Käytettävyyden sudenkuopat
Käytettävyyteen ja sen suunnitteluun liittyy monia harhakäsityksiä. Esimerkkejä tyypillisistä "sudenkuopista":  

Hyvä käytettävyys = visuaalisesti tyylikäs käyttöliittymä
Käytettävyyden varmistus tarkoittaa käytettävyystestausta
Helppo käyttää, kun on vähän näppäimiä
Hyvät verkkosivut, kun on "paljon linkkejä samaan paikkaan"
Käytettävyys kuntoon rekrytoimalla käytettävyysasiantuntija projektiin
Tuotepäällikkö käyttöliittymäsuunnittelijaksi
Käyttöliittymäsuunnittelu on maalaisjärkeä
Tunnen asiakkaat, tunnen käyttäjät
Me tiedämme käyttäjien tavoitteet
Käytettävyys on subjektiivista, sitä ei voi mitata
Kysytään käyttäjiltä
Kohderyhmähaastattelu (focus group) on tuloksellinen käytettävyysmenetelmä
Meillä on hyvä käyttöliittymä, kun asiakkaat ei valita
Annetaan käyttäjän päättää, mikä on hyvä suunnitteluratkaisu
Ei muuteta käyttöliittymää, koska käyttäjät ovat tottuneet vanhaan

Kunkin kohdalla on selitetty:
- mikä on sudenkuoppa
- miksi ei näin
- miten tulisi toimia

Katso myös päivitetty luettelo (pdf):

Hyvä käytettävyys = visuaalisesti tyylikäs käyttöliittymä

Sudenkuoppa
: "Kyllä meillä on kiinnitetty huomiota käytettävyyteen: olemme käyttäneet graafista suunnittelutoimistoa...." (eräs toimitusjohtaja käytettävyydestä).

Miksi ei näin: Visuaalinen tyylikkyys on tärkeä osa käyttöliittymää. Mutta tyylikkyys ei riitä, että sovellus olisi helppokäyttöinen. 

Miten tulisi toimia: Käytettävyyteen tarvitaan lisäksi toimiva käyttöliittymän arkkitehtuuri, joka tukee käyttäjän työtä. Ja hyviä suunnittelukäytäntöjä ja -standardeja noudattavaa interaktiosuunnittelua. Nämä syntyvät systemaattisella käytettävyyssuunnittelulla.

Käytettävyyden varmistus tarkoittaa käytettävyystestausta

Sudenkuoppa
: Käytettävyyden arviointi (käytettävyystestaus, asiantuntija-arviointi jne.) on pääasiallinen käytettävyysaktiviteetti.

Miksi ei näin: Käytettävyyden arviointi (käytettävyystestaus) on usein käytetty ja sinällään oleellinen käytettävyystoimenpide: saadaan selville mikä on olemassa olevien suunnitteluratkaisujen käytettävyyden toimivuus. Kuitenkin tällöin ollaan jo myöhässä - on jo suunniteltu käyttöliittymäratkaisuja, ja sidottu paljon resursseja ja aikaa suunnitteluun. On turhaa resurssien tuhlausta viedä arviointiin "arvattua" käyttöliittymää.

Miten tulisi toimia: Käytettävyyden suunnittelun tulisi olla mukana jo ihan varhaisimmassa vaiheessa kehityshanketta. Käytettävyydelle tulee asettaa selkeät tavoitteet, ja toteuttaa suunnitteluratkaisut hyviä käytettävyysperiaatteita noudattaen (ks. käytettävyyden varmistuksen vaiheet esim. JFunnel -mallista). 

Helppo käyttää, kun on vähän näppäimiä


Sudenkuoppa: "Tavoitteena on helppokäyttöisyys: yhden tai korkeintaan kahden näppäimen käyttöliittymä". Tämä näyttää olevan luontainen ajattelutapa, niin insinööreille kuin markkinoinnin edustajillekin. Tavoitellaan yhden näppäimen käyttöliittymää.

