5 tietä parempaan käyttäjäkokemukseen: Ohjelmistokehitys on jatkuvaa vuoropuhelua

Kirjoitimme aiemmin siitä, miten ohjelmistokehitystiimit varmistavat koodin teknistä laatua. Nyt lähestymme projektityöskentelyä käyttäjäkokemuksen näkökulmasta, kun äänessä ovat Design Lead Tuomas Talvitie, Product Owner Matilda Honkajuuri sekä UX Designer Jyri Mäkinen Cinialta.

Tarkoittaako UX-suunnittelu samaa asiaa jokaiselle? Onko vaatimusten määrittely lähinnä muotoilijan ja ohjelmistoarkkitehdin välistä kädenvääntöä? Tuskin tarkoittaa, ja ei sen ainakaan pitäisi olla sitä, kolmikko vastaa kuin yhdestä suusta. Yksimielisiä he ovat myös tästä: yhtä toimivaa projekti- tai työskentelymallia ei ole, sillä jokainen hanke on oma, monimutkainen kokonaisuutensa.

Mutta miten ohjelmistokehitys ja hyvä käyttäjäkokemus saadaan kulkemaan käsi kädessä, jos valmista ohjekirjaa ei ole? Ainakin näiden viiden näkökulman avulla:

1) Nippu hyviä toimintamalleja jokaisen käyttöön

On itse asiassa erinomainen juttu, ettei töiden tekemiseen ole valmista, ylhäältä annettua tapaa, Honkajuuri pohtii.

“Meillä on vahva design-tiimi. Se on suhteellisen iso, ja yhteenlaskettu työkokemus on melkoisen pitkä. Kun tällä joukolla vaihdamme kokemuksia eri projekteista ja sparraamme toisiamme, me kaikki saamme käyttöömme nipun erilaisia, joustavia ja hyväksi havaittuja työtapoja.”

Cinia ei ole tuotetalo eikä perinteinen projektitalo, vaan pitkäjänteisten kumppanuuksien ratkaisutalo. Esimerkiksi ketterät menetelmät ovat arkipäivää kaikille, mutta niitä sovelletaan eri tavoin. Helsingissä tai Tampereella saattaa olla hieman erilaisia käytäntöjä kuin Jyväskylän toimipisteessä. 

Raamit projektille nousevat silti ennen kaikkea asiakkaan tarpeista. “Eri toimialoilla liiketoimintaympäristöt ja ongelmakentät ovat hyvin erilaisia, joten toimintamalleja on syytä tarkastella tarpeen mukaan”, Tuomas Talvitie muistuttaa.

2) Design-osaajien keskinäinen tuki ja oppiva organisaatio

Oma Mattermost-kanava kuljettaa viestejä Cinian suunnittelijoiden välillä. Jyri Mäkinen muistaa useita tilanteita, joissa yhteinen pallottelu on auttanut umpikujasta eteenpäin. Varsinkin työuran juniorivuosina oli tärkeää, että matalalla kynnyksellä saattoi kysyä toisilta mielipidettä tai ehdotuksia työkaluiksi.

“Lisäksi meillä on kahden viikon välein tapaaminen, joka kokoaa yhteen kaikki muotoilun parissa työskentelevät cinialaiset”, Talvitie kertoo. “Ideana on juuri tuo aiemmin mainittu kehittäminen ja kartoitus. Jokainen voi kertoa, miten on omissa asiakasprojekteissaan ratkonut haasteita ja minkälaisia kipupisteitä on tullut vastaan.” 

“Näissä keskusteluissa nousee esiin näkökulmia ihan palveluiden määrittelystä frontend-kehitykseen asti”, hän jatkaa. “Kun konteksti- ja ympäristösidonnaisuus yhdistyy tietojen vaihtoon ja muiden työskentelyn seuraamiseen, mahdollistuu jatkuva oppiminen koko organisaation tasolla.”

Lue myös: Omannäköinen ura Cinialla: Näin kaksi koodaria on rakentanut polkuaan

3) Yhteinen ymmärrys termeistä: Mitä on UX? Mistä puhutaan, kun puhutaan vaatimusmäärittelystä? 

