Käytettävyysnavigoija

Ylivoimainen menestys, yksi käyttöliittymä

2012-02-06T12:00:00.001+02:00

Näin iPhone jyrää: katteet 75% koko matkapuhelinsektorista: http://www.macrumors.com/2012/02/03/apples-share-of-profits-among-top-mobile-phone-vendors-hits-75/

Tällainen menestys, vaikka Applen puhelimilla on vain yksi käyttöliittymä.

Muistuupa vain mieleen Nokia joskus aikoinaan. Käyttöliittymiä kehitettiin useita, kun käyttöliittymää käytettiin segmentointitekijänä. Käytettävyysmielessähän tällainen on ihan "hullu" lähestymistapa: käyttöliittymistä tuli itseisarvo käytettävyyden (ja käyttäjäkokemuksen) kustannuksella. Käytännössä tarkoitti muun muassa sitä, että toiset nokialaiset olivat helppokäyttöisempiä kuin toiset.

Tämä filosofia sai siis vallan Nokiassa. Joskus aikoinaan se riitti, mutta kun tuli kilpailua, niin tässä ollaan.

Itse pidän mahdollisena*, että vaikka näistä puhelimista on aikaa vuosia, niin tämä erikoinen paradigma jäi elämään Nokialla viime vuosiin asti - ainakin joidenkin ihmisten mieleen. Ja on osasyynä siihen, että Nokia jäi ratkaisevasti käytettävyydessä jälkeen.

* Tämä on siis tulkintani, ei tutkittua faktaa. Sitä tukee jotkut hajanaiset nokialaisten suusta kuulemat lausumat.

Laatu pakollisiin vaatimuksiin eikä valintakriteereihin tarjouspyynnöissä

2012-01-26T10:16:00.000+02:00

Hupsista! Kirjoitin aluksi tämän jutun tuli vahingossa tähän toiseen blogiini.

Katso kirjoitus Hanki käytettävyyttä! -blogista:
http://hankikaytettavyytta.blogspot.com/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html

(Pahoillani ylimääräisestä klikkauksesta. Ehdin kuitenkin levittää tätä linkkiosoitetta, ja tänne joku lukija saattaa tulla).

Käytettävyysatastrofi, jota käytettävyyden määritelmä ei tunne

2011-12-20T12:36:00.002+02:00

Jeff Sauro siteraa blogissaan Gerry McGovernia, joka määrittelee (käytettävyys)katastrofiksi tilanteen, jossa käyttäjä luulee saavuttaneensa oikean aikaansaannoksen mutta ei olekaan saavuttanut sitä.

Mielenkiintoinen tähän liittyvä näkökulma on se, että käytettävyyden ISO-määritelmä ei kata tällaista tilannetta, koska siinä ei ole attribuuttia "koetulle tuloksellisuudelle".

Olenkin standardointityöryhmissä ottanut esiin, että kun käytettävyyden määritelmää tarkastellaan uudelleen, nykyisiä attribuutteja (tuloksellisuus, tehokkuus, miellyttävyys) laajennettaisiin koetulla tuloksellisuudella ja myös koetulla tehokkuudella.

Katso Jeff Sauron blogi ja kommenttini siihen: http://www.measuringusability.com/blog/ui-disasters.php

Älä laske klikkauksia!

2011-11-17T12:21:00.001+02:00

Niiiiiiiin usein kuulee väitettävän, että hyvä verkkosivusto on sellainen, jossa tarvitsee klikata vähän.

Lienee kuitenkin useimmille alan ammattilaiselle selvää, että näin ei ole. Yksi (verkko-) käytettävyyden peruskirjan nimikin sanoo, mistä on ensisijaisesti kyse: Don't make me think!

Nyt asia on vahvistettu tutkimuksellakin: älä laske klikkauksia vaan mittaa aikaa! Ks. http://www.measuringusability.com/blog/click-clock.php

ISO 9241-210: miten lukea käytettävyyden perusstandardia?

2011-11-15T15:35:00.001+02:00

Käytettävyyden standardit tulivat esiin SIGCHI Finlandin järjestelmässä seminaarissa 10.11.2011, sen loppupaneelin yhteydessä.

Seminaarissa käyttämässäni spontaanissa yleisöpuheenvuorossa kerroin lyhyesti standardien synnystä. Kuitenkin puheenvuoroni oli lyhyt, ja myöhemmin tuli esiin, että sen perusteella saattoi jäädä vajaavainen kuva standardien syntymisestä.

Kerroin puheenvuorossani jotain, miten miten standardiryhmä valmistelee standardia: että työryhmässä keskustellaan, väitellään, tehdään kompromisseja, editorin rooli on iso jne.

Kuitenin se jäi kertomatta, että standardia kehittävä työryhmä ei suinkaan päätä yksin standardin sisällöstä. Ennen hyväksymistä standardiluonnokset käyvät läpi kansalliset lausuntokierrokset, joiden perusteella tehdään tarvittaessa muutoksia.

Mutta standardin tekstiluonnokset ja -muotoilut tuottaa siis työryhmä, ja erityisesti niiden editori. Ja teksti tietenkin jää aika paljon elämään, vaikka kuinka palautetta tulisi kommenttikierrosten aikana.

Kun käänsin ISO 9241-210 standardia (Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelu), niin sen alkuperäisessä englanninkielisessä versiossa oli useampi kohta, joka ei ollut ymmärrettävä tai looginen. Niissä kohdin otin yhteyttä ko. standardin editoriin, joka itsekin huomasi monessa kohdin ongelmia (hankalia ilmaisuja, puuttuvia sanoja, suoranaisia virheitä jne.). Otin sitten nämä huomioon käännöksessä.

Tätä kautta ajateltuna 9241-210:n suomenkielinen käännös on parempi kuin alkuperäinen englanninkielinen...

Yhteenvetona: Kun lukee standardeja, niin seuraavia näkökulmia kannattaa ottaa huomioon:

standardit ovat kompromissien ja äänestysten tulos; eivät siis edusta "totuutta"
kuitenkin niissä kumuloituu laajan kansainvälisen asiantuntijakaartin asiantuntemus ja osaaminen
jotkut asiantuntijat saavat äänensä kuulumaan ja vaikuttamaan paremmin; toiset (ehkä oikeammassakin olevat) voivat joutua antamaan periksi
tekstien muotoiluun (saattaa) vaikuttaa yhden henkilön (editorin) näkemys

Eli standardeja toisaalta kannattaa lukea kunnioituksella, toisaalta kriittisellä silmällä. Esimerkiksi tuo ISO 9241-210 on mielestäni ehdotonta peruslukemista kaikille alan ihmisille.

PS. Olen siis kirjoittanut kirjan Navigoi oikein käytettävyyden vesillä. Se on minun vuosien varrella kumuloitunut näkemykseni käyttäjäkeskeisestä suunnittelusta, ja siinä on paikattu niitä asioita ISO 9241-210:ssä, joihin minun "kriittinen silmäni" on iskenyt.

Mitä eroa käytettävyystestillä ja fokusryhmällä?

2011-11-08T09:48:00.003+02:00

seuraava linkki valaisee hauskasti asian: http://someslightlyirregular.com/2011/08/you-say-potato/

Käytettävyysseminaarin oikea linkki

2011-11-03T10:30:00.002+02:00

onkin tämä: http://www.sytyke.org/toiminta

Maailman käytettävyyspäivän 10.11.2011 seminaari: "Käytettävyys tietojärjestelmien suunnittelussa - mikä tökkii, mitä ratkaisuja?"

2011-11-01T07:59:00.002+02:00

Nykyiset älypuhelimet, jotka on kehitetty miljoonille erilaisille käyttäjillä ovat radikaalisti helpompia käyttää kuin tietojärjestelmät, jodien käyttäjäkunta on yleensä suppea ja hyvin tunnistettu. Miten tämä on mahdollista? Tilannehan pitäisi olla päinvastoin - käytettävyyden suunnittelun keskeinen lähtökohta kun on "tunne käyttäjäsi".