Miksi ei näin: Tosi on, että "vähän näppäimiä" näyttää yksinkertaiselta käyttää. Mutta miksi ratkaisu ei toimi? Yksinkertaisesti sen vuoksi, että laitteen toiminnallisuus ei osoittaudukaan niin yksinkertaiseksi. Yhtäkkiä ollaankin siinä tilanteessa, että käyttö perustuu esimerkiksi näppäinten pitkiin tai yhtaikaisiin painalluksiin - käytettävyyden kannalta yleensä erittäin ongelmallisia ratkaisuja. Tuloksena helpolta näyttävä laite - mutta vaikea käyttää.

Miten tulisi toimia: Hyvä käyttöliittymä syntyy systemaattisella suunnitteluprosessilla. Lopputulos näppäinten määrän suhteen on usein "ei paljon eikä vähän näppäimiä" - mutta oikeita sellaisia. 

Hyvät verkkosivut, kun on "paljon linkkejä samaan paikkaan"

Sudenkuoppa: "Verkkosivuilta saadaan asiat löytymään, kunhan on riittävästi linkkejä ristiin" (eräs mainostoimiston johtaja). 

Miksi ei näin: Voi auttaa asiaa, mutta ei todellakaan ratkaise tiedon löytämisen ongelmaa, jos on sivuston rakenne ja muut suunnitteluratkaisut ovat ongelmallisia.

Miten tulisi toimia: Verkkosivuilta tieto löytyy, kun informaatioarkkitehtuuri on hyvin suunniteltu, ja yksityiskohtien suunnittelussa on noudatettu hyviä suunnittelukäytäntöjä.

Käytettävyys kuntoon rekrytoimalla käytettävyysasiantuntija projektiin


Sudenkuoppa: "Meillä on käytettävyys kunnossa, olemme nimittäneet erään asiasta kiinnostuneen projektin käytettävyysasiantuntijaksi". Tämä ilmiö näyttää toistuvan uudestaan ja uudestaan: rekrytoidaan tai nimitetään käytettävyysasiantuntija - usein nuori ja kokematon - projektitiimin jatkoksi.

Miksi ei näin: Ratkaisu toimii harvoin, koska käytettävyyden oikea huomioiminen tarkoittaa useimmissa tapauksissa merkittäviä muutoksia olemassa oleviin suunnittelukäytäntöihin ja suunnittelukulttuuriin. Eli tulisi saada muutoksia myös "senioreiden" työ- ja ajattelutapoihin. Yleensä ylihaastava tehtävä varsinkin nuorelle henkilölle.

Miten tulisi toimia: Käytettävyyden organisatoriseen kehittämiseen ei ole välttämättä helppoa ratkaisua; helposti syntyy ristiriitoja. Yksi mahdollisuus on teettää käytettävyyssuunnittelun nykytilan analyysi (ns. käytettävyyskypsyysarviointi). Strategisten käytettävyystavoitteiden määrittäminen ja niiden merkitys yrityksen liiketoiminnalle (ks. JFunnel-malli) voi myös olla toimiva lähtökohta.

Tuotepäällikkö käyttöliittymäsuunnittelijaksi



Sudenkuoppa: "Olemme huomanneet, että ohjelmistosuunnittelija ei ole oikea henkilö suunnittelemaan käyttöliittymää. Niinpä se on annettu tuotepäällikön vastuulle". Usein kuvio on tämä: aluksi käyttöliittymän suunnittelee ohjelmistosuunnittelija. Kun asiakkaat valittavat käyttöliittymää, niin suunnitteluun otetaan tuotepäällikkö mukaan.

Miksi ei näin: Sinällään ollaan menossa oikeaan suuntaan: käytettävyyssuunnittelunhan tuleekin olla yhteistyötä. Ongelmahan tulee tietenkin siitä, jos ohjelmistosuunnittelijalla eikä tuotepäälliköllä ole käyttöliittymä- eikä käytettävyyssuunnittelun koulutusta. Vaikka tuntee hyvin asiakas- ja käyttäjätarpeetkin, niin käyttöliittymän suunnittelu on "eri juttu".

