Otsikon kysymys on varsinainen miljoonan dollarin kysymys. Se sisältää monen bisneksen kannalta tärkeät avainsanat – tehokkuus ja käyttäjälähtöisyys. Tehokkuus näistä on liiketoiminnallisesti ilmeinen hyöty, käyttäjälähtöisyyden hyödyt ovat puolestaan välillisiä, mutta niillä saattaa olla taloudellisesti paljon suurempi potentiaali kuin tehokkuudella. Tehokkuus määrittää kuinka nopeasti ja taloudellisesti lopputulokseen päästään, kun taas käyttäjälähtöisyys määrittää kuinka onnistuneesti lopputulos vastaa todellisen elämän tarpeisiin ja millainen kasvupotentiaali, kuluttajauskollisuus ja tuotettu lisäarvo tuotteella on. Suunnitteluprosesseja on lähes yhtä paljon kuin on yrityksiä, projekteja ja palveluita, useat näkemäni prosessit sisältävät elementtejä jotka pyrkivät tehokkuuteen, mutta millainen on käyttäjälähtöinen suunnitteluprosessi?
Millaisia prosesseja on olemassa?
Karkeasti ohjelmistoalalla käytetyt prosessit jakautuvat muutamaan pääryhmään – lineaarisiin, iteroiviin ja hybrideihin.
Iteroivissa malleissa palataan määrätyissä pisteissä taaksepäin esimerkiksi validoinnin jälkeen, eikä etenemä välttämättä ole niin suoraviivaista tai helposti hahmotettavaa. Näin siis paperilla – tosiasiassa jatkuvasti iteroivasti tarkentaen suunniteltu tuote etenee koko ajan määrätyissä sykleissä tullen koko ajan paremmaksi, tarkemmin määritellyksi ja laajemmaksi ominaisuuksiltaan. Iteroivat mallit mahdollistavat tiedon keräämisen kokeilemalla, eikä kaiken tarvitse olla tarkasti määriteltyä jo projektiin lähdettäessä. Suunniteltaessa nykymaailman kompleksisia ohjelmistokokonaisuuksia jotka vaativat usean tiimin saumatonta yhteistyötä, iteroivat mallit mahdollistavat yhteisen ymmärryksen rikastamisen. Esimerkiksi IBM Design Thinking Model on hyvä ja varsin tunnettu esimerkki iteroivasta prosessista, jossa käyttäjä on huomioitu pitäen prosessin lopputavoitteen keskiössä.
Hybridimalleissa näitä yhdistellään tarpeen mukaan, prosessissa voi olla iteroivia osuuksia, jonka jälkeen puolestaan edetään vaiheistetusti palaamatta taaksepäin. Usein hybridimalleihin päädytään hyvin tapauskohtaisesti tarpeen mukaan.
Miksi prosesseja määritellään?
Eräs suurimmista hyödyistä suunnitteluprosessin auki piirtämiseen on yhteisen ymmärryksen lisääminen siitä, mitä tapahtuu nyt, mitä seuraavaksi ja mitä on tähän mennessä saavutettu. Prosessien määrittely mahdollistaa suunnittelun vaiheiden pilkkomisen siten, että tiettyjä osia voidaan esimerkiksi ulkoistaa, kun tiedetään kunkin vaiheen tavoite ja lopputulema, kuinka paljon resursseja tarvitaan ja kuinka kauan vaiheet kestävät. Tämä pätee kaikkiin prosesseihin iteroivista lineaarisiin. Prosessi on tiimien väliselle yhteistyölle ikään kuin orkesterin nuotit, joiden avulla orkesteri pystyy eri soittimilla soittamaan samaa kappaletta, pitämään temmon samana ja ulkoistettu kallis sooloartistikin osaa nuottivihon avulla laulaa soolonsa oikeaan aikaan.
Käyttäjälähtöisyys prosessissa – miten se näkyy?
Olen joskus kysynyt ihan ääneenkin, voiko suunniteltava tuote olla käyttäjälähtöinen, jos sen suunnitteluun käytetty prosessi ei ole käyttäjälähtöinen? Käyttäjien osallistaminen, käyttäjätutkimus ja -testaus on olennainen osa tehokasta tuotekehitystä, ja sen tulee näkyä prosesseissa. Yleisimpiä sudenkuoppia joihin prosesseja määritellessä sorrutaan, on liiallinen prosessikeskeisyys. Joskus saattaa hämärtyä, miksi prosesseja ylipäätään määritellään. Usein tällöin itse prosessista tulee tärkeämpi kuin tuotteesta, ohjelmistosta tai palvelusta, jota ollaan suunnittelemassa. Puhumattakaan tuotteen tuomasta lisäarvosta. Useimmiten prosessikeskeinen prosessimäärittely johtaa liian yksioikoisen prosessin valintaan, esimerkiksi juuri vesiputousmallin valintaan kompleksisen ohjelmiston suunnitteluun. Silloin prosessi saattaa paperilla vaikuttaa selkeältä ja jopa järjestelmälliseltä mutta ei kestä todellisen elämän happotestiä eikä ole realistinen. Toisaalta liian prosessikeskeinen ajattelu saattaa johtaa myös liian kompleksiseen prosessiin, joka pyrkii vaikkapa ennustamaan aivan kaiken tulevaisuudessa tapahtuvan.
Kuitenkin kaiken tulisi vähintään jollain tasolla lähteä loppukäyttäjästä, myös käytetyn suunnitteluprosessin. Parhaita tapoja saada loppukäyttäjä näkyväksi suunnitteluprosessiin on määritellä pisteet, jossa tietoa kerätään käyttäjiltä tutkien, osallistaen tai testaten. Prosessissa täytyy olla myös sisäänrakennettuna mekanismeja, jolla varmistetaan, että virheet huomataan ajoissa ja niihin on mahdollista puuttua.
Mitä jos ensi viikolla pitäisi olla valmista?
Joskus on syytä edetä nopeammin kuin täydellisen tuotekehityksen viitekehyksessä edettäisiin. Esimerkiksi konseptien kehittäminen ja validointi uusille markkinoille on sellainen alue, missä kannattaa ennen suuria panostuksia varmistua siitä, että ollaan tekemässä oikeita asioita. Yksi kuuluisa ”oikotie onneen” on Google Venturesin kehittämä Google Design Sprint, jossa 5 päivässä suoritetaan minikokoinen tuotekehitysprosessi alusta loppuun. Se on mahdollista siten, että eniten resursseja syövät vaiheet kehitys ja julkaisu skipataan, osallistetaan oikea määrä oikeita ihmisiä ja loppukäyttäjiä, ja työskennellään rajatuissa aikaikkunoissa yhdistäen itsenäistä työskentelyä ja tiimityötä. Design sprintin vaiheet ovat päivien mukaan jaettuna:
- Ymmärrä (Understand)
- Tässä vaiheessa olemassa oleva tieto aiheesta kerätään yhteen yhteiseksi pohjaksi suunnittelulle.
- Lopputuote: Ongelman kuvaus, käyttäjät, tarpeet, konteksti, kilpailijat ja hahmotelma strategiasta
- Luonnostele (Sketch)
- Pyritään muodostamaan useita kilpailevia vaihtoehtoisia ratkaisuita vastaamaan edellisessä vaiheessa muodostettuun käsitykseen tarpeista.
- Lopputuote: Vaihtoehtoisia ratkaisuja
- Päätä (Decide)
- Päätetään yksi vaihtoehto edellisestä vaiheesta, joka kehitetään sprintin aikana testausvalmiiksi.
- Lopputuote: Parhaaksi tunnistettu ratkaisu kuvattu esimerkiksi storyboardiksi
- Prototypoi (Prototype)
- Rakennetaan testattava prototyyppi valitusta konseptista. Keskitytään toimintoihin ja käytettävyyteen estetiikan sijaan.
- Lopputuote: Karkea prototyyppi jolla tärkeimmät ominaisuudet voidaan testata.
- Testaa (Test)
- Testataan konseptia käyttäjillä, ja mahdollisesti arvioidaan myös sen toteutettavuutta.
- Lopputuote: Tieto siitä, mikä toimii ja mikä ei toimi. Validoitu karkea konsepti.
Design-sprintin aikana ei saada julkaisukelpoista tuotetta valmiiksi vaan sen tavoite on jotain muuta. Se pyrkii rikastamaan olemassa olevaa tietoa keräämällä niiden päälle kilpailevat ratkaisuvaihtoehdot, ja testaa niitä potentiaalisilla käyttäjillä. Tämä välttää resurssien hukkaamista pitkiin kehitys- ja julkaisuvaiheisiin eli oikoo suunnittelun raskaimman ja kalleimman vaiheen ohitse. Tällainen ”pikaprosessi” iteroi suoraan idean ja testauksen välillä erittäin tehokkaasti, jolloin varmistetaan suunniteltavan tuotteen bisnespotentiaali, arvontuotanto ja vältetään monia ongelmia joita olisi muuten yksinkertaisesti mahdoton ennustaa ennen toteutusta. Se on siis käyttäjälähtöinen ja tehokas suunnitteluprosessi. Miksi se ei siis ole täydellinen tuotekehityksen viitekehys, josta aiemmin puhuin?
Ehkä siksi, että siitä puuttuu edelleen se suorittava työ joka toimivan ohjelmiston aikaansaamiseksi on tehtävä. Molempia siis tarvitaan, nopeaa iteraatiota ja validointia jotta aikaa vievä kehitystyö ei mene hukkaan tai keskity vääriin asioihin. Aikaa vievää kehitystyötä jotta nopean syklin sprinttauksella saavutettu ymmärrys ja tieto ei mene hukkaan.
Teamit tarjoaa kokeneet palvelumuotoilijat, -UX/UI-suunnittelijat ja osaajat vaativiin ohjelmistokehityshankkeisiin. Tarjoamme käyttöösi kokonaisia tiimejä tai tarvittavat osaajat olemassa olevaan tiimiin. Toteutamme asiakaskohtaiset ohjelmistoratkaisut myös avaimet käteen -periaatteella.
