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. 

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.

ISO 9241-110 sisältää käyttöliittymän "perusperiaatteet"

ISO 9241-110 Dialogin periaatteet on käyttöliittymäsuunnittelijan keskeistä osaamista

ISO 9241-110 sisältää käyttäjävuorovaikutuksen suunnittelun keskeisiä periaatteita. Sisältö nimensä – ”periaatteet” - mukaan ei ole suoraan keittokirjamaisia konkreettisia ohjeita, vaan niitä on suunnittelijan sovellettava. 

ISO 9241-110 on päivitetty versio aiemmasta osasta ISO 9241-10, ja siten sisällöltään ”kypsynyt” yhden kierroksen verran.

Tässä kirjoituksessa esitän osan sisällön hyvin tiivistettynä. Jonkin verran seikkaperäisemmin olen käsitellyt sitä MetStan verkkojulkaisussa http://www.metsta.fi/ipubs/docs/machinery/articles/2011_nro_009.pdf. Tarkempaa perehtymistä varten tulee standardi kuitenkin hankkia. Standardi on saatavissa myös osana SFS:n käsikirjaa 72-2. 

Periaatteet on jaettu seitsemään osa-alueeseen:

• Sopivuus tehtävään: järjestelmä tukee käyttäjää tehtävän suorittamisessa; tehtävän suoritus ei perustu esimerkiksi valitun teknologian ominaisuuksiin. 
• Itsekuvautuvuus:  käyttäjille on selvää, missä dialogissa he ovat, missä kohdassa dialogia he ovat, mitkä toimet ovat mahdollisia ja miten ne voidaan suorittaa
• Yhdenmukaisuus käyttäjän odotuksiin nähden: järjestelmä vastaa käyttäjän ennakoitavissa olevia tilannekohtaisia tarpeita ja yleisesti hyväksyttäviä käytäntöjä
• Sopivuus oppimiseen: järjestelmä avustaa ja ohjaa käyttäjää järjestelmän käytön oppimisessa
• Hallittavuus:  käyttäjä kykenee aloittamaan ja hallitsemaan vuorovaikutuksen suuntaa ja nopeutta, kunnes tavoite on saavutettu
• Virheiden sieto: tarkoitetut tulokset voidaan saavuttaa syötteissä olevista ilmeisistä virheistä huolimatta joko ilman käyttäjän korjauksia tai vähäisin korjauksin
• Sopivuus yksilöllistämiseen: käyttäjät voivat muokata vuorovaikutusta ja tiedon esittämistä vastaamaan yksilöllisiä kykyjään ja tarpeitaan

Kukin osa-alue sisältää useita periaatteita, ja kukin periaate on konkretisoitu esimerkillä. Esimerkiksi yksi itsekuvautuvuuden periaate on: 

• Missä tahansa dialogin vaiheessa käyttäjälle esittävän tiedon olisi opastettava käyttäjää dialogin suorittamisessa loppuun. 
• Ja tätä konkretisoiva esimerkki:  Hotellivarausjärjestelmä antaa käyttäjän syöttää tarvittavat tiedot ja käyttää painikkeita [Seuraava] ja [Edellinen] dialogin vaiheiden läpikäymisen ohjaamiseen. 

Mikä hyödyllistä käytettävyystutkimusta?

Asiasta käytettävyysnavigoijablogissa (siinä myös mobiili näkökulma!)

http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-hyodyllista-kaytettavyystutkimusta.html

ISO 9241: Perustietoa käyttöliittymäsuunnittelijoille ja käytettävyysasiantuntijoille

Moniosainen ISO 9241 -standardi sisältää oleellista perustietoa jokaiselle käyttöliittymäsuunnittelijalle ja käytettyvyysasiantuntijalle

ISO 9241, Ihmisen ja järjestelmän välisen vuorovaikutuksen ergonomia, on laaja moniosainen standardi, joka sisältää periaatteita ja ohjeita käyttöliittymäsuunnittelun eri osa-alueisiin. Standardin eri osat sisältävät hyödyllistä perustietoa, joista jokaisen käyttöliittymäsuunnittelijan ja käytettävyysasiantuntijan olisi hyvä olla selvillä.

Ohjelmistojen suunnittelun sekä käytettävyyden varmistamiseen ohjeita antavat keskeiset osat ovat: 

• ISO 9241-110: Dialogin periaatteet (suomennettu)

• ISO 9241-11: Käytettävyyden määrittely ja arviointi (suomennettu)
• ISO 9241-12: Tiedon esittäminen (suomennettu)
• ISO 9241-13: Käyttäjäopastus (suomennettu)
• ISO 9241-14: Valikkodialogi
• ISO 9241-15: Komentodialogi
• ISO 9241-16: Suorakäyttödialogi
• ISO 9241-17: Lomakepohjainen dialogi
• ISO 9241-20: Tieto- ja viestintäteknologian laitteiden sekä palvelujen esteettömyyttä koskevat ohjeet (suomennettu)

• ISO 9241-129: Opastusta yksilöllistämiseen
• ISO 9241-151: Opastusta www-käyttöliittymiä varten (suomennettu)
• ISO 9241-171: Ohjelmistojen esteettömyttä koskevaa opastusta

• ISO 9241-210 Vuorovaikutteisten järjestelmien ihmiskeskeinen suunnittelu (aiemmin ISO 13407)