Miten tulisi tehdä: Käyttöliittymän suunnittelu on oma ammattitaitonsa: alan teoriat ja hyvät suunnitteluperiaatteet tulee tuntea. (Tämän otan hieman varovasti esiin: niin ohjelmistosuunnittelijat kuin tuotepäällikötkin toki voivat myös tuottaa hyviä ideoita käyttöliittymäratkaisuiksi!)

Käyttöliittymäsuunnittelu on maalaisjärkeä 


Tämä liittyy edelliseen. Hyvät käyttöliittymäratkaisut kyllä uppoavat maalaisjärkeen. Mutta niiden synnyttäminen ei vain onnistukaan maalaisjärjellä. Esimerkkinä vaikka iPodin käyttöliittymä. Käyttö on helppoa. Mutta ei varmasti ole syntynyt Applen insinööreiltä(?) noin vain maalaisjärjellä.

Tunnen asiakkaat, tunnen käyttäjät


Sudenkuoppa: Tämä ajattelutapa on usein markkinoinnin ja myynnin edustajilla.

Miksi ei näin: Kuitenkaan asiakastuntemus ei ole sama kuin  käyttäjätuntemus. Asiakastuntemus liittyy asiakkaan ostokäyttäytymiseen. Käyttäjätuntemus on taas nimenomaan sovelluksen käyttöön liittyvien tavoitteiden, tehtävien ja käyttöympäristöjen tuntemusta. Yhdessä asiakassegmentissä on tyypillisesti useita käyttäjäryhmiä.

Miten tulisi toimia: Eriyttää käyttäjäanalyysi asiakasanalyysista, ja käyttää käyttäjäanalyysiin soveltuvia menetelmiä.

"Me tiedämme käyttäjien tavoitteet"


Sudenkuoppa: Yksi käytettävyyssuunnittelun perusasioista on määrittää käyttäjien tavoitteet. Usein  ihmiset ajattelevat, että he tietävät ne. Tämä johtuu ehkä siitä, että termi "tavoite" on yleinen ja epämääräinen.

Miksi ei näin: Käyttäjien tavoitteet tulisi määrittää konkreettisina aikaansaannoksina. Voi sanoa, että kun systemaattisesti  jäsennetään käyttäjien tavoitteita, työskentely ja sen tulokset ovat poikkeuksetta yllättäneet mukana olijat. Käytettävyystavoitteiden jäsentäminen "aukaisee silmät".

Miten tulisi toimia: Käyttäjätavoitteet tulisi määrittää omana aktiviteettinaan. Yksi perusmenetelmä on työstää niitä erityisissä työpajoissa (ks. UIContext).  

Käytettävyys on subjektiivista, sitä ei voi mitata 



Sudenkuoppa: Ajatellaan, että käytettävyys on henkilökohtaista, eikä sitä voi mitata.

Miksi: Käytettävyyttä voi mitata. Tosin kuvaavien mittareiden valinta voi olla haastavaa.

Miten tulisi toimia: Yksi tyypillinen mittausperuste on käyttäjän suoriutuminen tehtävistä. Toinen tyypillinen mittari on käyttäjätyytyväisyys (ei ole sama kuin asiakastyytyväisyys); sen mittaamiseen on olemassa useitakin eri kyselyjä. 

Kysytään käyttäjiltä


Sudenkuoppa: Käyttäjiltä kyseleminen on houkutteleva vaihtoehto, mutta se on usein epäluotettavana. Kaksi tällaista tyypillistä tilannetta:
  • kysellään tulevaisuuden skenaarioita, tyyliin: "käyttäisitkö tällaista ja tällaista tuotetta (tai tuotteen ominaisuutta), jos sellainen olisi olemassa?"
  • pyydetään käyttäjältä palautetta käyttöliittymäratkaisuista, esimerkiksi näyttämällä yksittäisiä käyttöliittymäruutuja käyttäjälle

