keskiviikko 27. tammikuuta 2016

Tietojärjestelmien käytettävyysongelmat: miten ottaa oppia tuotekehityksestä?

Tietojärjestelmien käytettävyysongelmien yksi keskeinen syy on se, että vastuu vaatimuksista, tarpeiden jäsentämisestä ja suunnitteluratkaisujen oikeellisuudesta sälytetään asiakkaille. Mallia pitäisi ottaa tuotekehityksestä, jossa vastuu asiakkaan ymmärtämisestä ja suunnitteluratkaisujen toimivuudesta on luonnollisesti  yksinomaan aina kehittävällä yrityksellä. (Vai voiko Nokia syyttää käyttäjiä siitä, että heidän puhelimiensa käytettävyys ei toiminut?)

Aito asiakaslähtöinen suunnittelu ymmärretään hyvin usein väärin. Ajatellaan, että se tarkoittaa asiakkaan osallistumista suunnitteluprosessiin. Ja että kun asiakas on mukana määrittely- ja kehittämistyössä, niin se itsessään takaa, että suunnittelun laatu paranee ja saadaan korkealuokkainen lopputulos.

On kuitenkin kriittistä, millä tavoin, missä rooleissa ja millä vastuulla asiakas on mukana. Tässä tehdään kaksi yleistä virhettä. 
  1. Laitetaan asiakas sellaisiin rooleihin, joissa tällä ei ole edellytyksiä tuottaa hyvää laatua. Tällaisia ovat tehtävät, jotka eivät ole asiakkaan ydinosaamista ja joihin tällä ei ole aitoja edellytyksiä, resursseja tai motivaatiota. 
  2. Vastuutetaan asiakasta niistä tuotoksista, joita tämä tuottaa näissä väärissä rooleissa.
Jo järjestelmämäärittelyn peruslähestymistapa on aidon asiakaslähtöisyyden vastakohta: pyydetään asiakasta kertomaan vaatimuksia, toiveita, mielipiteitä ja näkemyksiä kehitettävästä järjestelmästä. 

Muita ongelmallisia tapoja ovat esimerkiksi ne, joissa asiakkaan edustajat laitetaan tekemään määrittelyjä tai suunnittelua työpajoissa tai arvioimaan suunnitteluratkaisuja, prototyyppejä, rautalankamalleja tms.

Aidossa asiakaslähtöisyydessä asiakas on ainoastaan sellaisissa rooleissa, jossa hän voi tuottaa laadukasta tietoa kehittämistyöhön – oman ammattinsa, työnsä ja työpaikkansa asiantuntijana – ja jossa asiakasta ei laiteta minkäänlaiseen vastuuseen kehittämistyön laadusta.

Käytännössä tämä tarkoittaa ainoastaan kahta asiakkaan roolia: 
  1. Asiakas on tiedon lähteenä työstään ja kehittämiskohteesta – esimerkiksi lääkäri kertoo työstään ja sairaalan toiminnasta. 
  2. Asiakas – erityisesti käyttäjä – on kehitettävän järjestelmän tai sen prototyyppien testikäyttäjänä.
Vastuullinen asiakaslähtöisyys on sitä, että järjestelmää tai tuotetta kehittävä yritys ottaa kaiken vastuun kaikesta suunnittelutyössä, asiakastarpeen perusymmärryksestä lähtien. Aidossa asiakaslähtöisyydessä suunnittelun lähtökohtana on

  • kehitystiimin syvällinen ymmärrys asiakkaan työstä ja asiakkaan maailmasta
  • kehitystiimin omassa tulkinnassa siitä, mitä asiakas aidosti tarvitsee  sekä toteutuksen kehittämisen laadusta
  • kaiken kaikkiaan kehitystiiminvastuunotto ajattelusta koko kehityshankkeen ajan.


Keskeinen kysymys sitten tietenkin on se, että miten kehitystiimi pääsee sisälle asiakkaan maailmaan ja saa syvällisen ymmärryksen siitä? Päinvastoin kuin usein ajatellaan, tämän pystyy tekemään yllättävänkin nopeasti. Oleellista on vain tehdä se toimivalla tavalla. Väitän, että nykyisin käytössä olevat menetelmät (aktivitettikaaviot, vuokaaviot, prosessikuvaukset, tietovirtakaaviot jne.) eivät pureudu oleelliseen. 

Itse olen hakenut ratkaisua uudesta ajattelutavasta: menetelmästä nimeltään kohdemaailma-analyysi. Katso lisää tästä.  

2 kommenttia:

  1. Aihe on vaikea, eikä universaalia totuutta voida koskaan löytää, mutta yleisesti toimivalle mallille(lue idealogialle) käytettävyys-kehittämisessä olisi varmasti tarvetta.

    Vaikken ole vielä paljoa todellisiin projekteihin osallistunutkaan, jo omien projektien läpivieminen on aiheuttanut tutustumisen tähän samaiseen ongelmaan; tosin eri mittakaavassa.

    Tehdessä omia projekteja tuotteen todellinen käytettävvyyskehitys tapahtuu minulla poikkeuksetta aina ulkona lenkkeillessä ja pyöritellessä näitä käytettävyysnäkökohtia mielessäni paremmiksi. Etuna tässä on se että tietyn palasen todelliset käyttömahdollisuudet tulevat paremmin realisoitua tällä 'iteratiivisella' mallilla.

    Mietinkin nyt, koska ensimmäisellä kerralla suunniteltu toteutusmalli ei lähes koskaan tule olemaan se lopullinen ratkaisu, niin olisiko tähän nykyisellään iteratiiviseen prosessiin olemassa mitään nopeampaa keinoa, jolla siis tästä "kehitä -> ideoi" -syklistä pääsisi nopeammin lopulliseen toimivaan toteutukseen?

    Tällä tavalla toteutusprosessi vie valitettavan paljon aikaa, sillä jo yhden osion lopullisen muodon realisoituminen voi vaatia kymmenittäin syklejä.

    Joten ymmärrän lopussa kirjoittamasi lauseen kehitystiimin ajatusmaailman muokkaamisesta, sekä ymmärryksen syventämisestä asiakkaan ajatusmaailmasta erittäin hyvin.

    VastaaPoista
  2. Kiitos kirjoituksesta. Tuttu juuri puhui aiheesta ja toi tuotekehityksen esille. On mielenkiintoista nähdä, miten heillä toimintatavat muuttuvat. Aikaahan nämä ottavat että löytyy se toimiva keino.

    VastaaPoista