Osat sisältävät kaikkiaan satoja yksittäisiä periaatteita tai ohjeita. Standardin osissa valaistaan ohjeita myös esimerkein - tosin vaihtelvissa määräin - jotka parantavat ohjeiden luettavuutta ja ymmärtämistä.

Standardi ei ole mobiilispesifinen - itse asiassa siinä ei ole erityistä osaa mobiiliohjelmistojen suunnitteluun. Kuitenkin standardin sisältö on laajasti yleispätevää, niin mobiilisovelluksille kuin muillekin.  

Tämän blogin seuraavissa kirjoituksissa annan tietoa  tiivistetysti kunkin osan sisällöstä ja esimerkkejä osien ohjeista tai periaatteista. Sisältöön tarkempi perehtyminen - ohjeet kattavammin - edellyttää osien hankkimista (standardit ovat tekijänoikeuksien alaisia, eikä niitä saa kopioida). Ajatus on, että blogin perusteella lukijat saavat käsityksen standardin osien keskeisistä sisällöistä.  

käytettävyysammattilaisen eettiset säännöt

Eettiset säännöt on periaattessa käytettävyysammattilaisen perustietoa: http://www.usabilityprofessionals.org/about_upa/leadership/code_of_conduct.html .

Itse olen nyt joutunut näihin perehtymään, ja ne kyllä antavat tukea, jos joutuu hankalaan tilanteeseen (ei siis teknisesti vaan eettisesti).

käyttöliittymän mallia...

tietyllä tavalla mobiili käyttöliittymä tämäkin: http://360vr.com/2011/06/22-discovery-flight-deck-opf_6236/index.html

Mikä olikaan käytettävyyden määritelmä? Mitä ajatuksia ja kokemuksia?

Näin kesälomien päättyessä kertaus perusasioihin. Onko aito, oikea käytettävyyden määritelmä joskus hukassa? (ainakin itse joudun virallista määritelmää aina aika etsimään). Määritelmähän on sanamuodoltaan aika monimutkainen, ja hieman erilaisia käännöksiä näkyy eri kirjoituksissa. 


Käytettävyysnavigoija-blogissa käyn läpi määritelmää ja kyselen kokemuksia: 
http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html

Käyttäjävaatimukset, käyttäjätarpeet, käyttäjätoiveet - mikä ero?

On tärkeää ymmärtää, mitä eri termeillä tarkoitetaan. Otsikossa mainitut termit eivät suinkaan tarkoita samoja asioita. Kirjottelen asiasta Käytettävyysnavigoija-blogissa:
http://kaytettavyysnavigoija.blogspot.com/2011/06/kayttajatarpeet-toiveet-ja-vaatimukset.html

--------------
Tämä on sitten viimeinen kirjoitus ennen kesälomia. Palataan asiaan elokuun alussa!

Kokemuksia ulkopuolisen tekemästä käytettävyysarvioinnista

Kirjoitin Hanki käytettävyyttä! -blogiin yhden erityisen positiivisen kokemuksen tekemästäni käytettävyysarvioinnista. http://hankikaytettavyytta.blogspot.com/2011/06/ulkopuolinen-kaytettavyysarvioija-ei.html

Kyseessä oli ison julkisen organisaation verkkosivujen arviointi.  Vaikka kyseessä ei ole mobiili sovellus, niin arviointiperiaatteet ja -käytännöt ovat yleisiä ja siten myös sovellettavissa mobiilimaailmaan.

Yksi mielenkiintoinen havainto oli se, että sivujen suunnittelijat (= "käyttöliittymäsuunnittelijat") olivat olleet varsin yksinäisiä  suunnittelutyössään. Eli kollegat ja muut eivät olleet ehtineet paneutua asiaan ja sen vuoksi ulkopuolinen tuki koettiin arvokkaana.

Ja tulee mieleen: missä määrin tuotteiden käyttöliittymien suunnittelijat kokevat vastaavan tyyppistä "yksinäisyyttä"? Osaisiko joku kommentoida?

Mitä ovat käytettävyysvaatimukset?

Käytettävyysvaatimusten määrityksen olisi oltava käytettävyysohjatun vuorovaikutussuunnittelun keskeinen toimenpide. Käytettävyysvaatimukset määrittävät tavoitteet kehitettävän sovelluksen käytettävyydelle: kuinka hyvää käytettävyyttä tavoitellaan.

Ks. Käytettävyysnavigoija-blogi: http://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html

"Käytettävyysvaikuttavuus"

"Käytettävyysvaikuttavuus" kuullostaa ehkä oudolta ja epäelegantilta käsitteeltä. Kuitenkin se tarkoittaa keskeisiä perusteita käytettävyyssuunnittelulle (niin mobiilille kuin muullekin).

Tästä on kirjoitus Käytettävyysnavigoija-blogissa: http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

Mobiilin käyttöliittymän suunnitteluprosesseista

Tässä blogissa on kirjoitettu toistaiseksi lähinnä mobiilien laitteiden suunnitteluohjeista. Kuitenkin käytettävyyssuunnittelu prosessina on periaattessa samanlaista, on kyseessä sitten mobiili laite tai normaalinäyttöinen tietokone.