Miksi ei näin: Palautettahan näistä voi saada, mutta vastausten luotettavuus on kummassakin tapauksessa erittäin kyseenalaista. Oman tulevan käyttäytymisen arviointi on epäluotettavaa. 80-luvulla useimmat ihmiset olivat sitä mieltä, että eivät tarvitse kännykkää. Käyttöliittymäruudun (-ikkunan) kommentointi ei ole puolestaan paljasta sitä, miten tuote toimii varsinaisissa käyttäjätehtävissä.

Miten tulisi toimia: Käyttäjillä tehtävä arviointi tulisi perustua siihen, miten käyttäjät suoriutuvat tehtävistään. Tulokset saadaan perustuen havainnointeihin ja käyttäjiltä tehtäviin tarkentaviin kysymyksiin; eivät käyttäjän mielipiteisiin.

Kohderyhmähaastattelu (focus group) on tuloksellinen käytettävyysmenetelmä


Katso edellinen kohta (kohderyhmähaastattelu on nimenomaan mielipiteitä luotaava menetelmä)

Meillä on hyvä käyttöliittymä, kun asiakkaat eivät valita


Sudenkuoppa: Asiakastyytyväisyystutkimusten mukaan käytettävyys ei ole ongelma.

Miksi: Käytettävyys voi olla ongelmallinen, vaikka asiakkailta ei kuulukaan valituksia. Esimerkiksi asiakastyytyväisyystutkimukset harvoin pureutuvat käytettävyyteen. Luotettava käytettävyystutkimus ei myöskään perustu käyttäjien aktiivisuuteen - ei voi koskaan tietää, onko sellaisia aktiivisia käyttäjiä, jotka antaisivat palautetta.

Miten tulisi toimia: Käyttäjätyytyväisyyden arvioimiseen on sitä varten luodut käytettävyyttä arvioivat kyselymenetelmät.

Annetaan käyttäjän päättää, mikä on hyvä suunnitteluratkaisu 


Sudenkuoppa: Tämä voi vaikuttaa "hyvältä" idealta, erityisesti asiakaskohtaisten järjestelmien suunnittelussa.

Miksi ei näin: Kuitenkin tämän lähestymistapa on kovin ongelmallinen. Aluksikin, käyttäjä asetetaan rooliin, johon hänellä (todennäköisesti) ole koulutusta: käyttöliittymäsuunnittelijaksi. Toiseksi, tässä tapahtuu helposti vastuun siirtoa suunnittelijalta käyttäjälle. Jos käyttäjän ratkaisu ei olekaan hyvä, niin tällä systeemillä siitä tulee käyttäjän syy. Tämä on jopa eettinen ongelma.

Miten tulisi toimia: Päätös suunnitteluratkaisuista tulisi selkeästi olla suunnittelijoilla, perustuen käytettävyysaktiviteeteilla hankittuun käyttäjädataan.

Ei muuteta käyttöliittymää, koska käyttäjät ovat tottuneet vanhaan


Sudenkuoppa: Pidetään käyttöliittymä entisellään, koska käyttäjät tottuneet siihen.

Miksi ei näin: Sinällään looginen perustelu: käytön opittavuushan perustuu käyttäjän aiempaan kokemukseen. Eikä käyttöliittymän muuttaminen olekaan perusteltua, ellei ole selkeitä perusteita. Mutta sellainen perustelu kyllä yleensä on parantunut käytettävyys. Jos vanhassa käyttöliittymässä on käytettävyysongelmia, niin niiden korjaaminen on yleensä plussaa myös vanhoille käyttäjille. Ja tämä asia voidaan vielä käytettävyystesteissä varmistaa.

Filosofisempi peruste muuttamisen puolesta on se, että mikään ei kehity, jos asioita ei muuteta.

Miten tulisi toimia: Selkeästi valita käytettävyyden kehittämisen tie. Parempi käytettävyys tarkoittaa yleensä sitä, että vanhaankin tottunut käyttää sitä paremmin. Jos näillä käyttäjillä on ongelmia, näitä voidaan ratkaista erityisesti heille suunnitelluilla käyttövinkeillä tms.  

--------------
Jos tulee mieleen lisää, tai jos olet eri mieltä jostakin sudenkuopasta, niin laita postia: timo.jokela(at)joticon.fi.