World Usability Day -tapahtuma

Paikka: Haaga-Helia, Ratapihantie 13, Pasila, Helsinki. Luokka 2209

Aika: to 10.11.2011 klo 9:30 - 11:45 (- 12:00)

Tarkemmat tiedot ja ilmoittautuminen: (huom! aiemmin tässä ollut linkki ei toiminut)
http://www.sytyke.org/k%C3%A4ytett%C3%A4vyysosyn-seminaari-10112011-k%C3%A4ytett%C3%A4vyys-tietoj%C3%A4rjestelmien-suunnittelussa-mik%C3%A4-t%C3%B6kkii-mit%C3%A4

Käytetttävyyssuunnittelun perustandardi ISO 9241-210 ilmestynyt suomeksi

2011-10-21T09:11:00.000+03:00

ISO 9241-210 kuvaa käytettävyyssuunnittelun ("Vuorovaikuittesten järjestelmien käyttäjäkeskeisen suunnittelun") keskeiset käsitteet, periaatteet ja aktiviteetit. Sisältää esimerkiksi käyttäjäkokemuksen määritelmän. Korvaa aiemman, hyvin tunnetun standardin ISO 13407.

Standardia saa SFS:ltä: http://sales.sfs.fi/servlets/ProductServlet?action=showquicksearch&keywords=9241-210&x=24&y=15 (standardithan pitää ostaa).

Standardi on periaatteessa suunnattu "laite- ja ohjelmistokehityksen sekä uudelleensuunnittelun prosesseista vastaaville henkilöille", mutta on ehdottoman suositeltavaa peruslukemista myös käytettävyysasiantuntijoille ja käyttöliittymäsuunnittelijoille.