“Jos haluat kunnon lounasväittelyn, kysäise, mitä UX kenellekin tarkoittaa”, Honkajuuri heittää. “Yhden mielestä se on vain glitteriä, jota sipaistaan käyttöliittymän päälle. Toisten mielestä sen alle mahtuu kaikki loppukäyttäjätutkimuksesta tarvekartoituksen kautta ikonien piirtämiseen. Itse ajattelen, että kyse on lopulta kokonaisvaltaisen loppukäyttäjäkokemuksen luomisesta kehityshankkeissa.”

“UX, UI, palvelumuotoilu, liiketoimintamuotoilu, strateginen muotoilu… Ne lomittuvat toisiinsa ja sisällöistä voidaan väitellä. Mieluummin kysyisin, mitä suunnittelu tai design tuo yhteiseen pöytään? Lopulta tärkeintä on yritykseltä löytyvä suunnitteluvalmius. Eli mikä on meidän valmiutemme reagoida muutoksiin ja keskittyä olennaiseen yhdessä”, Talvitie jatkaa.

Vaatimusmäärittely on toinen sana, josta voi syntyä väärinkäsityksiä. Onko se yksi iso järkäle vai elävä joukko muuttujia matkan varrella?

“Jos puhuisimme vaatimusmäärittelystä jonakin yksittäisenä tapahtumana ohjelmistokehityksessä, olisimme lähempänä vesiputousmallia kuin ketterää ohjelmistokehitystä”, Honkajuuri huomauttaa. Usein vaatimusten määrittely ja päivittäminen onkin iteratiivista työtä jopa vuosia jatkuvan kehityskumppanuuden aikana.

4) Yhteys käyttäjiin jatkuu koko hankkeen ajan: tarpeiden tunnistamisesta toimiviin ratkaisuihin

“Kuvitellaan, että asiakas kertoisi haluavansa kuuraketin”, Honkajuuri havainnollistaa rautalankaesimerkin avulla. “En säntäisi suin päin määrittelemään vaatimuksia raketille, vaan jatkaisin keskustelua asiakkaan kanssa ymmärtääkseni, miksi hän haluaa raketin. Tarve saattaisi olla esimerkiksi se, että asiakkaan on saatava valokuva maapallosta. Sen jälkeen muotoilu voi lähteä liikkeelle.”

“UX-suunnittelu on jatkuvaa vuoropuhelua käyttäjien, arkkitehtien ja devaajien sekä projektin muiden sidosryhmien kanssa. Teemme paljon yhteistyötä ja käymme läpi hyvin konkreettisia, reaalimaailman asioita”, Jyri Mäkinen kuvaa vaihetta, jossa suunnitelmista on edetty toteutukseen. 

Ja kuten mainittua, jatkuvan kehityksen projekteissa myös aiemmin mainittuja vaatimuksia pitää tarkastella jatkuvasti. Ovatko ne yhä valideja? Kun käyttäjä on tiiviisti mukana kommentoimassa työtä, päästään toimivampaan lopputulokseen kuin silloin, jos vain UX-suunnittelija ja ohjelmistoarkkitehti ratkoisivat haasteet parhaaksi katsomallaan tavalla.

Lue myös: Osallistaminen keskeistä terveydenhuollon järjestelmien palvelumuotoilussa

5) Saumaton keskustelu teknisten ja design-osaajien välillä

Uudella idealla on parhaat mahdollisuudet muuttua teknisesti toimivaksi ratkaisuksi, jos sen äärellä on mahdollisimman monta eri alojen osaajaa heti alusta asti. 

“Suunnitteluun, keskusteluun ja prototyyppien luomiseen tarvitaan usean eri asiantuntijan yhteistyötä. Mukana voivat olla esimerkiksi Product Owner, rahoituksesta päättävä vastuuhenkilö, loppukäyttäjä ja UX-suunnittelija – ja tämäkin lista on vain yksi esimerkki. Kokoonpano valitaan aina projektiin sopivaksi”, Honkajuuri kuvailee. “Prototyyppien kanssa tarvitaan usein muutama nopea epäonnistuminen, mutta juuri kokeilujen avulla löydämme tärkeimmän ytimen.”

“Vaatimusten määrittelyyn tarvitaan alussa mahdollisimman monialainen joukko. Kehityksen jatkuessa joukon pitää olla itse asiassa yhtä monialainen”, Talvitie täydentää. 

Näin päästään lopputulokseen, joka palvelee loppukäyttäjää, on liiketaloudellisesti järkevä ja teknisesti mahdollinen toteuttaa. 

Haluatko mukaan joukkoon, jossa eri näkökulmia arvostetaan?