Käytännön käytettävyysvihje: hanki oikeaa ulkopuolista näkemystä

Käyttöliittymäsuunnittelussa - niinkuin monessa muussakin asiassa - sokaistuu helposti omaan tekemiseensä.  Sokaistumista tapahtuu yksilöillä mutta myös firmankin tasolla. Sen vuoksi ulkopuolinen näkemys käyttöliittymäratkaisuihin on tarpeellista.

Ulkopuolista näkemystä käytettävyyteen saa kahdella päämenetelmällä: 

1. ulkopuolisen käytettävyysasiantuntijan tekemä asiantuntija-arviointi
2. käytettävyystestaus (käyttöliittymän testaus loppukäyttäjillä)

Näistä käytettävyystestaus (2) on ehkä se perusratkaisu, mutta esimerkiksi itse olen tehnyt paljon asiantuntija-arviointeja (1). Ja oma kokemukseni on, että asiantuntija-arvioinnit ovat olleet useimmissa tapauksissa parempi ratkaisu kuin käytettävyystestaus:

• Asiantuntijan läpikäynti on nopeampi ja edullisempi kuin käytettävyystestaus
• Asiantuntija pystyy katsomaan järjestelmän läpi kattavammin ja analyyttisemmin
• Asiantuntija-arvion pystyy tekemään hyvinkin varhaisessa vaiheessa käyttöliittymäsuunnittelua

On selvää, että asiantuntija-arvioinnin laatu riippuu hyvin voimakkaasti arvioijasta. Mutta sama ilmiö on havaittu myös käytettävyystestauksen suhteen: testien laatu riippu voimaakkaasti siitä, kuka tekee testit (ks. CUE-tutkimukset). Tutkimustulokset ovat osittain ristiriitaisia menetelmien laadun suhteen.

Käytettävyystestaus on kuitenkin menetelmä, jota olisi sitten jossain välissä syytä käyttää. Mutta mielestäni liian usein sen käyttöön syöksytään liian epäkypsillä suunnitteluratkaisuilla.

Ulkopuolinen näkemys kannattaa hankkia mahdollisimman varhaisessa vaiheessa. Mielellään jo ennenkuin toteutus alkaa. Mitä pitemmälle arviointia lykätään, sitä työläämmäksi tulee mahdollisten muutosten tekeminen.

Ja vielä varoitus parista sudenkuopasta:

• Käyttöliittymän katselmointi asiakkaan kanssa ei ole tuloksellinen käytettävyyden arviointimenetelmä. On ihan eri asia tehdä käytettävyystestaus (= laittaa käyttäjät käyttämään järjestelmän protoa) kuin käydä läpi käyttöliittymäratkaisuja neuvottelussa asiakkaan kanssa. 
• Järjestelmän koekäyttö käyttäjillä ei niin, että käyttäjät antavat palautetta, ei ole sama kuin käytettävyystestaus. Käytettävyystestaus perustuu testaajien (käytettävyysasiantuntija, suunnittelutiimi tms.) jäsentämään arviointiin käyttäjien suoritumisesta. Käyttäjien antama palaute perustuu taas käyttäjien omaan jäsennykseen. Näissä on suuri ero.  

----------------------------------------------------------------

Tämä on viimeinen kirjoituksen tähän blogiin CreaBase-projektin puitteissa  - projektihan päättyy tänään 31.8.2011. Voi olla, että en jatka juuri tämän blogin kirjoittelua - riippuu siitä, missä määrin nimenomaan mobiilikäyttöliittymäasiat ovat itselläni tapetilla. Osahan tämänkin blogin kirjoituksista ovat yleisempiä, niinkuin nämä viimeiset kirjoitukset. 

Tarkoitukseni on kuitenkin jatkaa kirjoittelua ainakin kahteen muuhun blogiin: 

• Käytettävyysnavigoija -blogi, jossa keskityn yleiseisiin käytettävyysasioihin
• Hanki käytettävyyttä -blogi, joka käsittelee käytettävyyden varmistamista järjestelmien kilpailutuksessa ja hankinnassa (esimerkiksi kun hankitaan terveydenhuollon järjestelmiä)

Olet tietenkin tervetullut seuraamaan mielenkiintosi mukaan näitäkin blogeja!

Käytännön käytettävyysvihje: mieti mittareita

Miten paljon käytettävyyteen kannattaa panosta? Miten ohjata käyttöliittymän suunnittelua oikeaan suuntaan?

Kehitysprojektin aluksi kannattaa miettiä sitä, mitä vaikuttavuutta käytettävyydellä halutaan, ja määrittää vaikuttavuudelle mittarit ja tavoitetasot.

Mitä käytettävyyden vaikuttavuus tarkoittaa? Otetaan esimerkki:

