Ihmislähtöisen kehittämisen 3 tärkeintä työkalua

Organisaatiossanne todennäköisesti on jo käytössä jokin nykyaikainen tapa kehittää digitaalisia tuotteita tai palveluita. Viitekehys, kurinalainen tai vähintään yhtenäinen prosessi ja oikein valitut työkalut auttavat toimimaan tehokkaasti sekä tuottavasti. Lisäksi on ihminen tai peräti joukko ihmisiä: tekijät ja asiakkaat.

Ihmislähtöinen kehittäminen huomioi jokaisessa vaiheessa tai toiminnossa sen, kenelle arvoa tuotetaan: onko kohteena käyttäjä, sidosryhmä, kollega tai esim. sijoittaja. Jos toiminta ei palvele kohderyhmäänsä, se ei palvele muitakaan esimerkiksi organisaatiota ja omistajia. Jotta kohderyhmä on helpompi ottaa mukaan kehittämisen prosessiin, esittelen tässä muutaman hyödyllisen työkalun tai harjoitteen. Nämä varmistavat, että kehitätte tuotetta oikealle asiakkaalle, oikeaan tarpeeseen ja oikealla tavalla.

Kolme työkalua ihmislähtöiseen kehittämiseen

1. Kerää asiakasymmärrystä persooniksi  

Omassa mielikuvassani asiakas tai käyttäjä mylvii DevOpsin silmukan kaikissa vaiheissa. DevOpsin ja ketterän kehittämisen perimmäinen tavoite on tuottaa arvoa käyttäjälle mahdollisimman nopeasti vaiheittain ja oppien. On olennaista, että tiimit ratkaisevat oikeaa ongelmaa tai ongelmia ymmärtäen käyttäjien aidot ja todennetut tarpeet.

Yhä useammin törmään asiakasymmärryksen puutteeseen ja persoonan tarpeellisuuteen. Persoona on se ihminen (eläin tms), markkina tai segmentti, jolle toiminta kohdistetaan. Jotta voimme puhua ihmislähtöisestä kehittämisestä, jokaisessa kehityksen, testauksen ja tuotannon vaiheessa tulisi tunnistaa käyttäjä, asiakas eli persoona.

Siksi projektissa on usein mukana UX-suunnittelija. Haasteena on, missä vaiheessa ja miten asiakasymmärrys ja UX-suunnittelu sopeutuvat DevOpsiin: alkupuolella, testauksen ohessa tai loppupuolella. Alussa on useita kysymyksiä ilman kontekstia, testausten ohessa käyttäjätutkimus tuntuu olevan sekä raskas että liian hidastempoinen ja lopussa se on liian myöhäistä. Käyttäjätutkimuksen tulisi kulkea ketterästi tuotekehityksessä kaiken aikaa. Devaaja voi myös esimerkiksi haastatella projektiryhmää siitä, mitä odotuksia tai pelkoja projektin suhteen on ja saa näin lisätietoa asiakkaan odotuksista ja muutenkin mikä eri ihmisten ymmärrys on projektin luonteesta.

Olisi hyvä, että jokaisessa vaiheessa tiimit määrittäisivät persoonan (usein käyttäjä), jolle arvoa tuotetaan. Persoonasta voi tehdä esimerkiksi pahvileikkeen tiimin kahvihuoneeseen tai sen voi yhdistää Jiraan lisäosalla, joita ehkä syystä ja tarpeesta tuntuu olevan yhä enemmän. Ottamatta kantaa, mikä Persoona-lisäosa on paras teille, tässä muutama varteenotettava: Easy Agile Personas for Jira & Supersona. Saattaa olla, että persoona pysyy parhaiten mielessä ja mukana, kun se kulkee Jiran stooreissa ja tehtävissä.

Suosittelen, että persoonanne noudattavat tarpeitanne tai kysymyksiä ennemmin kuin jotakin valmista pohjaa. Asiantuntijamme auttavat helposti tai kattavasti alkuun asiakasymmärryksen keruussa.

2. Käyttäjän polku ja käyttäjäkokemus

Käyttäjätarinat palastelevat sen, miten käyttäjä toimii ja käyttäytyy tuotteen tai palvelun eri vaiheissa. Näin palvelumuotoilijan ja asiakaskokemusvalmentajan näkökulmasta käyttäjätarinat ovat toiminnallisia ja kylmiä. Niistä puuttuu tunnekokemus ja asiakkaan "miksi" hän haluaa tai tarvitsee toimia niin kuin tarina kertoo. Kun ymmärtää mikä on käyttäjän tarpeen taustalla ja motivaattorina, on helpompi priorisoida ja kehittää tuotteita paremmalla käyttäjäkokemuksella.

