Viisi parempaa menetelmää

Viisi parempaa menetelmää suunnitella parempaa käytettävyyttä/ UX:ää. Viisi kriittistä kysymystä suunnittelun onnistumiseksi, ja vastaukset niihin. 

1. Mikä on se oleellinen tieto asiakkaasta,  mitä ei yleensä hankinta, mutta mikä pitäisi hankkia heti kehityshankkeen alussa? Tieto, joka on kriittistä kehityshankkeen onnistumiseksi. 

Ja miten kyseinen tieto hankitaan?

Vastaus: 

• Kriittinen tieto asiakkaasta: Kohdemaailmamalli (engl. TWM, Target World Model)
• Kohdemaailmamalli hankitaan Kohdemaailma-analyysilla (engl. TWA, Target World Analysis)

Yleisesti ajatellaan, että käyttäjäkeskeinen suunnittelu aloitetaan kysymyksillä: "Ketä ovat käyttäjät?" ja "Mitkä ovat käyttäjätehtävät? Nämä eivät kuitenkaan anna riittävän vahvaa perustetta vahvojen suunnitteluratkaisujen luomiselle. Tarvitaan Kohdemaailma-analyysi.

Kohdemaailma ei ole sama kuin käyttäjän maailma. Käyttäjän maailma on dynaaminen: tehtävät, joita käyttäjän tulee tai joita käyttäjä haluaa tehdä. Asiakkaan kohdemaailma on perustaltaan staattinen. Se kuvaa asiakkaan maailman ontologian: asiat ja niiden hierarkkiset ja rinnakkaiset suhteet. Toki sisältää myös dynaamisia elementtejä (asioiden tilat), mutta perusrakenne on staattinen. Esimerkiksi kun kehitetään yliopiston tohtorikoulutusta tukeva tietojärjestelmä, kohdemaailma on yliopiston tohtorikoulutus. Vastaavasti kohdemaailma on sairaalaan ilmoittautuminen (itseilmoittautumisjärjestelmä), lääkärien erikoistumiskoulutus (erikoistumiskoulutuksen hallintaohjelmisto) ja yrityksen toiminta (toiminnanohjausjärjestelmä). 

Kohdemaailma-analyysi tarkoittaa sukeltamista asiakkaan maailman syvälliseen ymmärrykseen - "tunne asiakas paremmin kuin hän itse" - ennen suunnittelun alkamista. Ilman asiakkaan maailman syvällistä ymmärtämistä on suuri riski, että kehittämistyö lähtee vikasuuntaan, seurauksena usein raskaatkin muutostyöt tai lopputulos, joka ei vastaa asiakkaan ja käyttäjien tarpeita. 

Kohdemaailma-analyysi ei tarvitse vie pitkää aikaa. Usein kolmessa päivässä saadaan aikaiseksi syvällinen malli. Toki analyysin tekeminen on intensiivistä ja ajattelua vaativaa. 

Kohdemaailmamallin ja kohdemaailma-analyysin tarkempi kuvaus löytyy kirjasta Kohdemaailma-analyysi.

2. Mikä on vaikuttavampi tapa kommunikoida käytettävyydestä/ UX:stä liiketoimintajohdon kanssa? 

Vastaus: 

• Määrittää Haluttu käytettävyyden vaikuttavuus, DUXI (Desired User eXperience Impact)
• Tehdään yhdessä liiketoimintajohdon kanssa 

Perinteinen tapa lähestyä liiketoimintaa on ns. cost-benefit -analyysi. Siinä yritetään vakuuttaa liiketoimintaa käytettävyyden/UX:n yleisistä eduista. 

DUXI on erilainen lähestymistapa. Siinä lähestytään liiketoimintaa analyyttisesti, ja katsotaan yhteistyössä liiketoimintajohdon kanssa, mitä vaikuttavuutta käytettävyydellä voidaan potentiaalisesti saavuttaa liiketoiminnassa. Käytettävyystyön sisältö ja resurssit tulee lähteä liiketoiminnan tavoitteista, ja DUXI:n määrittäminen on näiden käytettävyyteen liittyvien liiketoimintatavoitteiden määrittämistä. 

DUXI:ssa ei siten "myydä" käytettävyyttä. Analyysin johtopäätös voi hyvin olla, että tässä kehityshankkeessa käytettävyydellä saavutettu vaikuttavuus ei ole merkittävä, eikä käyttäjäkeskeiseen suunnitteluun ole suurta panostustarvetta. 

DUXI on aina liiketoimintakohtaista. Myös siinä määritetyt "halutun käytettävyyden vaikuttavuuden" mittarit ovat aina liiketoimintakohtaisia.  