• Eräässä julkisessa virastossa tilanne on se, että virkailijoiden aikaa kuluu aivan turhan paljon siihen, että joutuvat vastaamaan asiakkaiden "turhiin" puheluihin. Näissä "turhissa" puheluissa asiakkaat kysyvät, miten täytetään erilaisia lomakkeita, mitä tietoja tarvitaan eri hakemusten tekemiseen jne.
• Kaikki nuo asiat periaatteessa ovat tällä hetkellä viraston verkkopalvelussa, mutta se vain ei toimi käyttäjien kannalta. Kyseessä siis puhtaasti käytettävyysongelma. 
• Nyt kun järjestelmää uudistetaan, niin yhdeksi käytettävyyden vaikuttavuustavoitteeksi määritettiin asiakkaiden "turhien" puheluiden määrän radikaali pienentäminen: 90% vähemmän puheluita kuin mikä on nykytilanne
• Eli mittari on "turhien puheluiden lukumäärä", ja tavoitetaso on 90% vähennys puheluihin

Tämä esimerkki kertonee sen, että käytettävyyden vaikuttavuus on aina sovelluskohtainen liiketoiminta-asia (tuskin ylläolevan esimerkin mittari ja tavoitetaso pätevät kaikille järjestelmille tai tuotteille...).

Kunkin tuotteen tai järjestelmän kohdalla pitää siis erikseen miettiä ja päättää, mitä merkittävää vaikuttavuutta käytettäävyydellä voidaan  saavuttaa omassa sovelluksessa tai tuotteessa. Seuraavassa tyypillisiä käytettävyyden vaikuttavuusnäkökulmia:

• järjestelmän käyttöönoton sujuvuus
• oppimisaika
• käyttäjän työn tai tehtävien suorittamisaika
• järjestelmän hyväksyttävyys
• käyttökoulutuksen tarve (missä määrin tarvitaan)
• käyttäjädokumentaation määrää 
• käyttäjätyytyväisyys
• käyttäjätuen tarve 
• käyttäjät tekemien virheiden määrä
• jälleenmyyjien ja edustajien koulutuksen tarve

Käytännön käytettävyysvihje: vältä turhat mokat

Käyttöliittymissä näkyy niin paljon turhia mokia. Esimerkiksi alla oleva vähintääkin hämmentävä ("yksikäsitteisyysrajoitusten") virheilmoitus. Tällaisia kun olisi helppo välttää.

Ja se vinkki tähän on ehkä vähän tylsä: lukeminen. 

• Aiemmin kirjoittelin ISO 9241 -standardista. Sen eri osista löytyy lukuisa määrä ohjeita hyvistä suunnittelukäytännöistä. Ks. aiemmat kirjoitukset. 
• Konkreettinen ja helppolukuinen opas on Jeff Johnsonin GUI Bloopers. Englanninkielinen kirja, ja pitää tietenkin ostaa. On hauska, ja kuvaa monin esimerkein "käyttöliittymätöppäyksiä" ("blooper"), ja antaa ehdotuksia paremmiksi ratkaisuiksi
• Jos suunnittelee verkkosivuja, niin hyvä ja ilmainen opas on Research-Based Web Design and Usability Guidelines. Englanninkielinen, mutta helppolukuinen ja konkreettinen, käytetty paljon kuvia. Ja siis ilmaiseksi verkosta ladattavissa
• Edelleen verkkosivumaailmaan liittyen tunnettu, hauska ja myös tiivis kirja on Steve Krugin Don't make me think. Jo tuo kirjan nimi on mielestäni yksi verkkosivujen - ja myös laajemminkin käyttöliittymien - perusohjeita. Siis "älä pane käyttäjää pähkäilemään". Alla on esimerkki esimerkki dialogista, joka kyllä laittaa pähkäilemään: (siis mikä tuo rengastettu dialogi on?) 

Tällaisten ohjeiden tunteminen lisää käyttöliittymien laatua ja käytettävyyttä - ei tule turhia mokia. 

Mutta tulee muistaa, että tällaisten ohjeiden noudattaminen ei vielä takaa hyvää käytettävyyttä. Ja miksi? Koska hyvä käytettävyys on viime kädessä käyttäjien työn ja tehtävien tukemista. Ja tämän näkökulman suunnittelu on aina sovelluskohtaista, johon yleiset ohjeet eivät tietenkään voi antaa konkreettisia suunnitteluohjeita. 

Käytännön käytettävyysvihje: käyttäjähaastattelut

Tee käyttäjähaastatteluja niin, että opit ymmärtämään käyttäjien työn

Tässä alkaa CreaBase-projekti päättyä. Voi olla, että senkin jälkeen kirjoittelen tähän blogiin jotain.

Mutta ajattelen kirjoittaa tähän lopuksi muutamia käytännön vihjeitä, jotka haluaisin nostaa keskeisinä "vinkkeinä" käyttöliittymäsuunnittelussa.

Ja aloitan siitä, että käyttöliittymäsuunnittelun perustaksi tulisi ymmärtää käyttäjän työ.