Ennen kuin pilkkoo käyttäjätarinat olisi hyvä tarkastella käyttäjän polkua. Käyttäjän polku tai asiakaspolku kertoo, mitä ja miksi käyttäjä tekee ennen, palvelun käytön aikana ja sen jälkeen. Suosittelen lisäämään polkuun asiakkaan tunteet, mukaan lukien motivaattorit ja huolet. Devaustiimi, joka valjastaa tuotteeseen toiminnallisuuksien lisäksi käyttäjän tunteen, on voittaja. 

Minua ilahduttaa se, että Atlassianin Marketplacesta löytyy myös tuotteita asiakaspolun määrittämiseen. Myönnän, että minulla ei ole niistä riittävää kokemusta, mutta mielelläni kuulen muiden käyttökokemuksia. Näitä on mm. Agile User Story Maps, Roadmaps & Persona Journey for Jira sekä Journey Mapping for Jira. Asiakaspolun rakentaa helposti Confluenceenkin DrawIo:lla tai Gliffylla. Toki myös Marketplacen ulkopuolelta löytyy Jira-yhteensopivia työkaluja, kuten esim. Glassbox, joten on tärkeää valita sopiva työkalu tarve ja käyttö edellä.

3. Design Sprint tai muu nopea protoilu

Design Sprintin slogan on “Fail fast, learn fast”. Sprintin avulla voi varmistaa, ratkaistaanko oikeaa ongelmaa, onko oletettu lisäominaisuus todellinen tai toimiiko tietynlainen “kehitelmä”. Jos Design Sprint tuntuu liian aikaa vievältä, sprintistä voi ottaa parhaat opit ja metodit nopeaan testaukseen sekä prototypointiin todellisilla käyttäjillä. Kuvailen tässä kuitenkin Design Sprintiä, valitsi sen tai jonkin muun nopean kokeilun (ja iteroinnin). 

Design Sprint testaa käyttäjälähtöisesti tai asiakaslähtöisesti tuotteen tai palvelun jotakin osaa tai tekijää ennen, tuotekehityksen aikana tai loppuvaiheessa. Design sprint henkii samaa build - measure - learn -henkeä kuin ketterä kehittäminenkin, oli kyse sitten agilesta, leanista tai devopsista. Sen ehdoton etu on siinä, että tunnistetaan ratkaistaanko oikeaa ongelmaa valitulle kohderyhmälle.

Protoilussa ja testaamisessa tärkeää on oppia käyttäjiltä. Tulee testata sitä, mikä ratkaisee keskeisen käyttäjän ongelman, oppia siitä, kehittää se huomioiden, testata seuraavaa haastetta jne. Mikään ei ole turhempaa kuin kehittää tyhjiössä. Palautetta käyttäjiltä on syytä kerätä nopeasti ennen isoa taloudellista panostusta tai liiketoiminnallista päätöstä.

Ihmislähtöinen kehittäminen on edellytys taloudelliselle menestykselle

Työkalu on hyödytön, tapa toimia on turha ja lopputulema on väärä, jos kehittäminen ei ole ihmislähtöistä. Työkalujen ja prosessien pilvimaailmassa on vaikeaa muistaa empatia ja se kuulostaakin naurettavalta: henkilöltä, joka on päätynyt bileisiin, joihin se ei sovi mutta joihin se kuuluu. Siksi on tärkeää, että empatia, ihmisyys on mukana tuotekehityksessä samanvertaisena kuin työkalutkin. Metodeja ja työkaluja piisaa. Tärkeää on tunnistaa ensin ongelma ja vasta sitten metodi ja työkalu, mutta yllä mainituilla tavoitteilla varmistetaan valitusta työkalusta huolimatta ihmislähtöinen kehittäminen. Toivon, että edellä esitetyistä enemmän tai vähemmän empatian työkaluista on arkista hyötyä tuotekehityksessä.

Lopulta liiketaloudellinen menestys perustuu sille, että oikeat ihmiset kehittävät valittujen ihmisten oikeita ongelmia. Älä rakastu työkaluun, vaan ihastu ongelmaan ja kulje tavoitteen satamaan.