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. 

ISO 9241-14: ohjeita valikkojen suunnitteluun

ISO 9241-14 antaa ohjeita valikkojen rakenteen, navigoinnin, valinnan ja esitystavan suunnitteluun. 
Jos tehtävääsi kuuluu valikkojen suunnittelu, niin 9241-14 sisältää ohjeita tähän:   

• Valikkojen rakenne: annetaan ohjeita valikon valintojen ryhmittelyyn ja valintojen järjestykseen
• Valikossa navigointi: annetaan ohjeita navigointivihjeiden käyttöön sekä pikanavigointiin 
• Valinnan tekeminen: annetaan ohjeita valintatapoihin, näppäimistön käyttöön, kursorin käyttöön, osoittamiseen, sekä myös ääniohjaukseen.  
• Valikon esitystapa: annetaan ohjeita valinnan havaitsemiseen, valikkoihin liittyvään sijoitteluun sekä niin tekstivalinnan, graafisen valinnan kuin äänivalinnan rakenteeseen ja syntaksiin. 

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. 


Ja kommentti näistä standardeista yleensä. Oman subjektiivisen käsitykseni voisin ilmaista vaikka siten, että kun on nähnyt kaikenlaisia käyttöliittymäratkaisuja, niin on tullut mieleen, että olisipa tuonkin suunnittelija lukenut jos ei muuta niin edes noita standardeja... 
Standardit eivät ole ehkä varsinaisia lukuelämyksiä.  Mutta ne kuitenkin perustuvat monien kansainvälisten ammattilaisten kumuloituneeseen tietämykseen ja osaamiseen. 

ISO 9241-13: ohjeita käyttäjä opastamiseen käyttöliittymässä

ISO 9241-13 sisältää ohjeita liittyen sanalliseen muotoiluun, kehotteisiin, palautteen antamiseen, virheen hallintaan, tilatietoon ja on-line ohjeisiin. 

• Yleiset ohjeet: esimerkiksi ohje, että käyttäjäohjeiden tulisi erottua muusta näytössä olevasta tiedosta 
• Sanallinen muotoilu: annetaan ohjeita sille, miten tekstiä tulisi muotoilla; esimerkiksi ohje, että ohjeviestin tulisi ilmaista käyttäjän eikä järjestelmän kontrollia. 
• Kehotteet: annetaan ohjeita sen ilmaisulle, miten järjestelmä on valmis vastaanottamaan käyttäjän syötteen 
• Palautteet: annetaan ohjeita, miten järjestelmän tulisi antaa palautetta käyttäjälle; esimerkiksi ohje siitä, että järjestelmän tulisi antaa vasteen jokaiseen käyttäjän syötteeseen
• Tilatieto: annetaan ohjeita, miten ilmaista tietoa järjestelmän tai 
• vuorovaikutuselementin tilasta; Esimerkkinä ohje siitä, että olisi käytettävä näytön 
(ikkunan) vakiopaikkaa kunkin tyyppiselle tilatiedolle
• Virheenhallinta: esimerkiksi ohje, että virheviestien tulisi kertoa mikä meni väärin, mitä korjaavia toimenpiteitä käyttäjä voi tehdä ja mikä oli virheen syy
• On-line ohjeet: esimerkiksi  olisi annettava 
• tehtävään liittyvää tietoa järjestelmästä ja sen tarkoituksesta

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

ISO 9241-12 kertoo, miten esittää erityyppisiä tietoja käyttöliittymässä

ISO 9241-12 antaa perusohjeet käyttöliittymässä näkyvän tiedon suunnitteluun, sijoitteluun ja koodaukseen

ISO 9241-12 sisältää ohjeita tiedon esittämisen suunnitteluun käyttöliittymissä:

• Tiedon sijoittelu ja organisointi: ohjeita ikkunoiden ja alueiden, syöte- ja tulostealueiden, ryhmien, luetteloiden, taulukoiden, nimikkeiden ja kenttien suunnitteluun. 
• Graafiset elementit: ohjeita kursorien ja osoittimien suunnitteluun
• Koodaustekniikat. Koodaus on lyhenteiden käyttöä tai eri tyyppisten tietojen luokittelua (esimerkiksi miten lomakkeessa ilmoitetaan pakolliset kentät, tai miten tekstissä ilmaistaan avainsanat). Annetaan ohjeita aakkosnumeeriseen ja graafiseen koodaukseen, värikoodaukseen sekä markkereiden, välkkymisen, koon, kirkkauden ja alleviivauksen käyttöön koodauksessa

Esimerkki tiedon organisoinnista: Näytön elementeillä (esim. kentät, ikonit, graafit) tulisi olla nimike/ otsikko.

Esimerkki koodaustekniikoista: Väriä ei tulisi koskaan käyttää ainoana koodaustapana.

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