Yleisen käytettävyyssuunnittelun prosessi on kuvattu standardissa ISO 9241-210 ("ihmiskeskeinen suunnittelu). Kirjassani Navigoi oikein käytettävyyden vesillä (www.kaytettavyyskirja.net) olen tulkinnut ja vähän laajentanutkin ko. standardin esittämää mallia.

Vaikka kirja on aika uusi, niin ajatukset täsmentyvät koko ajan (toivottavasti oikeaan suuntaan). Ja kirjoitan uusiksi näitä täsmennyksiä. Silloin kun nämä asiat ovat yleisiä, ei mobiilimaailmaan rajoittuvia (mutta siis myös mobiilimaailmaan päteviä), niin kirjoitan niitä Käytettävyysnavigoija-blogiin. Laitan tähän blogiin sitten linkkejä, kun teen kirjoituksia sinne.

Ja ensimmäinen linkki: http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

Joskus kirjoittaminen on parempi ratkaisu kuin valinnat

Yleensä mobiililaitteilla on suositeltavaa käyttää valintoja, mutta joissakin tapauksissa kirjoittaminen on tehokkaampi ratkaisu

Tekstin kirjoittamista tarvitaan usein, mutta mobiililaitteella se on hidasta, varsinkin ilman näppäimistöä. Tämän vuoksi aina kun se on mahdollista, mobiililaitteilla tulisi käyttää valintaa kirjoittamisen sijaan.

Poikkeuksena tästä säännöstä ovat tapaukset, jossa valintojen määrä on kovin suuri, kuten vaikkapa pörssikursseissa kirjoittaminen voi olla valintaa kätevämpää. Esimerkiksi ’IBM’:n nimen kirjoittaminen on helpompaa käyttäjälle kuin valinta: ensin sopiva teollisuuden ala, sen jälkeen kirjoittaa ’I’, sen jälkeen tehdä valinta vierittämällä ruutua oikean yrityksen kohdalle. Käyttöliittymässä, joka luottaa pääasiassa valintaan kirjoittamisen sijaan on myös se hankaluus, että tieto voidaan järjestää monella eri tavalla ja käyttäjillä saattaa olla omat näkemyksensä tiedon organisointiin.

Weissin kokemuksen mukaan valintojen määrä pitäisi olla karkeasti ottaen alle 20, jotta niiden käyttäminen kirjoittamisen sijaan on kannattavaa. Erityisesti, kun valinnat voidaan jakaa osakategorioihin, kuten esimerkiksi kaupungit eri alueisiin maiden sisällä, on tekstin syöttö ön paremmin soveltuva ratkaisu kuin valinta.

"Suosi valintaa kirjoittamisen sijaan" -ohjetta ei tulekaan ottaa täysin kirjaimellisesti, kunhan muistetaan, että käyttäjillä on omat ongelmansa tiedon syöttämisessä ja se otetaan huomioon suunnittelussa.

Lähde: Weiss, Scott: Handheld Usability (2002). John Wiley & Sons

Suunnittelusuosituksia Internet-palveluille

Viisi suositusta suunniteltaessa Internet-palvelujen käyttöliittymiä: 1. sisällön optimointi, 2. tietokoneen ja kännykän käyttötavat, 3. kännykän kykyjen laaja hyödyntäminen, 4. kännykän resurssien kompensointi ja 5. sisällön päivitys. Mobiili erillissovellus voi tarjota paremman käyttökokemuksen kuin mobiili selain. 

Vartiainen (2009) on kerännyt väitöskirjassaan Suunnittelusuosituksia Internet-palvelujen kännykkäkäyttöliittymille yhteensä viisi eri näkökulmaa, jotka pitäisi ottaa huomioon suunniteltaessa Internet-palvelujen käyttöliittymiä. Nämä suositukset ovat:

1. Sisällön optimointi. Mobiilissa web-selaimessa webin sisältö pitäisi optimoida vastaamaan mobiililaitteen näytön tulostuskykyä. Vähintäänkin selaimella tulisi olla visualisointimenetelmä, joka muuntaa sisällön pienelle näytölle soveltuvaksi. Erillissovellus (mobiili client-sovellus) voi optimoida käyttöliittymän sisällön tietyn Internet palvelun tarpeisiin.
2. Tietokoneen ja kännykän käyttötavat. Mobiilin web-selaimen pitäisi hyödyntää tuttujen pöytätietokoneiden käyttötapoja, mutta sen lisäksi tuoda uusia ratkaisuja mobiilia käyttöä varten. Erillissovellus voi olla suunniteltu erityisesti tietylle mobiililaitteelle ja mobiilikäyttöön.
3. Kännykän kykyjen laaja hyödyntäminen. Mobiilin web-selaimen käyttöliittymän pitäisi tarjota miellyttävä käyttäjäkokemus hyvän navigointinäppäimen, pienen näytön ja yhdenmukaisen vuorovaikutuksen kautta. Erillissovellus voi hyödyntää käyttöliittymän ominaisuuksia, joita laitteella on käytössä, sisältäen parannetun grafiikan ja välittömän palautteen.
4. Kännykän resurssien kompensointi. Mobiilin web-selaimen pitäisi tuottaa erikoislaatuisia käyttöliittymäratkaisuja korvaukseksi rajoitetuista mobiililaitteen resursseista. Mobiililla erillissovelluksella on mahdollisuus täysin hyödyntää laitteen ominaisuuksia, joilla piilottaa tekniset yksityiskohdat käyttäjältä, tarjota mielekkäitä oletusarvoja, automatisoida toimintoja ja mahdollistaa yhteydetön käyttö.
5. Sisällön päivitys. Web-selain tarjoaa Internetin sisällön manuaalisen päivittämisen sekä automaattisen lataamisen. Sen pitäisi optimoida päivittäminen tavalla, joka on hyödyllinen käyttäjälle. Erillissovellus voi olla täysin integroitunut vastaavaan Internet-palveluun: se voi tarjota pääsyn ajan tasalla olevaan sisältöön ilman manuaalista päivitystä. (Vartiainen, 2009).

Vartiainen on lisäksi verrannut toisiinsa mobiilien erillissovellusten ja web-selaimen tyypillisiä eroja niiden ominaisuuksissa, koska mobiilit Internet-palvelut on mahdollista toteuttaa näillä kahdella eri tavalla. Mobiili web-selain on pääasiallinen tapa toteuttaa palvelut ja se voi yleensä tukea useita erityyppisiä Internet-palveluita, kuten pc-tietokone. Se ei ole kuitenkaan optimoitu erityisesti jollekin palvelulle, eikä siksi voi tarjota optimaalista käyttökokemusta millekään tietylle palvelulle. 

Mobiili erillissovellus taas on täysin integroitu vastaavaan Internet-palveluun ja se pystyy hyödyntämään alustan mahdollisuuksia ja optimoimaan käyttöliittymän palvelun tarpeita vastaavaksi. Siten sillä on edellytykset tarjota käyttäjälle parempi käyttökokemus kuin mobiililla web-selaimella. Toisaalta mobiilin erillissovelluksen kehittäminen voi olla työlästä sekä toteuttamiskelvotonta kaikille alustoille. 


Lähteet: Vartiainen, E., (2009). Design Implications for Mobile User Interfaces of Internet Services. Doctoral Dissertation Helsinki University of Technology, Faculty of Information and Natural Sciences, Department of Media Technology. Saatavilla: http://lib.tkk.fi/Diss/2009/isbn9789522481429/isbn9789522481429.pdf

Suunnitteluohjeita mobiililaitteiden web-lomakkeille

Suunnittele erilaiset lomakkeet mobiilinäyttöön kuin isolle näytölle. Esimerkiksi otsikot kenttien yläpuolelle, erilaiset haut samaan kenttään, yleensä yksinkertaista lomakkeet. 

Mobiililaitteissa tarvitaan myös lomakkeita, niitä käytetään esimerkiksi erilaisten asiakasrekisteröintien ja varausten teon yhteydessä. Chui Chui Tan (2011) pureutuu aiheeseen artikkelissaan “Forms that work: Designing web forms for usability” (http://www.formsthatwork.com/Mobile-forms).

Tan mukaan web-lomakkeet, jotka toimivat hyvin tietokoneilla, eivät välttämättä sovi mobiililaitteille. Tan (2011) esittää strategioita, joiden avulla voi suunnitella tehokkaampia ja vähemmän virheille alttiita web-lomakkeita mobiililaitteille. Kirjoittajan mukaan tietokoneiden web-lomakkeita ei ole suunniteltu tehokkaiksi, mikä on tärkeää lomakkeissa mobiililaitteissa käytettäessä. Lisäksi mobiililaitteissa webyhteys on rajoitetumpi, johtuen 1. käyttäjän käyttöympäristöstä 2. hitaammasta/epäluotettavasta verkosta ja 3. itse laitteesta, jossa on pienempi näyttö.

Www-lomake mobiililaitteeseen voi olla: 1. yksinkertaistettu versio pöytätietokoneen weblomakkeesta (ei mainoksia, kuvia, tai muita häiritseviä tekijöitä) 2. Kokonaan eri versio, jossa on yksinkertaisempi ja selkeämpi käyttöliittymä, tai 3. samat lomakekentät kuin web versiossa, mutta pienillä muutoksilla layoutissa ja kenttien otsikoiden asettelussa. Tan antaa yhteensä kahdeksan eri suunnitteluohjetta mobiililaitteiden web-lomakkeille.

1. Sijoita kenttien otsikot kenttien yläpuolelle. Vältä asettamasta otsikoita kentän vasemmalle tai oikealle puolelle, koska horisontaalisten otsikoiden näyttäminen samalla ruudulla on monesti mahdotonta, varsinkin pidemmät otsikot voivat olla ongelma.
2. Mobiililomakkeiden tulee olla niin yksinkertaisia ja suoraviivaisia kuin mahdollista. Tarpeettomien elementtien ja ominaisuuksien poisjättäminen helpottaa käyttäjää fokusoitumaan tehtävään ilman turhia häiriöitä tai ei-tarpeellisia kenttien täyttämistä. Yksi tekniikka on poistaa valinnaiset ja vähemmän tärkeät -kentät. Toinen tapa on poistaa elementit, joilla ei ole ensisijaista käyttöä, kuten vihjeet, kuvaukset ja linkit. Se vähentää visuaalista epäjärjestystä ja yksinkertaistaa käyttäjäkokemusta. Näytä ainoastaan sellaiset kentät, joiden ehdottomasti välttämättömiä prosessin ja tehtävän täyttämiseksi. Karkeana ohjeena voi pitää sitä, että jos kentän syötteellä ei ole merkitystä lopputulokseen, sen voi poistaa.
3. Toinen tapa yksinkertaistaa mobiililomaketta on yhdistää useammat samantyyppiset syöttökentät yhteen kenttään. Esimerkiksi eri etsintäkentät voidaan yhdistää samaan kenttään. Esimerkkinä kirjoittaja antaa Mapquestin hakutoiminnon (http://classic.mapquest.com/), jossa käyttäjä on voinut hakea ajo-ohjeita kahden eri paikan välillä kolmella eri tavalla. 1. Yrityksen nimellä, 2. osoitteella, tai 3. tallennetuista, tai edellisistä sijainneista. Palvelu yhdistää eri haut yhteen kenttään. Käyttäjä voi kirjoittaa vapaasti joko tietyn osoitteen tai yrityksen nimen kenttään ja kun kenttä on valittuna, käyttäjän nykyinen sijainti on oletusarvona. Käyttäjälle jää näin samat valinnan mahdollisuudet kuin useammalla kentällä, mutta lomake on yksinkertaisempi, eikä käyttäjää kuormiteta eri vaihtoehtojen miettimisellä.
4. Mobiililaitteissa on monia sisäänrakennettuja ominaisuuksia, joita kannattaa hyödyntää lomakkeiden yksinkertaistamiseksi. Tällaisia ominaisuuksia on muun muassa sijainnin tunnistin, GPS:n tai satelliittien välityksellä. Esimerkkinä Europcar, jonka mobiililomakkeessa ehdotetaan käyttäjälle, että laite etsii käyttäjän sijainnin perusteella lähimmän noutopaikan. Lisäksi mobiililomakkeen valikossa 139 eri maa vaihtoehtoa on rajattu 40 yleisimpään.
5. Hitaiden internet yhteyksien takia mobiililaitteissa suositellaan käyttämään yleensä minimimäärää sivun latauksia. Tätä sääntöä voidaan rikkoa syöttämisvalintojen parantamiseksi. Esimerkkinä AirAsian lentojen varaus, jossa tietokoneella käytettävässä versiossa kaikki 80 kaupunkia 25:ssä eri maassa, on näkyvissä yhdellä valinnalla, mutta mobiililaitteen lomakkeella ne on jaettu useille eri sivuille (maan mukaan), koska noin pitkä alasvetovalikko ei toimi mobiililomakkeella. Pitkän lomakkeen jakamisessa useisiin osiin täytyy kuitenkin olla varovainen; tehtävän suoritus ei saisi venyä käyttäjälle loputtoman pitkäksi. Koska tapa vaatii useita sivunlatauksia, kaikkien turhien elementtien poistaminen sivuilta on erityisen tärkeää.
6. Käytä sopivia syöttö elementtejä ja valikon kontrolleja. Mobiililomakkeiden suunnittelussa voi muuttaa kontrollien tyyppiä toiseksi, mikä saattaa yksinkertaistaa lomaketta ja sen vuorovaikutusta käyttäjän kanssa. Esimerkkinä tästä kirjoittaja käyttää Expedian hotellin varauslomaketta, jossa alasvetolistan kolme valintaa on korvattu erillisillä hyperlinkeillä. Suurta määrää linkkejä ei kuitenkaan kannata käyttää sivun alussa, koska vaarana on, että itse lomake jää pois näytöltä. Toisena esimerkkinä kontrollien vaihtamisesta Tan (2011) käyttää Shangri La hotellin varauslomaketta, jossa radiopainikkeiden luettelo on vaihdettu lyhyeen alasvetovalikkoon, jolloin lomaketta on saatu yksinkertaisemmaksi.

Mobiilikäyttäjien tarvitsee monesti täyttää vain osa lomakkeesta. Aseta etusijalle pakolliset kentät ja sisällöt ja vältä valinnaisten tai vain joidenkin käyttäjien tarvitsemien kenttien painottamista. KLM:n lentojen seuranta on toteutettu mobiililomakkeella siten, että 151 eri lentokenttää sisältävä alasvetolista on korvattu ennustavalla tekstinsyöttökentällä, johon käyttäjä voi syöttää joko lennon numeron tai lentokentän nimen. Tekstin syöttäminen toimii tässä tapauksessa hyvin, koska käyttäjä tietää aina, mitä lentokenttää etsii.

7. Valitse soveltuva listatyyppi. Listan valinnat on mahdollista toteuttaa kahdella eri tavalla, joko lukitulla alasvetovalikolla (aakkosjärjestyksessä tai satunnaisessa järjestyksessä), tai avoimella ennustavalla tekstihaulla, joista molemmilla on omat hyvät ja huonot puolensa.

Lukittu alasvetovalikko soveltuu tapauksiin, joissa käyttäjä tietää tarkasti mitä etsii, tai sellaisiin tapauksiin, joissa aakkos- tai kronologinen järjestys on luonnollinen, kuten maiden, numeroiden, tai päivämäärien kanssa. Lukittu alasvetovalikko ei sovellu sellaisiin tilanteisiin, joissa valinnat ovat satunnaisessa järjestyksessä, tai käyttäjä ei tarkasti tiedä, mitä valinnat ovat. Näiden lisäksi lukittu alasvetovalikko ei sovellu tilanteisiin, joissa eri vaihtoehdoilla on pitkät kuvaukset, koska kuvaustekstit todennäköisesti katkaistaan automaattisesti.

Avoin ennustava tekstin haku soveltuu tapauksiin, joissa eri vaihtoehdoilla on pitkät kuvaukset, jotka voivat jatkua usealle riville. Jos lista on kovin pitkä, eikä alasvetovalikko sovellu, tai ole järkevästi ryhmiteltävissä tiettyyn järjestykseen, avoin ennustava haku voi olla parempi valinta. Avoin ennustavat haku soveltuu tapauksiin, joissa käyttäjä tietää mitä etsii, ainakin sen verran, että osaa näppäillä muutaman kirjaimen tekstikenttään.

Avointa tekstin hakua käytettäessä kannattaa muistaa, että ennustavan haun listan ei pitäisi olla liian pitkä. Käyttäjä vierittää listaa läpikäydessään alaspäin ja jos hän ei löydä etsimäänsä, hänen täytyy vierittää takaisin ylöspäin tekstikenttään syöttääkseen uudet hakusanat. Pitkän listan läpikäyminen on aikaa vievää ja suuritöistä.

8. Aseta mielekkäät oletusarvot. Tarjoa käyttäjälle mahdollisuuksien mukaan joitakin oletusarvoja sopiviin kohtiin lomakkeilla. Kaikilla lomakkeilla on omat käyttötapauksensa, esimerkiksi junan aikataulujen etsintä lomakkeella käyttäjä todennäköisesti tahtoo etsiä aikatauluja junille, jotka lähtevät samana päivänä alkaen nykyisestä kellon ajasta. Siksi, on järkevää asettaa lähtöajaksi nykyinen päivä ja seuraava lähtevä juna oletusarvoiksi. Mielekkäät oletusarvot ovat minimalistisen suunnittelun perusta.

Yhteenvetona mobiililomakkeiden suunnittelusta Tan (2009) teroittaa: Ensinnäkin, suunnittelijan pitää ymmärtää milloin ja miksi käyttäjät käyttävät mobiililomaketta. Toiseksi pitää tunnistaa lomakkeen ensisijaisen tehtävän sisältö ja/tai kentät. Sen jälkeen on sovellettava edellä mainittuja strategioita parhaan vuorovaikutuksen saavuttamiseksi. Kannattaa muistaa, että ensisijaisena tavoitteena käyttäjällä on saada tehtävänsä suoritettua tehokkaasti ja vaivattomasti.

Lähteet: Tan, C., C., (2011). Forms that work: Designing web forms for usability. Saatavilla: http://www.formsthatwork.com/Mobile-forms

Kontrastit ja värit

Kontrasti tulisi olla riittävä. Värejä ei tulisi koskaan käyttää ainoana koodaustapana. 

Pienten näyttöjen käyttöliittymistä on tullut ubiikki osa nykypäivän yhteiskuntaa. Pieniä näyttöjä löytyy aina digitaalikelloista autojen näyttöihin saakka. Näyttöjen määrästä huolimatta niiden monimutkaisuus ja käytettävyys vaihtelevat runsaasti eri toteutuksissa. Pienten näyttöjen kehittymisessä on nähtävissä useita eri trendejä, laitteiden koko on pienentynyt, laskentateho on lisääntynyt, ohjelmistojen ja käyttöliittymien kompleksisuus on kasvanut ja ominaisuuksien lähentyminen on parantunut. (Mauney, Masterton, 2008).

Pienten näyttöjen suunnittelu perustuu pääasiassa näköaistiin. Suunnittelussa yleisiä ovat kysymykset siitä, kuinka pieniä dataelementtejä voidaan laittaa näytölle, että ne voidaan vielä kunnolla nähdä ja tunnistaa. Tähän seikkaan vaikuttavat valon määrä, silmän anatomia ja herkkyys, sekä tarkkuus. (Mauney, Masterton, 2008).

Visuaalinen tarkkuus tarkoittaa pienintä yksityiskohtaa, jonka silmä voi havaita tietyltä etäisyydeltä. Kohteen visuaalinen terävyys riippuu sen koosta ja sen etäisyydestä katsojaan. Pieni lähellä oleva objekti voi näyttää suuremmalta kuin kauempana oleva suurempi esine. (Mauney, Masterton, 2008).

Monet asiat vaikuttavat tarkkuuteen, kuten valaistus, kontrasti, aika, ja aallonpituus. Yleisesti ottaen, kun valoisuus ja kontrasti lisääntyvät ja aika, joka kohdetta katsotaan, pitenee, tarkkuus paranee.

Värin suurempi kontrasti parantaa tarkkuutta. Punainen väri on helpoiten nähtävissä tilanteessa, kun on vähän kontrastia, seuraavaksi helpoimpia ovat järjestyksessä vihreä, keltainen ja valkea. Noin 8 prosentilla miehistä ja 0,5 prosentilla naisista on jonkinlainen häiriö värien näkemisessä. Yleisin värisokeus on puna-vihersokeus, jolloin henkilö ei erota punaista ja vihreää väriä toisistaan. Tämän vuoksi väriä ei koskaan tulisi käyttää ensisijaisena tapana erottaa kahta eri asiaa. (Mauney, Masterton, 2008).

Lähteet:
Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

Lukeminen pieneltä näytöltä

Pienellä näytöllä kannattaa varata koko näytön leveys tekstin kirjoittamiseen. Pieneltä näytöltä ei ole yhtä helppoa ymmärtää tekstiä kuin suurelta näytöltä.

Pieneltä näytöltä lukeminen on tutkimusten mukaan hieman hitaampaa kuin suurelta näytöltä lukeminen. Kun näytöllä on vain kerrallaan luettavissa vain 1-2 riviä, suoritus on hieman huonompi kuin, jos luettavia rivejä on 4:stä 20:een. Kun näytön rivimäärä nostetaan 1:stä 20:een, lukeminen on ainoastaan 9 % nopeampaa, eikä tekstin ymmärtämisessä ole eroja. (Mauney, Masterton, 2008).

Näytön leveyden vaihtelulla on sen sijaan suurempi merkitys. 1/3 -levyisellä näytöllä lukeminen on 25% hitaampaa kuin 2/3 levyiseltä tai täysleveältä näytöltä. Tämän takia, jos näyttöä käytetään usein tekstin lukemiseen, sen leveydestä kannattaa varata tekstille mahdollisimman paljon tilaa. Tämä löydös tukee myös navigointi- ja muiden kontrollien sijoittamista vertikaalisesti näytöllä. (Mauney, Masterton, 2008).

Kokemusten mukaan käyttäjät lukevat mieluummin suurelta näytöltä ja käyttävät pientä näyttöä vain satunnaiseen lukemiseen. Monesti käyttäjät eivät lue tekstiä pieneltä näytöltä lineaarisesti, vaan enemmänkin silmäilevät sitä ja lukevat vain lyhyitä kohtia. (Mauney, Masterton, 2008).

Nielsen esittelee www-sivuillaan tutkimustuloksen, joka on ristiriidassa sen väitteen kanssa, että tekstin ymmärtämisessä ei ole eroja erikokoisten näyttöjen välillä. Ainakin monimutkaisen tekstin lukemisessa iPhonen näytön kokoiselta näytöltä, käyttäjät saivat 48% vähemmän pisteitä sisällön ymmärtämistä testattaessa kuin tietokoneen näytöltä lukevat käyttäjät. Tämä tarkoittaa, että mobiilin sisällön ymmärtäminen on kaksi kertaa hankalampaa kuin tietokoneen näytöltä. (http://www.useit.com/alertbox/mobile-content-comprehension.html, 2011).

Pieneltä näytöltä lukemisen heikon ymmärtämisen syiksi Nielsen antaa kaksi asiaa: Ensinnäkin, käyttäjät näkevät vähemmän tekstiä annetussa ajassa ja joutuvat luottamaan enemmän muistiinsa. Toiseksi, käyttäjät joutuvat liikuttelemaan ja vierittämään sivuja enemmän. Vierittäminen vie enemmän käyttäjän aikaa ja huomiota itse ongelmasta, sekä aiheuttaa ongelmia edellisen kohdan paikantamisesta sivulla.

Lukemiseen vaikuttavat näytön koon ja vierittämisen lisäksi myös muut seikat, kuten tekstin koko ja tarkkuus.

Lähteet: Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.

Nielsen, J., (2011). Nielsen's Alertbox, February 28, 2011. Www-sivu, saatavilla: http://www.useit.com/alertbox/mobile-content-comprehension.html

Valikot ja niiden suunnittelu

Hierarkkisen rakenteen teossa olisi muodostettava toisensa poissulkevia kategorioita, joissa valinnat sopivat hyvin ainoastaan kyseessä olevaan ryhmään. Otsikoiden pitäisi olla selkeitä ja sisältöä kuvaavia. Käytön yleisyyttä pidetään yleensä parhaana vaihtoehtona järjestää valinnat; muita ovat ”luonnollinen” järjestys (esim. viikonpäivät) tai aakkosjärjestys (valtiot).  Syvempi hierarkia on tehokkaampi kuin laaja hierarkia.

Valikoiden avulla käyttäjä voi valita suuresta määrästä eri vaihtoehtoja. Valikoiden hyvänä puolena on, että käyttäjä voi muistamisen sijaan tunnistaa ja valita tarvittavan toiminnon kirjoittamatta, mikä on hyödyllistä erityisesti silloin, kun laitteessa ei ole täyttä näppäimistöä kirjoittamiseen. (Mauney, Masterton, 2008)

Suunnittelussa tavoitteena on, että käyttäjä löytää haluamansa valinnat nopeasti ja mahdollisimman virheettömästi minimimäärällä näppäilyjä. Useimmiten valikon virheelliset valinnat johtuvat valintojen huonosta luokittelusta, päällekkäisistä luokista tai epäselvistä luokkien otsikoista. (Mauney, Masterton, 2008).

Valikon järjestämisessä pitää tehdä valikon yleisen rakenteen organisointi ja valikon sisäisten valintojen järjestäminen. Tutkimusten mukaan paras tapa valikon järjestyksestä päättämisessä on ottaa käyttäjät mukaan suunnitteluprosessiin. Pyrkimyksenä hierarkkisen rakenteen teossa on muodostaa toisensa poissulkevia kategorioita, joissa ei ole yhteisiä ominaisuuksia ja jotka on selkeästi määritetty niin, että valinnat jokaisessa kategoriassa sopivat hyvin ainoastaan kyseessä olevaan ryhmään. Kategorioiden otsikoiden pitäisi olla selkeitä ja sisältöä kuvaavia. (Mauney, Masterton, 2008)

Valikon sisällä valinnat voidaan järjestää: aakkos- tai aikajärjestykseen, koon mukaan, yhdenmukaisesti (jos samat valinnat ovat useassa eri paikassa, niiden järjestyksen tulisi olla aina sama), kategorioihin ja käytön yleisyyden mukaan (useimmin käytetyt ylös). (Mauney, Masterton, 2008).

Käytön yleisyyttä on monesti pidetty parhaana vaihtoehtona järjestää valikon eri valinnat. Tällainen järjestys voi säästää käyttäjän aikaa ja virheellisiä valintoja, koska syvällä valikkorakenteessa olevia valintoja on usein hankala löytää. Käyttäjät yleensä valitsevat heti ensimmäisenä löytämänsä kategorian, joka voisi sisältää heidän etsimänsä valinnan, joten käytön yleisyyden mukaan lajiteltu valikko helpottaa tällaista etsintää ja myös nopeuttaa jatkuvaa käyttöä. (Mauney, Masterton, 2008)

Jos valinnoilla on jokin ”luonnollinen” järjestys kuten esimerkiksi viikonpäivät, tai kuukaudet, sitä kannattaa hyödyntää. Samoin, jos muualla ohjelmassa on samoja valintoja, niiden järjestys on hyvä pitää yhdenmukaisena. Aakkosjärjestystä hyödyttää käyttää vain, kun valintojen aakkosjärjestys on käytössä vakiintunut, kuten esimerkiksi eri maita sisältävät valinnat. (Mauney, Masterton, 2008)

Valikot voivat olla rakenteeltaan leveitä, jolloin niissä on paljon eri valintoja per kategoria, tai ne voivat olla kapeita, jolloin niissä on vain muutama valinta per kategoria. Valikot voivat olla myös syviä, jolla tarkoitetaan, että niissä on useita alikategorioiden tasoja, tai matalia, jolloin niissä on vain muutama alikategoria. Tätä valikkojen hierarkiaa on tutkittu paljon kirjallisuudessa, pöytätietokoneiden valikoista yleensä leveät hierarkiat ovat tehokkaimpia käyttäjille, erityisesti silloin, kun valinnat ovat selkeitä. Leveät hierarkiat ovat myös parhaita edistyneille käyttäjille. Kuitenkin, tilanteissa joissa virheitä esiintyy paljon, tai ne ovat tuhoisia, kapea hierarkia, joka ohjaa käyttäjiä parhaaseen valintaan voi olla paras valinta. (Mauney, Masterton, 2008)

Lisäksi on tutkittu valikkojen erilaisten muotojen vaikutusta, jolloin huomattiin, että kovera rakenne on navigoinnin kannalta tehokkaampi kuin samankokoinen suhteellisen tasainen valikko. Koveralla valikolla tarkoitetaan, että valikossa on enemmän valintoja ylä- ja alatasoilla kuin keskitasoilla. Tasaisessa valikossa on suurinpiirtein sama määrä valintoja per taso. (Mauney, Masterton, 2008; Jones, Marsden, 2005)

Suurin osa em. tutkimuksista on tehty pöytätietokoneilla, joiden näytöille sopii enemmän tietoa. Jos kaikkia valintoja ei voi näyttää kerralla yhdellä näytöllä, syvyys vs. leveys kompromissi vaihtuu toisin päin. Mauney&Masterton (2008) viittaavat tutkimukseen, jossa aihetta on selvitetty puhelimissa ja pda-laitteissa. Tutkimuksessa havaittiin, että tehokkain hierarkia mobiililaitteissa on vain neljästä kahdeksaan valintaa per taso ja jos paljon valintoja tarvitaan, on parempi kasvattaa tasojen määrää kuin valintojen määrää per hierarkia taso. Siten, syvempi hierarkia on tehokkaampi kuin laaja hierarkia monen tasoisille käyttäjille. (Mauney, Masterton, 2008)

Valikon suunnittelusäännöt Mauneyn & Mastertonin mukaan (2008)

1. Järjestä valikon valinnat toisensa pois sulkeviin kategorioihin, jotka noudattavat tulevien käyttäjien/suurimman osan käyttäjistä hahmottamaa järjestystä.
2. Anna valikoille selkeät otsikot, joista käy hyvin ilmi niiden sisältö.
3. Käytä yksinkertaisia toimintaa kuvaavia verbejä kuvaamaan valintoja.
4. Käytä päätason otsikkoa vaikka otsikkorivillä, kun alivalikon valinta on valittuna.
5. Kun käytetään ympäri kiertävää valikkoa varmista, että käyttäjä tietää milloin valikko on kiertänyt ympäri ja palannut ensimmäiseen kohtaan. Tämän voi tehdä esimerkiksi niin, että sijoittaa ensimmäisen valikon valinnan aina näytön yläreunaan ja kun käyttäjä vierittää valikkoa alaspäin, korostettu valinta siirtyy näytöllä alaspäin ja hyppää taas ensimmäisen valinnan kohdalla näytön alareunasta yläreunaan.
6. Helpota käyttäjien navigointia ylöspäin valikkohierarkiassa. Näin käyttäjä voi nopeasti korjata virheensä, kun hän on valinnut väärän kategorian.
7. Tarjoa käyttäjälle tapa poistua valikosta ilman valinnan tekemistä. Siten käyttäjä voi poistua huomatessaan, että hänen etsimäänsä valintaa ei ole valikossa.

Lähteet: Jones, M., Marsden G., (2005) Mobile Interaction Design. John Wiley & Sons, Ltd.

Mauney, D.W., Masterton, C., (2008). Small-Screen Interfaces in HCI Beyond the GUI. Design for Haptic, Speech, Olfactory and Other Nontraditional Interfaces. Ed. Kortum, P., Morgan Kaufman.