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ä.
- 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.
- Vastuutetaan asiakasta niistä tuotoksista, joita tämä tuottaa näissä väärissä rooleissa.
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:
- Asiakas on tiedon lähteenä työstään ja kehittämiskohteesta – esimerkiksi lääkäri kertoo työstään ja sairaalan toiminnasta.
- Asiakas – erityisesti käyttäjä – on kehitettävän järjestelmän tai sen prototyyppien testikäyttäjänä.
- 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ä.