Kuvausta DUXI:sta löytyy esimerkiksi täältä ja täältä.  

3. Millä tavoilla ottaa käyttäjät mukaan paremmin (laadukkaammin, eettisemmin) kehityshankkeisiin, ja mitä tapoja tulee välttää?

Vastaus:

• TUDEO-periaate: Treat A User as A Domain Expert Only.

"Käyttäjäkeskeinen suunnittelu" on osoittautunut terminä harhaanjohtavaksi. Monet reaalimaailman esimerkit osoittavat, että asiaan perehtymätön tulkitsee termin usein väärin. Ei ymmärretä sitä, että käyttäjäkeskeisyys tarkoittaa vain rajattua tapaa ottaa käyttäjiä mukaan. Se ei tarkoita siis suinkaan sitä, että käyttäjälle voidaan antaa mitä erilaisimpia rooleja. 

Tästä väärinkäsityksestä pari, mielestäni aika karmeaa esimerkkiä reaalimaailmasta: 

• Koulujen käyttöön tarkoitetun järjestelmän käyttöliittymän suunnittelijaksi laitettiin erään koulun rehtori
• Monissa julkisissa hankinnoissa käytettävyyttä pisteytetään siten, että käyttäjäraati antaa pisteet (esim. 1 - 10) käytettävyydestä toimittajien esittämän demon perusteella. 

Tällaiset käytetyt tavat eivät toimi, ja samalla ovat eettisesti vääriä käyttäjiä kohtaan. Esimerkiksi käyttäjähaastattelut pitää tehdä tietyllä tavalla; muuten voivat sekä tuottaa epäluotettavaa tietoa ja samalla ovat käyttäjien huonoa kohtelua.

TUDEO-periaatteessa: 

• Oikeita tapoja ottaa käyttäjät mukaan on neljä. Kaikki perustuvat siihen, että käyttäjää pidetään ainoastaan oman osaamisensa asiantuntijana.  
• Vääriä - mutta usein käytettyjä - tapoja voidaan tunnistaa ainakin seitsemän. Näissä tavoissa käyttäjälle annetaan muita tehtäviä kuin oman osaamiseensa liittyviä, kuten käyttöliittymien arviointia, suunnittelua, ja mielipidekysymyksiin vastaamista. 

TUDEO-periaatetta on kuvattu täällä ja täällä (ei TUDEO-nimellä). 

4. Mikä on oikea tapa tehdä tietojärjestelmien julkinen hankinta niin, että lopputulos olisi aidosti hyvä käytettävyys? 

Vastaus: 

• UCRO-periaate: Usability as A Compulsory Requirement Only. 

Tarjouspyynnössä käytettävyys pitää sisällyttää pakollisiin vaatimuksiin niin, että niissä määritetään käytettävyyden riittävä taso. Käytettävyyden paikka ei ole vertailukriteereissä (lukuunottamatta joitakin harvoja tilanteita). 

Lisäehtona tietenkin on, että käytettävyysvaatimukset eivät saa olla mitä tahansa, vaan niiden tulee olla valideja ja riittävän kattavia. Validius tarkoittaa, että käytettävyysvaatimusten täyttäminen tarkoittaa sitä, että lopputulos on aidosti (riittävän) käytettävä. 

Lisää tietoa tästä on useassa tämän Käytettävyysnavigoija-blogin kirjoituksessa. 

5. Mikä on parempi käyttäjäkeskeisen suunnittelun malli?

Vastaus 

• JFunnel-malli: Käytettävyysohjattu vuorovaikutussuunnittelu

Paljon käytetyt käyttäjäkeskeisen suunnittelun mallit eivät sisällä käytettävyyden vaikuttavuuden eikä kohdemaailman määrittelyä. Ne usein korostavat iteraatiota, mikä ei itsessään ole tietenkään erityisen tavoiteltavaa. (iteraatiota usein tarvitaan, mutta johtuu enemmän ongelmien tuottamista tarpeista kuin että olisi tavoitteellista). 

JFunnel sisältää nuo puuttuvat aktiviteetit. Samoin se korostaa käyttäjäkeskeisen suunnittelun trattimaista luonnetta: asiakkaan, käyttäjän ja liiketoiminnan maailma tiivistyy käytettävyysvaatimuksiksi, joiden täyttämiseksi voidaan hakea vastausta laajasta suunnitteluratkaisujen avaruudesta. 

Lisätietoja kirjassa Navigoi oikein käytettävyyden vesillä. Mallia on päivitetty sen jälkeen, ks. blogikirjoitus.