Käytettävyys on käyttäjän työn tukemista, ja hyvä järjestelmä/ tuote on siis sellainen, joka tukee käyttäjän työtä. Sen vuoksi käyttäjän työn tunteminen on ensiarvoisen tärkeää.

Se, miten minä olen pyrkinyt ymmärtämään käyttäjän työtä, on käyttäjien haastattelut seuraavilla periaatteilla:

• Haastatellaan siis siinä mielessä, että oppii aidosti ymmärtämään käyttäjän työn
• Tässä tulee ymmärtää se, että käyttäjät eivät monestikaan osaa jäsentää työtään ja pukea ajatuksiaan selkeästi. Kyse ei ole siis siitä, että haastatellaan ja kirjataan käyttäjien sanomisia ylös
• Ydin on se, että opit ymmärtämään työn. Itselläni on useinkin käynyt niin, että tällaisessa haastattelutilanteessa itse käyttäjäkin on oppinut omasta työstään sellaista, mitä ei ole itse jäsentänyt aiemmin
• Tee tarkentavia kysymyksiä, tulkintoja jne. 

Käyttäjän työn ymmärtäminen antaa perustaa myös käyttöliittymää syvemmille asioille, kuten tietorakenteen suunnittelulle. Ks. http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html.

Tiedän, että yllä oleva selitys haastatteluista ei ole tyhjentävä "resepti". Mielestäni sellaista ei voi antaakaan, koska kyse on ymmärtämisestä, haastattelijan oivalluksiin perustuvasta jäsennys- ja ajattelutyöstä. Mutta ehkä tuo antaa idean siitä, mistä on kysymys.

Toinen tapa ymmärtää käyttäjien työtä on käyttäjien työn havainnointi (kutsutaan engl. contextual inquiry). Tämä on periaatteessa vahvempi tapa; siinähän ollaan kentällä. Ja periaatteessa myös ehdottomasti suositeltava. Ongelmana kuitenkin se, että havainnointi vaatii enemmän resursseja. Itse lähtisin aina ensi haastatteluista. (tai itse asiassa ihan ensiksi luen saatavilla olevat dokumentit, jotta haastatteluihin menisi mahdollisimman hyvällä taustatietämyksellä).

"Järjestelmän on oltava helppokäyttöinen" - vaatimus, jolla ei merkitystä

Kirjoittelen kyseisestä aiheesta "Hanki käytettävyyttä" -blogissa: http://hankikaytettavyytta.blogspot.com/2011/08/jarjestelman-on-oltava-helppokayttoinen.html. Ja totean, että jokainen järjestelmä täyttää vaatimuksen "järjestelmän on oltava helppokäyttöinen". 


Tämä aihe on herättänyt myös muutaman kommentin.

muutama käytettävyysongelmaharjoite

ks: http://kaytettavyysnavigoija.blogspot.com/2011/08/muutama-kaytettavyysharjoite.html

Ehdottakaapa ratkaisuja!

Ohjeita lomakkeiden suunnitteluun: ISO 9241-17

Tässä on jo ollut muutama kirjoitus standardeista. Mutta otetaan vielä tämä. 

ISO 9241-17 sisältää ohjeita useissa järjestelmässä hyvin keskeiseen osa-alueeseen, lomakkeiden suunnitteluun.  Ohjeita annetaan neljässä kategoriassa 

• Lomakkeen täyttörakenne: annetaan ohjeita liittyen otsikointiin, visuaaliseen koodaukseen, näytön täyttämiseen, käyttäjäohjeisiin, lomakkeen layoutiin, kenttiin ja nimikkeisiin
• Syötteen huomiointi: annetaan ohjeita  monien yksityiskohtien kuten kursorin liikkumisen, tekstin syötön, oletusarvojen, aakkosnumeerisen tekstin syötön, valintojen, valikoiden, luetteloiden, painikkeiden, valintojen, syötön korjauksen, virheiden käsittelyn, tietojen uudelleensyötön ja kenttien validoinnin suunnitteluun
• Palaute: annetaan ohjeita syötteen kaiuttamisen, kursorin ja osoittimien näyttämisen, virhesyöttöjen ja tietokantamuutosten näyttämisen suunnitteluun
• Navigointi: annetaan ohjeita kursorin oletussijainnin, kenttien välisen liikkumisen, tabuloinnin, vierittämisen ja lomakkeen valinnan suunnitteluun

Esimerkkinä ohjeet asioihin, joissa yllättävän paljon näkee puutteita: 

• pakolliset ja valinnaiset syöttökentät tulisi esittää siten, että kuka tahansa käyttäjä erottaa ne välittömästi toisistaan
• kun lomaketta näytetään ensimmäisen kerran, kursorin tulisi olla automaattisesti kentässä, jonka käyttäjän joutuu tai mahdollisesti täyttää ensimmäiseksi.  

Vähän tarkempaa tietoa artikkelissa  http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Ja vielä tarkempaa itse kyseisessä standardin osassa.