Kolmiosaisen blogisarjan toisessa osassa palvelumuotoilijamme Pirkka Rannikko pohtii muotoiluajattelua oman mentorointiprosessinsa pohjalta. Ensimmäisessä osassa Pirkka kertoi kokemuksistaan Vincitin mentorointiohjelmassa ja jakoi niiden synnyttämiä mietteitä luovasta ajattelusta.

Blogisarjamme toisessa osassa kuullaan palvelumuotoilijamme Pirkan ajatuksia designista kommunikoitaessa.

Design-prosessissa työn tuloksia esitellään erilaisille sidosryhmille. Oman työn tulosten paljastaminen muille, varsinkin keskeneräisenä, voi olla stressaavaa. Toisaalta sen avulla oppii paljon itsestään, muista ihmisistä ja tietysti itse design-työn tekemisestä. Kun ajatuksiaan esittelee usein ja pitää yleisön eli sidosryhmät lähellä, sitä matalammalla kynnyksellä keskeneräistäkin tulee esitettyä. Näin myös palautteen saaminen ja ratkaisun iterointi nopeutuu.

Valmistautuminen auttaa siihen kuinka hedelmällistä designin esittely voi olla. Käyttäjä- eli yleisölähtöinen esitys ottaa huomioon designiin kohdistuvat tavoitteet ja mielenkiinnon kohteet, joita yleisöllä on. Se kertoo yleisön ymmärtämällä kielellä tarinan käyttäjän näkökulmasta eli skenaarion, jossa designin avulla ratkaistaan liiketoiminnallinen ongelma. Yleisölähtöinen esitys harvemmin keskittyy yksittäisten näyttöjen, komponenttien, visuaalisen ilmeen yksityiskohtien tai toteutettujen JIRA-tikettien esittelyyn. “Millainen käsikirjoitus, sellainen palaute” on hyvä muistisääntö niin designin esittelyyn, kuin esim. sprinttien demoihin.

Kirjat Presenting Design Work ja Articulating Design Decisions tarjoavat oivallisia oppeja siitä miten luovan ongelmanratkaisun tuloksia kannattaa esittää.

Palautteesta eväitä iterointiin

Designin esittämisen tavoite on tietysti palautteen kerääminen. Ratkaiseeko esitelty ehdotus liiketoiminnan ongelman sopivalla tavalla? Palaute johtaa iterointiin kohti sopivampaa ratkaisua, mutta monesti myös sitä linjaaviin päätöksiin. Linjaava päätös on sellainen, joka ottaa vahvasti kantaa siihen, mihin suuntaan ratkaisua viedään. Sen pyörtäminen voi vaatia huomattavaa todistelua ja todennäköisesti päätös ja siihen johtaneet perustelut kannattaa dokumentoida pidemmässä hankkeessa.

Päätös voi johtaa suunnitteluohjuriin (design-driver) esim. “Lupa-asiakirjojen käsittelyautomaation tulee olla läpinäkyvää ja perusteltavissa, jotta käyttäjät voivat luottaa järjestelmään.” Toisaalta se voi vaikka liittyä tiettyyn toiminnallisuuteen, esim. “Lupa-asiakirjan tarkastajia pitää aina olla vähintään kaksi, koska lainsäädännön takia noudatamme neljän silmän periaatetta.”. Ehkä päätös myös laittaa vaihtoehtoisia ratkaisuvaihtoehtoja hyllylle kypsymään ja tappaa rakkaitakin ideoita.

Dokumentoinnilla päätökset talteen

Erikokoisia ja -tasoisia päätöksiä voi syntyä pitkän kehityshankkeen aikana paljon. Päätösten dokumentointi on tärkeää siksi, että niihin voitaisiin palata pitkänkin ajan jälkeen jatkokehityksen yhteydessä. Tällöin tiimin mielessä saattaa pyöriä kysymyksiä, joihin olisi hyvä löytää vastauksia, esim.

• Miksi ratkaisu on sellainen kuin se on?
• Mitä siitä kannattaa muuttaa ja mikä kannattaa pitää?
• Mitä vaihtoehtoja meillä oli pöydällä ja miksi päädyimme tähän?
• Jos muutamme ratkaisua tietyllä tavalla, mitkä ovat muutoksen vaikutukset?
• 
  

Hankkeeseen myöhemmin mukaan hyppäävät tarvitsevat myös tietoa olennaisista linjauksista. Tai voi olla, että teet handoverin jollekin toiselle tekemästäsi työstä. Miten heille kerrotaan heidän työnsä kannalta tärkeimmät asiat ratkaisuista ja siihen johtaneesta prosessista osana projektin ja designin briiffausta?

Voi myös olla, että design on tehty ns. etuaikaisesti ja siihen palataan vasta pidemmän ajan jälkeen kehityksen alkaessa (prioriteettien muutos, anyone?). Designin teon aikana designerilla todennäköisesti on hyvä intuitio siitä, mikä toimii ja mikä ei, kun asia on aktiivisessa työstössä. Myöhemmin voi kuitenkin olla vaikea palauttaa mieleen, miksi ratkaisuun on päädytty, jos muistiinpanoja ei löydy.

On kuitenkin helpompaa sanoa, että päätökset kannattaa dokumentoida, kuin tehdä näin käytännössä. Kiire, eri tason asioiden käsittely eri työkaluissa, vaihtelevat toimintatavat jne. tekevät tästä arjessa haastavaa. Sopivaa työtapaa joutuu todennäköisesti hakemaan pitkään. Esim. nykyisessä asiakasprojektissani tulevaisuuden ratkaisuiden pohtimiseen vaikuttavia asioita löytyy mm. Figmasta, JIRAsta, Powerpointeilta ja todennäköisesti Confluencesta.

Kolmiosaisen blogisarjan viimeisessä osassa Pirkka pohtii design-kritiikkiä ja kuinka rakentavaa palautetta fasilitoidaan. Laita sarja seurantaan!