Olin itse mukana valmistelevassa työryhmässä. Vaikka standardi on siis tärkeää peruslukemista alan ammattilaisille, kannattaa ottaa huomioon, että tämä(kin) standardi on osaltaan kompromissi, ja sitä tulee tarkastella myös kriittisesti. Standardi sisältää hyvin keskeisiä asioita, mutta omasta mielestäni siihen jäi myös ongelmakohtia (käyn läpi standardia blogissa http://iso9241-210.blogspot.com/).

- Tein itse standardin peruskäännöstyön, jota sitten viimeisteltiin MetStan kanssa. Palautetta käännöksestä otan mielelläni vastaan, ja kysymyksiä saa esittää.

Älä kysy näitä asioita käyttäjiltä

2011-10-11T19:44:00.000+03:00

Yksi käytettävyysalan guruja on Jared Spool. Persoonallinen kaveri ja tosi hyvä esiintyjä.

Kävin - tai käytiin porukalla - hänen kurssillaan joskus Nokialla ollessani joskus ammoin (vuonna 1995), aiheena paperiprotoilu. Se kurssi opetti paljon. Väitän muuten, että paperiprotoilulla oli ratkaiseva merkitys sille, että aikanaan Nokia oli käytettävyydessä markkinoiden ykkönen (ks. slide show paperiprotoilusta).

Nyt Jared kirjoittaa aiheesta "kolme kysymystä, mitä ei tulisi kysyä käyttäjätutkimuksessa": http://www.uie.com/articles/three_questions_not_to_ask/

Ja ottaa esiin seuraavat asiat:

älä kysy käyttäjältä tulevaisuudesta
älä kysy, kuinka käyttäjä suunnittelisi jonkun toiminnon (oma huomautus: tämä kiusaus tulee kovin helposti käytettävyystesteissä tai palavereissa käyttäjien kanssa)
älä kysy siten, että tarjoat valmista ehdotusta syyksi

Nämä kaikki hyviä pointteja. Mutta eivät kaikki välttämättä uusia. Osallistuin CHI-konferenssin tutoriaaliin käyttäjien haastattelusta vuonna 1996. Pitäjänä Eileen Isaac. Hän toi esiin osittain samat asiat. Eli älä kysy käyttäjiltä:

mitä he tekisivät hypoteettisissa tilanteissa (vastaa tuota "älä kysy käyttäjältä tulevaisuudesta")
kuinka usein käyttäjät tekevät asioita
milloin he tekivät viimeksi jonkin asian
paljonko he pitävät jostain asiasta absoluuttisella skaalalla

Ja minä lisäisin tähän vielä oman mausteeni:

kun kysyt, älä tyydy sellaiseen vastaukseen, jota et ymmärrä

Älä laita käyttäjiä jäsentämään työtään!

2011-10-07T09:47:00.000+03:00

Mikä on toimiva tapa ottaa käyttäjät mukaan järjestelmänkehitysprojektiin? Asia tuli taas esiin neuvottelussa asiakkaan kanssa.

Aluksikin, on mielestäni myytti, että järjestelmänkehitysprojekteissa eivät käyttäjät olisi mukana, eikä käyttäjiä kuunnella. Kyllä minun havaintoni on se, että projekteissa kannetaan huolta siitä, että käyttäjät ovat mukana, käyttäjiltä kysellään jne.

Silti tulokset ovat mitä ovat. Käytettävyys tökkii enemmän tai vähemmän.

Kyse ei ole siitä, että käyttäjät eivät olisi mukana, tai että käyttäjiltä ei kyseltäisi. Jopa väitän, että syyt käytettävyysongelmiin ovat osaltaan juuri siinä, että käyttäjät ovat mukana - mutta siinä "väärässä" roolissa, missä ovat tänä päivänä.

Tänä päivänä käyttäjät otetaan mukaan projekteihin rooleissa, jotka eivät toimi.

MIkä on sitten ongelma käyttäjien rooleissa? Tiivistäisin asian siten, että ongelma on se, että käyttäjille annetaan vastuu tarpeitteinsa ja työnsä jäsentämisestä.

Oman työn ja tarpeiden jäsentäminen on vaativaa työtä. Ja väitän, että käyttäjiä ei aidosti kiinnosta laittaa omia resurssejaan sellaiseen asiaan, joka ei ole heidän varsinaista työtään. Toki kyse on myös osaamisesta - työn jäsentäminen vaatii oman ammattitaitonsakin.

Työ jäsentäminen on haastavaa, "aivoresursseja" kuluttavaa työtä. Ja sellaiseen työhön pitää aidosti pinnistellä. Jos nyt tätä tekee "velvollisuudesta jonkin verran", niin ei ihme, jos lopputulos ei ole laadukas.

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

Esimerkki: Otetaanpa esimerkiksi se, että joku olisi kehittämässä uutta sähköpostiohjelmaa.

Kaikki me olemme sähköpostiohjelman käyttäjiä; joillekin voi olla hyvinkin keskeinen työkalu. Niinkuin minullekin.

Mutta jos joku tulisi haastattelemaan minulta tyyliin "millaisen sähköpostiohjelman haluat?", "mitä toiminnallisuuksia siinä pitäisi olla?", "miten nykyistä voisi parantaa?", "pitäisikö olla sitä ja tätä ominaisuutta?" jne. niin voin suoraan sanoa, että ei kiinnosta alkaa pohtia vastauksia tällaisiin kysymyksiin. Minua kiinnostaa hyvä sähköpostiohjelma, mutta sen kehittäminen ei ole minun päänsärkyni.

Minä uskon, että samalla tavalla suhtautuisi haastatteluun moni teistä lukijoistakin. (Vai olenko väärässä?)

Joka tapauksessa, jos kehittäjät perustavat suunnittelunsa sille, mitä minä sanon tällaisessa haastattelussa, niin heikoilla ovat.

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

Nyt kuitenkin kokemukseni mukaan järjestelmänkehityshankkeissa käyttäjiä laitetaan juuri tämän tyyppisiin rooleihin. Jäsentämään omaa työtään. Mikä taas ei ole heidän työtään.

Itse teen työkseni käyttäjien työn jäsennystä, mutta kun juuri sähköpostin kehittäminen ei erityisesti ole minun työtäni, niin resurssieni laittaminen siihen - ei kiitos!

Eli yhteenvetona näkemykseni ja suositukseni on: Käyttäjien työn jäsennys on järjestelmän kehityksestä vastaavien työtä, ei käyttäjien. Sen sijaan käyttäjille sopiva rooli on olla tiedon lähteenä.

Mitä tämä tarkoittaa menetelmällisesti, siitä myöhemmin enemmän.

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

PS. Tätä näkemystä tukee myös tuleva väitöskirja terveydenhuollon järjestelmien käytettävyydestä, jossa muun muassa tutkittiin sitä, missä rooleissa lääkärit haluaisivat olla mukana järjestelmien kehittämisessa. Mutta enpä kerro tästä enempää; Johanna Kaipio väittelee aiheesta Aalto-yliopistossa myöhemmin syksyllä (itse toimin esitarkastajana ja sitä kautta minulla etukäteistietoa)

Käyttäjäkokemuksen määritelmä ei osu ihan kohdalleen

2011-09-29T07:58:00.001+03:00

Käyttäjäkokemuksen keskeinen ja aika uusi (2010) määritelmä ISO 9241-210:ssa kuuluu seuraavasti (epävirallinen suomennos; standardin suomennus pitäisi ilmestyä piakkoin; ks. myös blogi koko standardista http://iso9241-210.blogspot.com):

"Käyttäjäkokemus: Henkilön havainnot javasteet, jotka ovat seurausta tuotteen, järjestelmän tai palvelun käytöstä ja/taiennakoidusta käytöstä".

Tämä on tarkennettu huomatuksilla:

"HUOM. 1 Käyttäjäkokemus sisältää kaikki käyttäjien tunteet, uskomukset,mieltymykset, fyysiset ja psyykkiset vasteet, käyttäytymiset jaaikaansaannokset, jotka ilmenevät ennen käyttöä, käytön aikana ja käytönjälkeen.

HUOM. 2 Käyttäjäkokemus on seurausta tuotemerkin imagosta, ulkonäöstä,toiminnallisuudesta, järjestelmän suorituskyvystä, järjestelmän vuorovaikutuskäyttäytymisestäja avustavista ominaisuuksista, käyttäjän aiemmasta kokemuksesta johtuvastasisäisestä ja psyykkisestä tilasta, asenteista, taidoista, persoonallisuudestasekä käyttötilanteesta.

HUOM. 3 Käytettävyys käyttäjien henkilökohtaisten tavoitteidennäkökulmasta tulkittuna voi sisältää sen tyyppisiä aisti- ja tunnenäkökulmia,joita tyypillisesti liitetään käyttäjäkokemukseen. Käytettävyyskriteereitävoidaan käyttää arvioimaan käyttäjäkokemuksen joitakin näkökulmia."

-------------------
Olin työryhmässä, jossa valmisteli tätä standardia ja vaikuttamassa myös määritelmän muotoiluun. Nyt jälkikäteen ajateltuna, mielestäni määritelmässä ei ihan osuttu kohdalleen.

Tuo määritelmä tekee käyttäjäkokemuksesta liian "kaiken kattavan". Erityisesti jos lukee sen, mitä HUOM 1:ssä sanotaan. Siinä erityisesti kohta "Käyttäjäkokemus sisältää... käyttäjien... aikaansaannokset,..." on se, joka ei semanttisesti oikein istu hyvin kokemus-sanaan. Aikaansaannoshan tarkoittaa jotain konkreettista, mitä käyttäjä saavuttaa. Vaikkapa jos tilaa lentolipun verkosta, niin aikaansaannos on se lentolippu.

Käyttäjäkokemus terminä viittaa kuitenkin semanttisesti subjektiiviseen, psyykkiseen asiaan (kokemus). Ei lentolippu (aikaansaannos) ole itsessään kokemus. Sen sijaan lipun tilaamiseen voi liittyä kokemuksia ("olipa helppoa!" tms.).

Yhteenvetona: Käyttäjäkokemuksen määritelmä on tehty turhan laajaksi ISO 9241-210 määritelmässä. Termit pitäisi määritellä niin, että määritelmä vastaa semanttisesti itse termiä. Nyt "kokemukseen" liitetään asioita, jotka eivät ole "kokemuksia". Olisi selkeämpää, että käyttäjäkokemus määriteltäisiin kattamaan vain "kokemuksellisia" asioita. Aikaansaannokset katetaan hyvin käytettävyyden määritelmässä (ISO 9241-11).

Älä laita tietokonetta leikkimään ihmistä

2011-09-16T08:46:00.001+03:00

Kävin viikolla toisessakin mielenkiintoisessa tilaisuudessa, kuntamarkkinoilla http://www.kuntamarkkinat.fi/

Siellä esiteltiin mm. suomi.fi -sivustoa. Sivustossa siellä täällä näkyy ihmishahmo (hahmolla oli jokin nimikin, en nyt muista sitä):

Tällainen suunnitteluratkaisu ei edusta käyttäjäystävällisyyttä. Ei ole suositeltavaa, että tietokone "leikkii" ihmistä. Suuri osa käyttäjistä vain ei pidä tällaisista ideoista. On se hahmo sitten aidomman näköinen ihminen tai vaikka windows-tyyppinen paperiliitin:

Tämä ei ole (pelkästään) oma näkemykseni, vaan sitä tukevat tutkimukset.

Muunmuassa Shneidermannin käyttöliittymäalan perusoppikirjassa http://www.pearsonhighered.com/educator/academic/product/0,3110,0321537351,00.html on oma alalukunsa "ei - ihmisen kaltaisesta" (nonanthropomorphic) suunnittelusta. Tutkimukset kertovat, että ihmisen kaltaiset suunnitteluratkaisut "amused some, but annoyed many".

Ei ole siis suositeltavaa, että suunnitellaan tietokone "leikkimään" ihmistä.

Älä usko mitä käyttäjät sanovat (paitsi joskus)

2011-09-14T10:56:00.000+03:00

Olin kuuntelemassa mielenkiintoista esitystä PKT:n aamuseminaarissa http://www.pkt.fi/asiantuntijapalvelut/aamu-matinea/aamu-matineasyyskuu/, pitäjänä Sirpa Juutinen, PricewaterhouseCoopers.

Sirpan aihe sivusi asiakastarpeiden ymmärtämistä. Sirpa sanoi muunmuassa että

"pitää pystyä hahmottamaan asiakkaan tarve... asiakas voi odottaa asiaa b, mutta pyytää palvelua a, joka ei johda b:hen" (ei ehkä ihan sanatarkasti mutta suunnilleen näin)

Pitää siis nähdä asiakkaan sanojen taakse, ja tarjota oikeaa palvelua tai ratkaisua.

Tämä sama pätee tismalleen myös käyttäjien tarpeiden ymmärtämiseen. Käyttäjät voivat

sanoa jotain, joka ei ole se tarve
tai voivat olla sanomatta jotain, joka on se tarve
ja joskus ehkä sitten niinkin, että se mitä käyttäjät sanovat, on se tarve.

Keskeistä käytettävyysosaamista on se, että selvittää käyttäjän tarpeet, riippumatta siitä miten käyttäjä ne ilmaisee.

kirjoituksia Hanki käytettävyyttä! -blogissa

2011-09-07T10:13:00.003+03:00

Olen viime aikoina kirjoitellut Hanki käytettävyyttä! -blogiin, http://hankikaytettavyytta.blogspot.com/

Kyseisen blogin erityinen näkökulma on käytettävyyden varmistaminen tietojärjestelmien hankinnoissa. Mutta siinä on ehkä kiinnostavaa käytettävyysasiaa yleisemminkin. Viime kirjoitukset käsittelevät käytettävyysvaatimuksia ja käytettävyyden validointia.

muutama käytettävyysongelmaharjoite

2011-08-22T15:15:00.006+03:00

Seuraavassa muutama suunnitteluongelma, joihin vastikään törmäsin (kun siis olin täyttämässä ko. lomakkeita). Mitä ongelmia, ja miten ratkaisisit?

tarkempi kuva yo. dialogista:

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

2011-08-10T16:37:00.000+03:00

Ei riitä, että tutkimus tuottaa uutta tietoa. Uuden tiedon on oltava myös hyödyllistä.

Viime vuosikymmenellä tehtiin eräs käyttöliittymäalan tutkimus, jonka tuloksena muun muassa todettiin, että kännykässä on valikko (suurinpiirtein näin).

Onko tällaisella tutkimustuloksella merkittävyyttä? Tiedän, että moni ajatteli tuolloin, että tuloshan on itsestään selvä. Tutkijan näkökulmasta tulosta kuitenkin saattoi perustella siten, että kukaan ei ollut asiaa systemaattisesti tutkinut aikaisemmin, ja että tässä sen vuoksi tuotettiin uutta tietoa.

Usein näkeekin mainittavan tutkimuksen kriteerinä sen, että tulee tuottaa uutta tietoa.

Tämän postaukseni idea ei ole pohtia sitä, että oliko tulos "kännykässä on valikko" uutta tietoa vai ei. Sen sijaan haluan nostaa esiin kysymyksen siitä, että onko uuden tiedon tuottaminen riittävä kriteeri käytettävyystutkimukselle (ja yleensäkin tutkimukselle). Ja tämä esimerkki mielestäni valaisee tätä asiaa erinomaisesti.

Ajatellaanpa, mitä hyötyä yllä mainitusta tutkimustuloksesta ("kännykässä on valikko") oli/ olisi ollut Nokialle? Tai jollekin muulle toimijalle? Vastaus on kai ilmeinen: ei yhtään mitään. Voiko tällaisen tulokseen reagoida juuri muuten kuin että "kännykässä on valikko... so what?". Ei tällainen tutkimustulos ainakaan Nokiaa (olisi) auttanut olemaan Applea edellä käytettävyysasioissa.

Ei riitä, että tutkimus tuottaa uutta tietoa. Uuden tiedon on oltava myös hyödyllistä.

Jos edellä mainittu tutkimus olisi tuottanut sen tyyppisiä kuten "valikko on hyvä ratkaisu kännyköissä", tai että "valikot ovat jossakin tilateissa hankalia käyttää, ja pitäisi kehittää jotain parempaa", niin näistä olisi ollut ihan eri tavalla hyötyä. Toisaalta tällaisten asioiden selvittäminen olisi tietenkin ollut tutkimuksellisesti paljon haastavampaa.

Yllä mainittu esimerkki oli akateeemisesta tutkimuksesta. Mutta sama pätee tietenkin myös lähempänä käytäntöä olevaan tutkimukseen. Käytettävyyssuunnittelussakin olisi keskityttävä toimenpiteisiin, joiden hyödyllisyys on aidosti merkityksellistä. Yhdessä käytettävyyden keskustelufoorumissa on esillä kysymys "Which should be used: Login, Log in, Logon, Log on?" (keskustelu näyttää näkyvän avoimesti!) Tämän tyyppisten asioiden selvittämiseen tuskin kannattaa laittaa merkittäviä resursseja.

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

2011-08-03T11:43:00.001+03:00

Näin kesälomien päättyessä kertaus perusasioihin. Onko aito, oikea käytettävyyden määritelmä joskus hukassa? (ainakin itse joudun sanatarkkaa 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ävyyden määritelmä on ISO 9241-11 englannin kielisen version mukaan: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

ISO 9241-11 virallinen - ja suositeltava - suomenkielinen käännös on: Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi.

Edelleen määritellään käytetyt termit:

• Käyttäjä: Henkilö, joka on vuorovaikutuksessa tuotteen kanssa.

• Tavoite: Tarkoitettu lopputulos.

• Tuloksellisuus: Tarkkuus ja täydellisyys, jolla käyttäjät saavuttavat määritetyt tavoitteet.

• Tehokkuus: Voimavarojen käyttö suhteessa tarkkuuteen ja täydellisyyteen käyttäjien saavuttaessa tavoitteet.

• Tyytyväisyys: Epämukavuuden puuttuminen ja myönteinen suhtautuminen tuotteen käyttöön.

• Käyttötilanne: Käyttäjät, tehtävät, laitteet (laitteisto, ohjelmisto ja aineistot) sekä fyysinen ja sosiaalinen ympäristö, jossa tuotetta käytetään.

(Esimerkiksi suomenkielisessä wikissä määritelmä on käännetty hieman erilailla: Se vaikuttavuus, tehokkuus ja tyytyväisyys, jolla tietyt määritellyt käyttäjät saavuttavat määritellyt tavoitteet tietyssä ympäristössä).

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

Määritelmän keskeinen ajatus on siis se, että käytettävyydessä on kyse siitä, miten tuote tukee käyttäjän tehtäviä ja työtä. Eikä siis esimerkiksi erityisesti siitä, minkä näköinen käyttöliittymä on (tämä harhakäsitys jatkuvasti tulee vastaan).

Määritelmä on keskeinen, paljon viitattu ja omasta mielestäni perussisällöltään hyvä. Mutta tämäkään määritelmä ei tietenkään ole mikään totuus.

Määritelmästä ja sen edelleen kehittämisestä keskustellaan standardointipiireissä. Ja on joitakin näkemyksiä - myös itselläni - miten määritelmää voitaisiin kehittää.

Palaan noihin kehittämisajatuksiin myöhemmin. Mutta ensin kysyisin, että onko teillä lukijat ajatuksia, kokemuksia tai ehdotuksia määritelmään liittyen? Mikä hyvää, mikä mättää, mitä puuttuu, mikä epäselvää tms?

Käyttäjätarpeet, -toiveet ja -vaatimukset. Mikä ero?

2011-06-28T10:40:00.012+03:00

Eräässä keskusteluryhmässä esitettiin käyttäjälähtöisyyteen kysymyksiä: "Mikäs on hyvä tapa löytää käyttäjävaatimuksia?" Ja "Mikä on paras tapa tietää millaista palvelua/laitetta/työkalua käyttäjät kaipaavat?"

On tärkeää, että termit määritellään niin, että ne ymmärretään ainakin kutakuinkin samalla tavalla. Ja mielellään niin, että ne ovat sisällöllisesti kuvaavia.

Yllä on kaksi käyttäjälähtöisyyteen liittyvää termiä: käyttäjävaatimukset ja mitä käyttäjät kaipaavat. Muita näitä lähellä olevia termejä ovat esimerkiksi käyttäjätarpeet ja käytettävyysvaatimukset.

Itse tulkitsen termit seuraavasti:
- Käyttäjävaatimukset: ovat käyttäjän esittämiä (sanomia tai kirjoittamia) vaatimuksia järjestelmälle. Käyttäjä voi esittää näitä esimerkiksi silloin, kun häntä haastatellaan.
- Käyttäjätoiveet, tai "mitä käyttäjät kaipaavat" ovat samantyyppisiä kuin vaatimukset, mutta termit tietenkin viittaavat siihen, että ovat "pehmeämpiä" kuin vaatimukset. Lisäksi tulkitsen, että näihin termeihin voi liittyä se, että käyttäjät eivät välttämättä ole ilmaisseet näitä toiveitaan
- Käyttäjätarpeet: ovat niitä "perimmäisiä" asioita, joiden perusteella järjestelmä olisi suunniteltava. Eli ne antavat perustan sille, mitä järjestelmän viime kädessä tulisi tehdä.

Näissä on se oleellinen ero, että

* Käyttäjävaatimukset ja käyttäjätoiveet /-kaipaukset ovat käyttäjien itsensä jäsentämiä asioita
* Käyttäjätarpeet ovat suunnittelutiimin jäsentämiä johtopäätöksiä käyttäjien ilmaisemista vaatimuksista, toiveista ja muista käyttäjälähtöisistä tietolähteistä (esimerkiksi havainnointi).

Eron tekee oleelliseksi se, että käyttäjien itsensä ilmaisemien asioiden laatu riippuu siitä, kuinka hyvin juuri kyseiset käyttäjät sattuvat jäsentämään tarpeitaan tai toiveitaan. Ja oma kokemukseni on se, että asioiden jäsentäminen on varsin haastavaa monelle käyttäjälle. Eli käyttäjä voi pukea sanoiksi jotakin ja tarkoittaa jotakin ihan muuta. Tai jättää pois jotakin oleellista tai korostaa jotakin turhaa. Ja jos suunnittelutiimi luottaa suoraan käyttäjien lausumiin, niin on suuri riski, että pieleen mennään. (Itse asiassa muistaakseni jo 80-luvulla tiedettiin, että jos suunnittelee ohjelmiston asiakkaan vaatimusten mukaan, niin asiakas ei tule olemaan siihen tyytyväinen).

Käyttäjätarpeiden määrittäminen taas riippuu suunnittelutiimin jäsentämiskyvystä. Siihen sitten liittyy se vastuu ja riskiotto, että ei tehdäkään oikeita tulkintoja ja jäsennyksiä. Mutta minun mielestäni tämä on kuitenkin se tie, joka suunnittelutiimin - tai vaikka käytettävyysasiantuntijan - olisi valittava. Olen nähnyt sellaisia käyttäjätutkimusraportteja, jossa tätä askelta ei ole otettu. Mielestäni tällainen ei edusta ammattimaisuutta vaan on vastuun pakoilua.

(Käytettävyysvaatimuksia ei käsitellä tarkemmin tässä kirjoituksesssa)

Mitä ovat käytettävyysvaatimukset?

2011-06-14T15:41:00.000+03:00

Käytettävyysvaatimusten tulisi olla todennettavia, valideja ja kattavia. Tällaiset vaatimusten määrittäminen käytännössä tarkoittaa käyttäjän suoriutumiseen perustuvia vaatimuksia: tulee määritää riittävän kattavasti käyttäjätehtävät ja -tavoitteet, sekä käyttäjän suoriutumista kuvaavat mittarit, mittausinstrumentit ja tavoitetasot.

Käytettävyysvaatimuksista on vastikään keskusteltu eri käytettävyysfoorumeissa. Muunmuassa CreaBasen seminaarissa Kajaanissa toukokuussa ja nyt KäytettävyysOSY:n LinkedInin keskusteluryhmässä.

Käytettävyysvaatimusten määritys tulisi olla käytettävyysohjatun vuorovaikutussuunnittelun keskeinen aktiviteetti. Aktiviteetissa asetetaan tavoitteet kehitettävän sovelluksen käytettävyydelle: kuinka hyvää käytettävyyttä tavoitellaan.

Käytettävyysvaatimusten määrityksellä on periaatteessa kaksi tarkoitusta:

vaatimukset toimivat käyttöliittymän suunnittelua ohjaavina suunnitteluajureina (”drivereina”): kun suunnittelijat tietävät tavoitteet, joiden perusteella suunnitteluratkaisujen laatua arvioidaan, ne ohjaavat suunnitteluratkaisuja oikeaan suuntaan
vaatimukset muodostavat kriteerit käytettävyyden todentamiselle: todentamisessa saatuja tuloksia verrataan määriteltyihin käytettävyystavoitteisiin

Kun keskustellaan jostakin asiasta niin on tärkeää, että on yhteinen ymmärrys siitä, mitä käytetyillä termeillä tarkoitetaan. Ja kun puhutaan käytettävyysvaatimuksista, keskeinen termi on tietenkin "käytettävyysvaatimus".

Lehtonen & al (2010) tutkimuksessa löydettiin kolmen eri tyyppisiä käytettävyyteen liittyviä vaatimuksia. Vaatimukset liittyvät

1. suunnitteluohjeistojen noudattamiseen
2. suunnittelukäytäntöihin ja -resursseihin
3. käyttäjän suoriutumiseen

Mutta ovatko nämä kaikki aidosti käytettävyysvaatimuksia? Vai vain osa niistä? Mitä itse asiassa on käytettävyysvaatimus?

Tässä kirjoituksessa jäsennetään sitä, mikä on käytettävyysvaatimus - ja mikä ei. Joka ei jakas lukea loppuun asti, niin yhteenvetona on se, että lähinnä käyttäjän suoriutumiseen perustuvat vaatimukset ovat "aitoja" käytettävyysvaatimuksia.

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

Mitä on käytettävyysvaatimus? Periaatteessahan asia on yksinkertainen: käytettävyysvaatimukset ovat sellaisia, että kun ne täyttyvät, niin tuote (järjestelmä, palvelu) on käytettävyydeltään "hyvä" (= halutun tasoinen). Mutta kun käytettävyysvaatimuksia lähtee tarkemmin jäsentämään, niin kyseessä ei olekaan ihan yksinkertainen juttu.

Vaatimuksia vaatimuksille

Kirjallisuudesta löytyy paljonkin vaatimuksia vaatimuksille - siis mikä tekee vaatimuksesta "hyvän". Keskeisiä kriteereitä ovat:

1. Vaatimuksen on oltava todennettava: vaatimuksen saavuttaminen voidaan objektiivisesti testata.
2. Vaatimus on oltava validi: vaatimus on sisällöltään oikea
3. Vaatimukset on oltava kattavat: ne kattavat koko tuotteen (järjestelmän, palvelun) riittävän laajalti

Nämä "vaatimukset vaatimuksille" ovat aika kinkkisiä, kun puhutaan käytettävyydestä.

1. Todennettavuus

Todennettavuus liittyy vaatimuksen yksikäsitteisyyteen. Todennettavuus siis tarkoittaa sitä, että vaatimus on määritelty siten, että sen saavuttaminen - tai että sitä ei saavuteta - voidaan todentaa objektiivisesti. Tämä on oikeastaan "vaatimuksen perusvaatimus": jos vaatimus ei ole todennettava, se ei ole vaatimus.

Todennettavuus käytännössä sulkee pois laadulliset vaatimukset (vaatimukset tyyliin, että pitää olla "helposti opittava"; "nykyaikainen käyttöliittymä"; "suunniteltu käyttäjäkeskeisesti"...). Sen vuoksi yllä luetelluista vaatimustyypeistä suunnitteluohjeiden noudattaminen ei tyypillisesti ole todennettava vaatimus, koska useimmat suunnitteluohjeet ovat laadullisia.

Käytännössä todennettavan vaatimuksen saavuttaminen on objektiivisesti mitattavissa jollakin skaalalla. Yksinkertaisimmillaan skaala on kaksiarvoinen (kyllä/ei). Joka tapauksessa, todennettavaa vaatimusta varten on määritettävä mittarit, mittausinstrumentit ja tavoitetasot.

2. Validiteetti

Validiteetti ottaa kantaa vaatimusten sisältöön. Validit vaatimukset tarkoittavat sitä, että ne ovat sisällöllisesti oikeat. Validi käytettävyysvaatimus on sellainen, että kun se täyttyy, niin lopputuloksena on tuote (järjestelmä, palvelu), joka aidosti on käytettävyydeltään "hyvä". Epävalidi vaatimus on taas sellainen, että vaatimus voi täyttyä, mutta silti käytettävyys voi olla "huono".

Validit vaatimukset tulisi määrittää sellaisiksi, jotka kuvaavat juuri kyseisen järjestelmän haluttua ja järkevää käytettävyyttä. Jos esimerkiksi sovelluksen käyttö perustuu vapaaehtoisuuteen, niin käyttäjätyytyväisyys on kriittistä (muutenhan järjestelmää ei käytetä); toisissa tapauksissa käytettävyysongelmat on ehkä mahdollista ratkaista vaikka koulutuksella. Joissakin tapauksissa kriittisiä käyttäjätehtäviä on muutama, toisissa kymmeniä. Joissakin tapauksissa virheiden seuraukset ovat pahemmat kuin toisissa. Joissakin tapauksissa päähyöty tulee tehostuneina työprosesseina, toisissa käyttäjätuen tarpeen vähenemisenä, kolmansissa ehkä koulutussäästöinä. Jne.

Alussa mainituista kategorioista:

suunnitteluohjeistovaatimukset ovat periaatteessa valideja (mutta eivät yleensä todennettavia)
suunnittelukäytäntö- tai resurssivaatimukset eivät ole valideja (= ne voivat täyttyä, mutta silti lopputulos voi olla käytettävyydeltään ongelmallinen)
käyttäjän suoriutumiseen perustuvat vaatimukset ovat valideja (oikein määritettyinä)

3. Kattavuus

Kun käytettävyysvaatimukset ovat kattavat, ei jää "käytettävyysaukkoja". Kattavuus on tietenkin haastava asia, ja täydelliseen kattavuuteen tuskin yleensä päästään. Joka tapauksessa, tulisi pyrkiä määrittämään kattavasti käyttäjätehtävät ja -tavoitteet

"Haluttu käytettävyysvaikuttavuus": perusta käytettävyyden suunnittelulle

2011-06-09T16:26:00.001+03:00

Käytettävyysohjatun vuorovaikutussuunnittelun prosessia kuvaavan JFunnel-mallin (Jokela 2010) ensimmäinen aktiviteetti on "strategisten käytettävyystavoitteiden määritys". Sen tarkoitus kuvataan: "Strategisten käytettävyystavoitteiden tarkoituksena on määrittää, miten sovelluksen käytettävyyden halutaan tukevan liiketoimintaa (tai organisaation toimintaa). Strategiset käytettävyystavoitteet määrittävät ”liiketoiminnan kielellä”, mitä hyvä käytettävyys tarkoittaa".

Olen tullut siihen tulokseen, että "strateginen käytettävyystavoite" ei ehkä ole paras mahdollinen termi: se ei semanttisesti kerro kovin selvästi, millaisesta aktiviteetista on sisällöllisesti kyse. Kuvaavampi termi tälle asialle on "käytettävyysvaikuttavuus". Ehkä tämäkään termi ei kuullosta kovin elegantilta, mutta asiallisesti tästä on kyse: aktivitetissa kun nimenomaisesti tulisi määrittää, mitä liiketoiminnallista vaikuttavuutta käytettävyydeltä halutaan. (Englanniksi termi on elegantimpi: "usability impact".)

Käytettävyyden vaikuttavuus on valintakysymys. Se, millaista vaikuttavuutta halutaan, riippuu sovelluksesta mutta on myös business-valinta. Vaikuttavuus voi olla erilaista niin laadultaan kuin tasoltaan, riippuen casesta. Esimerkiksi yhdessä julkisen hallinnon sovelluksessa määritettiin erääksi keskeiseksi käytettävyysvaikuttavuudeksi se, että "turhat" puhelut asiakkailta vähenevät merkittävästi (koska niihin menee paljon virkailijoiden aikaa). Vaikuttavuuden taso määritettiin myös numeerisesti.

Käytettävyystoimenpiteiden määrä ja laatu sitten riippuu tästä halutun vaikuttavuuden laadusta ja tasosta. Jos sovellus ja businessvalinta ovat sellaisia, että potentilaalisesti saavutettavat vaikuttavuudet eivät ole merkittäviä, niin vaikeapa silloin voi olla perustella käytettävyystoimenpiteitä. Esim. julkisissa kilpailutuksissa on usein niin, että asiakas ei tarjouspyynnöissä aidosti edellytetä käytettävyyttä. Eipä silloin ole paljon perusteita softantekijöille otta käytettävyttä huomioon (itse asiassa tarkoittaisi vain tarjouksen kilpailukyvyn heikkenemistä).

Eli korjattu versio kirjan tekstiin:

"Aktiviteetin otsikko: 0. Haluttu käytettävyysvaikuttavuus

Halutun käytettävyysvaikuttavuuden (desired usability impact) määritys on aktiviteetti, jota ei yleensä käytettävyyssuunnittelun lähteissä tuoda esiin. Toki on kirjallisuutta liittyen käytettävyydellä saavutettaviin etuihin (Bias and Mayhew 1994), mutta vähemmän siitä, miten määrittää etuja tavoitteellisesti. Käytettävyyden vaikuttavuus on tietoinen valinta - sen vuoksi puhutaan halututusta vaikuttavuudesta - eikä laskennallisesta "mitä kaikkia etuja käytettävyydellä voi saavuttaa".
Taustana tämän aktiviteetin sisällyttämiseen on se tosiasia, että käytettävyys on jatkuva, ei ”on/off” –suure. Sen vuoksi käytettävyydelle tulisi määrittää tavoitetaso: kuinka hyvää käytettävyyttä halutaan. Ja tällainen tason määritys periaatteessa ei voi perustua muuhun kuin niihin strategisiin valintoihin, joita liiketoiminta tai organisaatio tekee.

Tarkoitus

Haluttu käytettävyysvaikuttavuus määrittää, miten ja missä määrin sovelluksen käytettävyyden halutaan tukevan liiketoimintaa tai organisaation toimintaa. Haluttu vaikuttavuus määrittää ”liiketoiminnan kielellä”, miten käytettävyyden tulisi konkreettisesti tukea liiketoimintaa tai organisaation toimintaa.

Luonnehdinta

Tavoitteen määrittämiseksi tarvitaan tietoa sovelluksen liiketoimintakontekstista. Näitä ovat esimerkiksi:

* mikä tuote ja sen päätoiminnallisuus (mitkä ovat sen tarjoamat palvelut asiakkaalle)
* mille markkinoille
* ketkä ovat asiakkaat
* miten sen halutaan erottuvan markkinoilla
* mitkä ovat kilpailutekijät
* mitkä ovat liiketoiminnalliset tavoitteet

”Liiketoiminnan” tilalla voi olla – kontekstista riippuen – organisaation, esimerkiksi sairaalaympäristön toimivuus.

Tavoitteita määrittäessä tulee ymmärtää, että käytettävyys ei välttämättä ole kaikki kaikessa vaan sen merkitys ja vaadittu taso riippuu liiketoimintakontekstista. Käytettävyyden suunnitteluun voidaan helposti laittaa paljonkin resursseja, enemmän kuin on järkevää. Haluttu käytettävyysvaikuttavuus on organisaation strateginen valinta, joiden tulisi toisaalta tuottaa järkeviä liiketoiminnallisia etuja, ja toisaalta olla kehitysresursseihin nähden järkevästi saavutettavissa.

Strategisena tavoitteena ei siis välttämättä tulisi olla, että saavutetaan ”paras mahdollinen käytettävyys”. Tavoitetason asettaminen riippuu esimerkiksi siitä, haluaako yritys haluaa olla ”johtotähti” käytettävyydessä vai pyrkiikö olemaan kilpailijoiden tasolla. Tuote voi olla liiketoimintamenestys huolimatta käytettävyysongelmista. Esimerkiksi Nokian 90-luvun peruspuhelinmallin (kuva 6, kuva 9) kaupallinen menestyminen lienee ollut erinomainen, selkeistä käytettävyysongelmista huolimatta.

Aktiviteetti on liiketoimintajohdon, yrityksen ja kehitysprojektin eri osapuolten sekä käytettävyysammattilaisten vuoropuhelua. Tavoitteiden määrittämistä varten tulee valita attribuutit, jotka sopivat sovelluksen liiketoimintakontekstiin. Käytettävyysvaikuttavuuden tyypilliset attribuutit perustuvat ns. käytettävyyden liiketoimintaetuihin, esimerkiksi:

* järjestelmän hyväksyttävyys
* koulutuksen helppous
* käyttäjät eivät tee virheitä
* käyttäjätuen tarpeen minimointi
* käytön nopeus, vaivattomuus
* käyttäjien työn tehostuminen
* käyttäjä- ja työtyytyväisyys

Haluttu käytettävyysvaikuttavuus on aina väistämättä sovelluskohtaista. Vaikuttavuus asettamisessa voidaan esimerkiksi ottaa kantaa käyttöohjeeseen tai käyttökoulutukseen: onko tavoitteena, että tuote tulisi olla opittavissa ilman käyttöohjetta tai käyttökoulutusta? Esimerkki toisen tyyppisestä tavoitteesta on asiakkaiden viranomaisille tekemien ”turhien” puhelujen vähentäminen.

Tuotokset

Aktiviteetin tuotoksena kuvataan haluttu käytettävyysvaikuttavuus niin laadullisesti (mitä attribuutteja) kuin tavoitetasona. Attribuuttien tulisi kuvata yrityksen tai organisaation todellisia liiketoimintahyötyjä. Tavoitteiden määrityksessä tulisi pyrkiä mitattavuuteen.

Syytä olisi välttää sellaisia kriteereitä, jotka eivät riipu yksikäsitteisesti käytettävyydestä. Tällainen on esimerkiksi ”lisääntynyt myynti”: myyntiin vaikuttavat niin monet muutkin seikat, että käytettävyyden vaikuttavuutta on vaikea erottaa.

Käytettävyysvaikuttavuuden määrittäminen voidaan nähdä myös riskinhallintana. Tunnistetaan riskit, jotka seuraavat potentiaalisista käytettävyysongelmista. Käytettävyyssuunnittelu nähdään sitten riskin pienentämismenetelmänä.

Menetelmät

Aktiviteetti on liiketoimintajohdon, projektijohdon ja käytettävyysasiantuntijan välistä vuoropuhelua. Taustatiedoiksi voidaan tarvita ymmärrystä niin käyttäjäryhmistä (aktiviteetti 1) ja käyttökontekstista (aktiviteetti 2).

Viitteet

Jokela, T (2010). Navigoi oikein käytettävyyden vesillä. www.kaytettavyyskirja.net

Nokian käyttöliittymäkohtalon taustat 90-luvulla?

2011-06-06T08:03:00.001+03:00

Nyt siis Nokia kurssi huitelee alamaissa. Käyttäjäkokemuksen suunnittelussa jälkeen jäämistä pidetään yhtenä keskeisistä syistä Nokian alamäkeen.

On kaikkiaan hämmentävää Nokian epäonnistuminen hyvän käyttäjäkokemuksen tuottamisessa. Nokialla on sankoin joukoin käytettävyys- ja käyttäjäkokemusammattilaisia - moni alalta väitellyt ja kansainvälisesti tunnustettu. Ei ole uskottavaa, etteikö Nokialla olisi ollut alan osaamista. Syyt ovat muualla. Nokia teknologiavetoisesta kulttuurista on puhuttu yhtenä syynä.

Mutta pidän yhtenä mahdollisena syynä myös erikoista käyttöliittymäparadigmaa, joka sai vallan Nokialla 1990-luvulla. Mielestäni on mahdollista, että tämän paradigman vaikutukset näkyivät vielä viime vuosiin asti ja ovat osaltaan taustalla Nokian puhelinten käyttäjäkokemusongelmiin.

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

Monet ehkä muistavat Nokian puhelinten erilaiset käyttöliittymät 90-luvun lopulla. Oli punainen ja vihreä luurinäppäin -käyttöliitymä, oli "navi"-näppäinkäyttöliittymä, oli rullakäyttöliittymä...

Nokialla sai silloin valtaa erikoinen "tyyliohjautunut" käytettävyysparadigma: strategiana oli erilaisia käyttöliittymätyylejä. Käytännössä silloin paradigma tarkoitti erilaisilla näppäimistöillä varustettuja puhelimia. Erilaisista käyttöliittymätyyleistä tehtiin itseisarvoja; niitä käytettiin mm. markkinasegmentoinnin keinona. Välitön seuraus ja ongelma oli tietenkin se, että eri puhelimet olivat keskenään erilaisia käyttää. Tyylien rajoitteissa pyrittiin kuitenkin tekemään puhelinten sovelluksista niin helppokäyttöisiä kuin pystyttiin. Ja kohtuudella onnistuttiinkin.

Toinen seuraus oli kuitenkin se, että yksinkertaistetuilla käyttöliittymätyyleillä oli vaikea suunnitella joitakin puhelinten sovelluksia millään tavalla elegantisti. Seurauksena saatettiin jättää operaattoreille tärkeitä sovelluksia pois. Jopa sanottiin, että "asiakkaat ovat väärässä", kun operaattorit halusivat tiettyä sovellusta.

Ydinasia tässä kuitenkin on se, että tyylikeskeisyys on tietenkin vastoin sitä, mitä käytettävyys aidosti on. Se on itse asiassa täysin vastakkaista käytettävyyden periaatteille, vaikka käytettävyyden nimellä sitä Nokialla sisäisesti markkinoitiinkin. Käyttöliittymänhän ei tulisi ole itseisarvo, vaan apuväline, vuorovaikutuskeino sovelluksiin. Kriteeri hyvälle käyttöliittymä on se, että sovellusten käyttö sujuu. Ei sen enempää. Käyttöliittymät tulisi suunnitella sovellusten ehdoilla eikä toisin päin.

Ja nyt pidän mahdollisena, että tämä erikoinen 1990-luvun oppi jäi elämään joidenkin Nokian päättävien henkilöiden keskuuteen myös pitkälle 2000-luvulle. Tällaista olen tulkinnut joidenkin Nokian johtajien julkisuudessa olleista lausunnoista vuosien aikana (tosin niin tarkkaan en seurannut asioita, että olisin kirjannut näitä muistiin). Joka tapauksessa vähän sen tyylistä viestiä, että ratkaisu ongelmaan olisivat olleet jotkut "käyttöliittymäjippo"-tason asiat.

-----------

Eli pidän siis mahdollisena, että tämä erikoinen oppi olisi vaikuttanut vielä viime vuosina Nokian käyttöliittymäpäätöksiin, jotka sitten viime kädessä realisoituivat tämän päivän jälkeenjääneisyyteen.

Tämä on kuitenkin minun pohdintaani, enkä tiedä, että menivätkö asiat todella näin 2000-luvulla (noita 1990-luvun tapahtumia kyllä seurasin omin silmin). Mutta ainakin tämä mielestäni olisi yksi looginen selitys sille, miksi Nokialla kävi kuin kävi; miksi Nokian merkittävä käyttäjäkokemusosaaminen ja -resurssit eivät realisoituneet tuotteisiin. Jos joku nokialainen eksyy tälle blogille, niin ehkä voi kommentoida asiaa.

Jos tämä tulkintani on osittainkin totta, niin siinä on tietenkin on mielenkiintoista pohdittavaa käytettävyys- ja käyttöliittymäalalle yleensä. Mutta ei mennä tässä asioiden edelle.

Käyttäjälähtöinen tietorakenne - käytettävyysasiantuntijan keskeisin tehtävä?

2011-05-26T12:14:00.003+03:00

Käytettävyysalalla yritetään monesti korostaa, käytettävyys on enemmän kuin käyttöliittymä. Eli käytettävyyteen ei vaikuta pelkästään käyttöliittymäratkaisut vaan myös syvemmällä olevat järjestelmän suunnitteluratkaisut.

Mitä nämä käyttöliittymää syvemmällä olevat ratkaisut sitten ovat? Itse näen erityisen keskeisenä, että järjestelmällä on käyttäjälähtöisesti määritetty tietorakenne. Tietorakenteita kyllä määritetään, mutta kokemukseni mukaan ei erityisen käyttäjälähtöisesti. Ja kuitenkin, jos tietorakenne on ongelmallinen, niin käyttöliittymällä sitä on hyvin hankala korjata.

Kokemukseni mukaan käyttäjätarpeiden jäsentäminen tuottaa vahvan tietorakenteen. Ei itsestään, koska tietorakenne voi olla haastavaa jäsentää loogiseksi. Mutta tällainen jäsentäminen onkin mielestäni sopivaa haasteellista käytettävyysasiantuntijan työtä. Erityisesti järjestelmän eri entiteettien liittyvien tilojen tunnistaminen voi vaatia tosi aivotyötä - ainakin itse olen joskus joutunut todella pinnistelemään.

Ja vielä sellainen näkökulma, että tietorakennetta määritettäessä pääsee todella syvälle sovellusalueen ja käyttäjän maailmaan. Kohta jäsennät sitä paremmin kuin käyttäjät itse. On ihan mukava tunne, kun voi tuottaa käyttäjille "ahaa"-elämyksiä.

Käyttäjälähtöisen tietorakenteen määrittäminen on perustavaa laatua oleva työvaihe. Toisaalta olen myös huomannut, että sitä ei välttämättä kukaan muu projekteissa tee. Siinä on mielestäni oiva ja keskeinen rooli käytettävyysasiantuntijalle.

Pitkät nimikkeet on ok!

2011-05-18T08:25:00.003+03:00

Olen talven aikana ollut ainakin kolmessa eri tilanteessa, jossa välilehtien tai painikkeiden nimikkeiksi on haluttu lyhyitä ilmaisuja; mielellään yksi lyhyt termi. Kukaan noista henkilöistä ei ollut taustaltaan käyttöliittymäalan ihminen: pari projektipäällikköä ja yksi tuotepäällikkö. Kuitenkin siis aika päättävässä asemassa, kun tehdään käyttöliittymäratkaisuja.

"Lyhyet nimikkeet" näyttää siis olevan intuitiivinen ajattelutapa. Kuitenkaan tälle ei liene muuta perustelua, paitsi että jos on tilaongelma kuten usein pienissä näytöissä.

Kuitenkin pitemmän nimikkeet ovat suotavia, jos niillä tehdään asiat selvemmiksi eikä ole tilaongelmaa. Esimerkkinä selkeästä, pitkästä nimikkeestä alla oleva SurveyMonkeyn dialogissa oleva "Päivitä kyselytutkimuksen otsikko" - painike.

Vai näkeekö joku pitkässä nimikkeessä olevan jokin ongelma?

Mikä mahtaa olla käytettävyystestien laatu Suomessa?

2011-04-28T09:24:00.001+03:00

Jatkona edelliseen: Ralf Molich kirjoitti sähköpostissaan seuraavan kokemuksensa (lupasi, että saan julkaista sen blogissani):

"During the past 1-2 years I have been asked to carry out QA checks on 7 usability test providers. QA checks were ordered by clients who wanted uniform and state-of-the art usability tests across countries, including countries whose language they did not understand. They also wanted to be sure that they got what they paid for so they could safely make important decisions based on the usability test results. Needless to say, almost all the people involved in these tests had impressive portfolios and exams from renowned universities.  

The findings were, eh, interesting. Only one utest provider passed without serious notes. Six of seven got one or more serious or critical notes on their adherence to standard procedures for usability testing."

Eli Molichin havainto on, että käytettävyystestien tekemisen laatu on kyseenalaista. Vaikka niiden tekijöillä on meriittejä.

Minulla on tullut se käsitys, että tilanne Suomessa ei ehkä ole sen kummempi. Sen perusteella, mitä olen kuullut kentältä ja mitä käytettävyysraportteja olen itse joskus nähnyt.

Vai mitä kokemuksia on itse kullakin?

Käytettävyystyö ei ole rutiinia

2011-04-17T19:47:00.002+03:00

Käytettävyystyö ei ole rutiinia. Käytettävyyttä ei varmisteta käyttäjäkeskeisillä prosesseilla tai menetelmillä: ei käytettävyystestauksella, käyttäjätutkimuksilla, käyttötapausmäärittelyillä, käytettävyysohjeistoilla.

Asiaa on tutkittu tieteellisesti Rolf Molichin vetämissä CUE -tutkimukset: http://www.dialogdesign.dk/CUE.html. Yksi tulos vaikkapa se, että kun yhdeksän (9) käytettävyystestiryhmää testasi samaa kohdetta, niin 75% raportoiduista ongelmista löysi vain yksi ryhmä.

Voidaan ajatella ja usein sanotaankin, että käytettävyys on nuorehko ja ei vielä kyspä tieteen ala. Ja sitä kautta nähdään selitys tällaisille tutkimustuloksille.

Itse kuitenkin olen taipuvainen ajattelemaan, että pointti on se, että käytettävyys on olennaisesti "älytyötä". Käytettävyystyöhön liittyy vain vähän rutiiniasioita. Näitä ovat ehkä sellaiset kuin käyttäjien rekrytointi, käytettävyystestien logistiset järjestelyt ja perusrutiinit.

Mutta käytettävyyden varsinaisen substanssin laatua eivät mitkään menetelmät takaa. Molichin tutkimuksessa todettiin, että käytettävyystestien tulokset olivat ihan erilaiset riippuen siitä kuka testejä sattui tekemään. Väitän, että vielä suurempi hajonta on tilanteessa, jossa pitäisi valita sopivia käytettävyystoimenpiteitä tiettyyn projektikontekstiin. Ja erityisesti väitän, että aivan liian yleisesti valitaan "oikeaksi" toimenpiteeksi käytettävyystestaus.

ISO 9241-210

2010-04-27T08:40:00.003+03:00

kirjoittelen blogia ISO 9241-210:stä; pidän tässä blogissa taukoa sen aikaa

http://iso9241-210.blogspot.com/

Apple ei kysele käyttäjiltä

2010-04-12T20:58:00.001+03:00

Uusimassa Time -lehdessä (April 12, 2010) on juttu Applesta. Siinä sanotaan: "Apple never holds focus groups. It doesn't ask people what they want; it tells them what they're going to want next".

Yess! Juuri näin!

"Kysytään käyttäjiltä" on helposti ensimmäinen mieleen tuleva keino, kun halutaan kehittää tuotteista käyttäjäystävällisempiä.

Käyttäjälähtöisyys on a ja o. Ja käyttäjät toki tulee ottaa mukaan suunnitteluun. Mutta ei niin, että kysytään käyttäjiltä, "mitä he haluavat?" tai "haluavatko tätä ja tätä?". Tällainen lähestymistapa on ongelmallinen kahdestakin syystä. (1) Tulokset perustuvat käyttäjien jäsentelykykyyn. Se voi osua kohdalleen, mutta aika suuri todennäköisyys, että ei. (2) Käyttäjät laitetaan asemaan, joka ei ole heille luontainen. Itse käytän sähköpostia päivittäin, mutta minua ei tippaakaan kiinnosta pohtia, millaisen paremman sähköpostiohjelman haluasin. Minulla on paljon muutakin tekemistä.

Käyttäjien tulisi olla tiedon lähteitä, heille ominaisilla tavoillaan. Käytettävyysasiantuntijoiden ja suunnittelijoiden tulee tulkita ja muuntaa tämä tieto tuotteeksi, jota "käyttäjät haluavat seuraavaksi".