Käytettävyysohjattu vuorovaikutussuunnittelu: JFunnel malli ( käytettävyyssuppilo )

1 (13) Käytettävyysohjattu vuorovaikutussuunnittelu: JFunnel malli ( käytettävyyssuppilo ) Timo Jokela, FT timo.jokela@joticon.fi Tiivistelmä Tämän dokumentissa kuvataan käyttäjäkeskeisen suunnittelun tarkemmin sanottuna käytettävyysohjatun vuorovaikutussuunnittelun elinkaarimalli, ns. JFunnel -malli ( käytettävyyssuppilo ). Dokumentissa annetaan lyhyet kuvaukset suunnittelun prosesseista, sekä käydään läpi käytännön seikkoja, jotka tulisi ottaa huomioon suunnittelun käytännön toteutuksessa. hite paper v. 210109

2 (13) Sisältö Tiivistelmä... 1 Johdanto... 3 Mitä on käytettävyys... 3 Käytettävyysohjattu vuorovaikutussuunnittelu... 4 JFunnel: käytettävyyssuppilo... 4 0. Strategiset käytettävyystavoitteiden määritys... 6 1. Käyttäjäryhmien tunnistus... 7 2. Käyttökontekstin määritys... 7 3. Operatiivisten käytettävyystavoitteiden määritys... 7 4. Käyttäjätehtävien suunnittelu... 8 5. Vuorovaikutusratkaisujen tuottaminen... 9 6. Käytettävyyspalaute... 9 7. Käytettävyyden varmistus... 10 Käytännössä huomioitavaa... 10 Tee riittävän ajoissa... 10 Käyttäjien mukanaolo... 10 Suunnittelija on avainasemassa... 11 Suunnitteluratkaisujen iterointi... 11 Käytettävyysprosessien tulokset riippuvat niiden tekijöistä... 12 Käytätettävyysmenetelmien projektikohtainen soveltaminen... 12 Kompleksisuuden hallinta... 12 Infrastruktuuri... 12 Viitteet... 12 hite paper v. 210109

3 (13) Johdanto Liittyykö yrityksesi tai organisaatiosi kehittämiin (hankkimiin) sovelluksiin 1 yksi tai useampi seuraavista ongelmista: o sovellus jää käyttämättä o jos ei koko sovellus niin sen yksittäiset toiminnot jäävät käyttämättä o menee paljon aikaa ja resursseja käyttäjäkoulutuksen antamiseen o menee paljon aikaa ja resursseja jälleenmyyjien tukemiseen o sovelluksen käyttöönotto on hidasta o käyttäjät tekevät virheitä järjestelmään tulee virheellisiä tietoja o käyttäjät luulevat suorittaneensa tehtävän, mutta itse asiassa tehtävä on jäänyt kesken o järjestelmän tukipalvelut kuormittuvat käyttäjien soitoista, sekä asiakkaalla että toimittajalla o käyttäjät valittavat työprosessiensa sujuvuutta o työtyytyväisyys laskee, kun rutiininomaisestikin tehtävä työ vaatii useita ja turhalta tuntuvia vaiheita o käyttäjät eivät löydä haluamaansa tietoa (verkkosivut)? Tämän tyyppiset ongelmat ovat tyypillisiä seurauksia sovelluksen ongelmallisesta käytettävyydestä. Hyviä käyttöliittymiä on kuitenkin mahdollista suunnitella: tarvitaan käytettävyysohjattua vuorovaikutussuunnittelua. Tässä dokumentissa kuvataan käytettävyysohjatun vuorovaikutussuunnittelun prosessi. Dokumentin tarkoitus on olla yleissivistävä. Se on tarkoitettu antamaan kuva prosessista niin asiasta kiinnostuneelle johdolle kuin suunnittelijoille. Dokumentti ei ole tarkkuudeltaan tarkoitettu käytännön käsikirjaksi. Mitä on käytettävyys Käytettävyyden määritelmä annetaan standardissa ISO 9241-11 (ISO/IEC 1998): 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. Määritelmä ehkä kuulostaa monimutkaiselta mutta on konkreettisesti käyttäjälähtöinen. Määritelmässä tarkastellaan käytettävyyttä kolmesta lähtökohdasta: o ketkä ovat käyttäjiä? o mitkä ovat käyttäjien tavoitteet? o mikä on sovelluksen käyttöympäristö? Kriteerit, joilla käytettävyyttä tarkastellaan ja mitataan ovat: o Tuloksellisuus. Missä määrin käyttäjä pääsee tavoitteisiinsa, niin että lopputulos on oikea? Tuloksellisuutta voidaan pitää käytettävyyden tärkeimpänä peruskriteerinä: saako käyttäjä aikaiseksi sen, minkä vuoksi yleensä hän sovelllusta käyttää. 1 Tässä dokumentissa käytetään termiä sovellus kattamaan tuotteet, ohjelmistot, järjestelmät, verkkosivustot jne. hite paper v. 210109

4 (13) o Tehokkuus. Kuinka paljon resursseja tarvitaan siihen, että käyttäjä pääsee tavoitteeseensa? Tyypillinen tehokkuusmittari on aika: mitä nopeammin käyttäjä pääsee tavoitteisiinsa, sitä parempi tehokkuus. o Käyttäjätyytyväisyys. Kuinka miellyttävänä käyttäjä kokee sovelluksen käyttämisen. Jos käytettävyyden määritelmän tiivistää, niin se voisi kuulua: Käytettävyys on käyttäjän työn tukemista. Käyttäjäkokemus vs. käytettävyys Termi käyttäjäkokemus ( user experience ) on tullut käytettävyyden rinnalle viime vuosina. Käyttäjäkokemuksen määritelmä on: a person's perceptions and responses that result from the use or anticipated use of a product, system or service (tämän hetkinen määritelmä valmisteilla olevassa standardissa ISO 9241-210). Vaikka olen itse ollut mukana ym. määritelmän muotoilussa, näen asian vielä osittain keskeneräisenä. Käyttäjäkokemusta markkinoidaan laajempana asiana kuin käytettävyys, mutta usein puuttuu selkeä kuvaus, millä tavalla se on laajempi. Ym. määritelmä tuo yhden laajennuksen käytettävyyteen: käyttäjäkokemus sisältää myös tuotteen ulkonäön siinä mielessä, että näyttääkö tuote helppokäyttöiseltä (kohta anticipated use ym. määritelmässä). Tästä näkökulmasta tässä dokumentissa kuvattu JFunnel-prosessi pitäisi olla sovellettavissa myös käyttäjäkokemuksen suunnitteluun, ehkä lukuun ottamatta tuota ulkonäkö-näkökulmaa. Käytettävyysohjattu vuorovaikutussuunnittelu Käyttöliittymän pystyy suunnittelemaan periaatteessa kuka tahansa. Maailma on täynnä esimerkkejä sovelluksista, joiden käyttöliittymä ilmeisimmin on suunniteltu ottamatta huomioon käytettävyyttä. Hyvän käyttöliittymän - hyvän käytettävyyden - suunnittelu vaatii systemaattisen lähestymistavan. Käytettävyyteen tähtäävästä suunnittelusta käytetään kirjallisuudessa eri termejä. ISO 13047 (ISO/IEC 1999) käyttää termiä ihmiskeskeinen suunnittelu. Muita paljon käytettyjä termejä ovat Nielsenin (Nielsen 1993) käyttämä käytettävyyssuunnittelu, Mayhewin käyttämä käyttäjäkeskeinen suunnittelu (Mayhew 1999) ja Constantinen (Constantine and Lockwood 1999) käyttökeskeinen suunnittelu. Tässä dokumentissa käytetään termiä käytettävyysohjattu vuorovaikutussuunnittelu. Termillä halutaan korostaa sitä, että hyvän käytettävyyden aikaansaaminen ei synny käytettävyysaktiviteettien suorittamisella tai sillä, että käyttäjät ovat mukana prosessissa. Sovelluksen käytettävyyden ratkaisee aina viime kädessä suunnittelijat: missä määrin käytettävyysnäkökohdat huomioidaan suunnitteluratkaisussa. Käytettävyysaktiviteetit ja ohjeistot antavat ohjaustietoa, jotka (toivon mukaan) huomioidaan suunnittelussa. JFunnel: käytettävyyssuppilo Joticonin käyttämä JFunnel käytettävyysohjatun vuorovaikutussuunnittelun elinkaarimalli on esitetty kuvassa 1. Kuvan soikiot kuvaavat prosesseja, ja nuolet ja numerot kuvaavat loogista etenemisjärjestystä. hite paper v. 210109

5 (13) Kuva 1. Käytettävyysohjattu vuorovaikutussuunnittelu: JFunnel -malli arvoa kuluttajille, arvoa liiketoiminnalle Keskeinen prosessi on luonnollisesti käyttöliittymäratkaisujen tuottaminen (5): siinä tuotetaan konkreettiset käyttöliittymän suunnitteluratkaisut. Toinen keskeinen prosessi on operatiiviset käytettävyysvaatimukset (3), joka on mallin, tai käytettävyyssuppilon, keskimmäisessä, puristetussa kohdassa. Suppilomuodolla ja käytettävyystavoitteiden sijainnilla puristuskohdassa korostetaan sitä, että operatiiviset käytettävyystavoitteet tiivistävät käyttäjädatan joka voi olla hyvinkin runsasta ja monipuolista - suunnittelua ohjaaviksi tavoitteiksi. Toisaalta suppilo aukeaa kohti suunnittelua, kuvaten sitä, että toimivien suunnitteluratkaisujen avaruus on potentiaalisesti laaja. Käytettävyysohjaustietoa tuottavat prosessit 0 4, 6 ja 7. Hyvää käytettävyyttä ei voida suunnitella tuntematta käyttäjien työtä (prosessit 1 ja 2). Prosessi 3 tuottaa tavoitteet käyttöliittymän laadulle. Prosessit 6 ja 7 ovat tuotettujen suunnitteluratkaisujen testausta. Lisäksi suunnittelua tulisi ohjata standardit ja yleiset suunnitteluohjeet, joita löytyy kirjallisuudesta paljonkin. Esimerkiksi ISO 9241-sarja (ISO/IEC 1998) kattaa laajalti eri käyttöliittymän osa-alueet). JFunnel-mallin tarina Mallin tausta alkaa vuodesta 1997, jolloin Nokialla ja Teamarella tehtiin ensimmäiset käytettävyyssuunnittelun prosessiarvioinnit ( käytettävyyskypsyysarvioinnit ). Arviointimallina käytettiin eurooppalaisessa INUSE-projektissa kehitettyä prosessimallia. Kokeilujen perusteella malli todettiin hankalaksi käyttää, ja sen perusteella siihen tehtiin muutoksia; päivitetystä mallista tuli ISO:n teknisessä raportissa (ISO 18529) kuvattu prosessimalli. Väitöstutkimuksessaan Timo Jokela sovelsi käytettävyyskypsyysarvioinneissa tuota päivitettyä ISO 18529 (myös ISO 13407) prosessimallia, ja totesi mallin edelleen hite paper v. 210109

6 (13) ongelmalliseksi. Malli oli tulkinnanvarainen, eikä niiden perusteella voinut selkeästi raportoida kaikkia käytettävyyssuunnitteluun liittyviä oleellisia havaintoja. Tutkimuksessaan Timo Jokela kehitti sitten mallia edelleen, päätyen malliin, joka nimettiin tutkimusprojektin mukaan KESSU -malliksi. KESSU-mallia käytettiin 2000-luvulla eri tarkoituksissa, prosessiarviointien lisäksi käytännön projekteissa kuin opetuksessakin, ja se edelleen askeleittain kehittyi. Prosessit täsmenivät, ja niiden kuvaukset tarkentuivat. Viimeinen suurempi kehitys tapahtui alkuvuodesta 2008, jolloin mallin visuaalisen esityksen muoto muuttui kehästä (kehämuoto oli alkujaan peräisin ISO 13407:sta) suppiloksi. Tähän idea tuli TRATTI -myyntiprosessin mallista 2. Myyntiprosessin tapaan käytettävyyssuunnittelussa on selkeä puristusvaihe : käytettävyystavoitteiden määritys, jolloin suppilo kuvaa hyvin prosessia. Samalla mallille annettiin sen muotoa kuvaava nimi (JFunnel). Samoihin aikoihin syntyi termi käytettävyysohjattu vuorovaikutussuunnittelu. Paljon käytetty termi käyttäjäkeskeinen suunnittelu on semanttisesti vähän harhaanjohtava (onko käyttäjä suunnittelun keskellä?). Käytettävyyssuunnittelu - termissä on puolestaan se ongelma, että varsinainen vuorovaikutussuunnittelu ei ole käytettävyysaktiviteetti, jolloin tarve tuli termille, joka kattaa sekä käytettävyysaktiviteetit että vuorovaikutussuunnittelun. Malliin myös lisättiin uusi prosessi, strategisten käytettävyystavoitteiden määritys. Näin meillä on nykyinen JFunnel-malli. On kuitenkin huomioitava, että mikään tällainen malli ei ole totuus. Väitöskirjan aikoihin (2001) olin erittäin tyytyväinen silloiseen KESSU -malliin; tänä päivänä näen selkeästi sen puutteet. Kun edelleen tulee lisää kokemusta JFunnel-mallin käytöstä eri yhteyksissä, siihen on odotettavissa edelleen päivityksiä. KESSU/JFunnel-mallin käytön laajuutta ei ole tarkemmin tutkittu. Kuitenkin on viestejä kuulunut sen käytöstä eri yhteyksissä, myös käytännön projekteissa. Malli on toiminut yhtenä perustana käytettävyyssuunnittelun merkittävimmän kansainvälisen standardin ISO 13407 uudistamisessa (tuleva ISO 9241-210). Tieteellisiä julkaisuja mallista on tehty useita. 0. Strategiset käytettävyystavoitteiden määritys Strategisten käytettävyystavoitteiden tarkoituksena on määrittää, miten sovelluksen käytettävyyden tulisi tukea liiketoimintaa. Tavoitteena ei siis tarvitse olla, että saavutetaan paras mahdollinen käytettävyys. Strategiset käytettävyystavoitteet ovat organisaation strategisia valintoja, joiden tulisi toisaalta tuottaa järkeviä liiketoiminnallisia etuja, ja olla toisaalta kehitysresursseihin nähden järkevästi saavutettavissa. Aktiviteetin tuotokset ovat strategiset käytettävyystavoitteet, esitettynä mahdollisimman konkreettisesti, mielellään mitattavasti. Tyypilliset mittarit perustuvat ns. käytettävyyden liiketoimintaetuihin: o koulutukseen käytettävät resurssit o järjestelmän hyväksyttävyys o käyttäjätukeen kuluvat resurssit o tehostuneista käyttäjän työprosesseista saadut säästöt o käyttäjätyytyväisyys 2 JKC Oy Consulting hite paper v. 210109

7 (13) Esimerkkinä tavoitteissa voidaan ottaa kantaa käyttöohjeeseen tai koulutukseen: onko vaikkapa tavoitteena, että sovellus tulisi olla opittavissa ilman koulutusta. 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 vaikutusta on vaikea erottaa. 1. Käyttäjäryhmien tunnistus Tämän aktiviteetin tarkoituksena on tunnistaa ketä ovat kehitettävän sovelluksen käyttäjät. Käytettävyyden määritelmän mukaan tämä on perusasia: käytettävyyshän on ensisijaisesti suhteessa sovelluksen käyttäjiin. Jokainen sovelluksen käyttäjä on erilainen yksilö. Käytännössä ei ole kuitenkaan mahdollista, että sovelluksia suunnitellaan jokaiselle käyttäjälle erikseen. Sen vuoksi käyttäjäkunta tulisi kategorisoida ne sopiviin käyttäjäryhmiin, sekä tuottaa kuvaukset ko. käyttäjäryhmistä. Käyttäjäryhmien kategorisointi ei useinkaan ole yksinkertainen tehtävä. Kategorisointiperusteen tai perusteiden - valinta on ensimmäinen haaste. Kategorisointiperusteita ovat esimerkiksi: o demograafiset tekijät (ikä, sukupuoli, koulutus, jne.) o työroolit o käyttöympäristöt o sovelluksen käyttökokemus o elämäntyyli o persoonalliset ominaisuudet 2. Käyttökontekstin määritys Käyttökontekstin määritys tarkoittaa yleisesti ottaen käyttäjän työn 3 määritystä. Koska käyttökonteksti (tavoitteet, tehtävät, ympäristö) ovat tyypillisesti erilaisia eri käyttäjäryhmillä, niin käyttökontekstin analyysi tyypillisesti tehdään käyttäjäryhmäkohtaisesti. Käyttäjän käyttökontekstin analyysissa määritetään käyttäjän tavoitteet ja tehtävät sovelluksen suhteen sekä sovelluksen käyttöympäristö. Luonteeltaan käyttökontekstin ymmärtäminen on tiedon keräämistä ja jäsentämistä. Käyttökonteksteista on saatavissa paljon tietoa, ja haasteena on tämän tiedon hallinta. Kaikkea tietoa ei voi eikä ole järkevää kerätä eikä käsitellä. Sen vuoksi prosessiin kuuluu luonnostaan kompleksisuuden hallinta. Käyttäjäryhmien tunnistus ja käyttökontekstin määritys edellyttävät usein keskinäistä iterointia, ja sen vuoksi ne on järkevä tehdä yhdessä. 3. Operatiivisten käytettävyystavoitteiden määritys Operatiivisten käytettävyystavoitteiden määritys on keskeinen prosessi. Siinä asetetaan suunnittelutavoitteet kehitettävän sovelluksen käytettävyydelle: mitkä kriteerit kehitettävän sovelluksen tulisi täyttää, jotta se olisi käytettävyydeltään hyvä. Jotta vaatimukset tekisivät 3 Työ lainausmerkeissä sen vuoksi, että esimerkiksi kuluttajatuotteiden suhteen ei voi varsinaisesti puhua työstä. hite paper v. 210109

8 (13) käytettävyyden konkreettiseksi suunnittelun tavoitteeksi, ne tulisi määritellä mitattavassa muodossa. Operatiivisilla käytettävyystavoitteiden määrityksellä on kaksi päätarkoitusta: o toimivat vuorovaikutusmedioiden suunnittelua ohjaavina ajureina: kun suunnitteluratkaisujen tekijät tietävät tavoitteet, ne ohjaavat suunnitturatkaisuja oikeaan suuntaan o olla perusteena käytettävyyden varmistukselle (aktiviteetti 7): varmistuksessa saatuja tuloksia verrataan määriteltyihin käytettävyystavoitteisiin Näistä kahdesta tarkoituksesta voidaan ensimmäistä pitää tärkeämpänä, koska sitä kautta vaikutetaan suoraan suunnitteluratkaisuihin. Operatiiviset käytettävyystavoitteet ovat tarkemmalla tasolla kuin strategiset tavoitteet. Esimerkiksi jos strategiseksi käytettävyystavoitteeksi on asetettu opittavissa ilman koulutusta, niin operatiivisissa käytettävyystavoitteissa määritetään tarkemmin, mitä opittavissa olevat asiat ovat. Käytettävyysvaatimusten määritys koostuu periaatteessa kahdesta vaiheesta o käytettävyysmittareiden valinta o käytettävyystavoitteiden määrittäminen Operatiiviset käytettävyysvaatimukset määritetään tyypillisesti käyttäen ISO 9241-11 käytettävyyden määritelmää perusteena, käyttäen soveltuvin osin attribuutteja: o tuloksellisuus (effectiveness) o tehokkuus (efficiency) o käyttäjätyytyväisyys (satisfaction) Jos käytettävyyden määritelmää tulkitaan tarkasti, tavoitteet pitäisi määrittää suhteessa käyttäjäryhmään, tavoitteeseen ja käyttöympäristöön. Käytännössä kuitenkin tällainen lähestymistapa tuottaa yleensä hallitsemattoman suuren määrän mittareita. Sen vuoksi vaatimusten määrä pitäisi pystyä pitämän kohtuullisena esimerkiksi valitsemalla oleellisimmat käytettävyystavoitteet. 4. Käyttäjätehtävien suunnittelu Tässä prosessissa suunnitellaan, miten käyttäjät suorittavat tehtävänsä kehitettävän sovelluksen avulla. Suunnittelun kohde on siis käyttäjien tehtävät ei käyttöliittymä. Tehtäväkuvauksissa kuvataan, mitä vuorovaikutusta käyttäjä tekee sovelluksen kanssa, mutta ei itse vuorovaikutusmekanismien toteutusta. Käyttäjätehtävien suunnittelussa otetaan kantaa esimerkiksi käyttäjän ja tietokoneen väliseen työnjakoon: mitä toimintoja allokoidaan tietokoneelle ja mitä käyttäjille. On tilanteita, jossa voi olla perusteltua jättää käyttäjille toimintoja, jotka olisi helppokin toteuttaa teknologisesti. Yksinkertainen esimerkki työnjaon suunnitteluongelmasta on kännykän näppäinlukko. Pitäisikö näppäinlukko olla automaattinen (menee tietyn ajan kuluttua päälle itsestään) vai manuaalinen? Automatisoinnin tekninen toteutus on helppoa, mutta ei ole itsestään selvää, onko se käyttäjän kannalta järkevää. hite paper v. 210109

9 (13) 5. Vuorovaikutusratkaisujen tuottaminen Käyttöliittymän ja muiden vuorovaikutusmedioiden (esimerkiksi käyttöohjeet) suunnitteluratkaisujen tuottaminen on luonteeltaan innovatiivista, jossa ratkaisut suunnitellaan perustuen: o käytettävyyssuunnittelun aiempien prosessien (0-4) tuottamaan ohjaustietoon; nämä tuottavat ohjaustietoa erityisesti tehtävätason käyttöliittymäsuunnitteluun o erityisesti käytettävyystavoitteet (3) ohjaavat suunnittelua oleellisesti o evaluointiaktiviteettien (6-7) antamaan palautteeseen o yleisiin käytettävyysohjeistoihin ja standardeihin, jotka tuottavat ohjaustietoa erityisesti vuorovaikutuselementtitason suunnitteluun; näitä ovat o kansainväliset standardit o yksittäisten asiantuntijoiden tuottamat suunnitteluohjeet o yleiset ja yritys/sovellustason tyyliohjeet, jotka tuottavat ohjaustietoa erityisesti visuaaliseen suunnitteluun o toisaalta teknologisten mahdollisuuksien, toisaalta suunnittelurajoitusten huomioimiseen o suunnittelijan taustaan, näkemyksiin ja luovuuteen Luonteenomaista käyttöliittymäratkaisujen suunnittelulle on se, että ei ole olemassa yhtä ainoaa oikeaa ratkaisua tai oikeita ratkaisuja. Asetetut tavoitteet täyttäviä ratkaisuja voi olla useitakin; toisaalta voi olla vaikeaa löytää ollenkaan sellaista suunnitteluratkaisua, joka täyttäisi haastavia käytettävyysvaatimuksia. Tyypillistä suunnittelulle on iteratiivisuus. Riittävän hyvän suunnitteluratkaisun etsiminen voi tarkoittaa, että useiden erilaisten suunnitteluratkaisujen toimivuutta tulee kokeilla hakemalla käytettävyyspalautetta (prosessi 6). Toisaalta parasta suunnitteluratkaisua ei kannattaa etsiä: periaatteessa riittää, että ratkaisu täyttää asetetut tavoitteet (prosessi 3). On huomattava, että varsinaisen käyttöliittymän lisäksi prosessin tuotoksia ovat myös muut asiat, joiden kanssa käyttäjä on vuorovaikutuksessa: käyttöohjeet, myyntipaketit, koulutusmateriaalit jne. 6. Käytettävyyspalaute Käytettävyyspalaute on perinteisin ja yksittäin ehkä eniten suoritettu käytettävyysprosessi. Suunnitteluratkaisuille annetaan laadullista palautetta sen käytettävyydestä: mikä suunnitteluratkaisussa toimii ja mikä ei. Lähtökohtana on kehitettävän sovelluksen prototyyppi, jota arvioidaan käytettävyyden näkökulmasta. Prototyyppejä voi olla eriasteisia: paperiprototyypeistä tietokonesimulaatioihin. Prosessin tuotokset ovat sekä käyttöliittymäratkaisun ongelmakohtien ja toimivien kohtien tunnistukset. Tuloksiin usein liitetään ehdotukset paremmista suunnitteluratkaisuista. Tämän prosessin suorittamiseen on olemassa lukuisia menetelmiä. Usein menetelmät jaetaan kahteen pääryhmään (muitakin ryhmittelyjä on): o ns. asiantuntijamenetelmiin, joissa ei ole loppukäyttäjä mukana o käytettävyystestaukseen, jossa loppukäyttäjä on mukana Käytettävyyspalautetta - esimerkiksi asiantuntija-arviointia - tarjotaan usein yksittäisenä palveluna. On kuitenkin otettava huomioon, että käytännössä elinkaaren alun vaiheita tulee suorittaa ainakin jossain määrin palautteen antamisen perustaksi. Muuten käytettävyyspalaute jää väistämättä kovin ohueksi. hite paper v. 210109

10 (13) Usein käytettävyysanalyysin kohteena on valmis, olemassa oleva sovellus. Siinä tapauksessa analyysin tulokset ovat hyödynnettävissä sovelluksen seuraavan version suunnittelussa. 7. Käytettävyyden varmistus Käytettävyyden varmistamisessa testataan, päästäänkö operatiivisten käytettävyysvaatimusten määrityksessä (prosessi 3) asetettuihin tavoitteisiin. Prosessia luonnehtii mittaaminen: sovelluksen käytettävyyden tasoa mitataan soveltuvilla mittareilla. Mittaustavan määrittäminen onkin yksi prosessin haasteista. Käytännössä mittaaminen on usein käyttäjäpohjaista, esimerkiksi käytettävyystestaus. On kuitenkin myös laskennallisia tapoja mitata käytettävyyttä. Käytännössä huomioitavaa Edellisessä kappaleessa kuvattiin käytettävyysohjatun vuorovaikutussuunnittelun prosessit, joista prosessit 0 3 liittyvät erityisesti käytettävyystavoitteiden määrittämiseen. Mallin vaiheet toteutuvat kuitenkin harvoin kirjanmukaisesti. Tapauskohtaista soveltamista tapahtuu monestakin näkökulmasta: o kuinka laajalti prosesseja suoritetaan o millä menetelmillä prosesseja suoritetaan o missä määrin tehdään iterointia (ts. vaikka prosessit etenevät loogisesti järjestyksessä, käytännössä usein palataan prosesseissa taaksepäin) o miten tekijöiden (asiakas, käytettävyysasiantuntija) roolit menevät Kaikkiaan, käytettävyystavoitteiden määritys eikä käytettävyyden suunnittelu yleensäkään - ole mekaanista työtä, vaan käytäntöjä tulee soveltaa tilanteen mukaan. Tee riittävän ajoissa Aina uudestaan tehty virhe on se, että käytettävyyttä ajatellaan aivan liian myöhäisessä vaiheessa suunnitteluprosessia. Käytettävyyden ongelmat voivat menevät järjestelmän rakenteisiin saakka, ja tarvittavalle suuremmalle remontille ei usein ole enää mahdollisuuksia projektin loppuvaiheessa. Käytettävyysaktiviteetit tulisi aloittaa kehitysprojektin varhaisissa vaiheissa, siinä vaiheessa, kun määritellään kehitettävän sovelluksen ensimmäisiä vaatimuksia. Prosessien 1-3 merkitystä ei voi vähätellä, varsinkin kun niiden suorittaminen on mahdollista heti sovelluksen määrittelyvaiheessa. Ajoissa aloitettu käytettävyyssuunnittelu tuo ryhtiä kehityshankkeeseen: o saadaan selkeät vaatimukset ja kriteerit käyttöliittymän laadulle o päästään juupas/eipäs keskusteluista systemaattiseen suunnitteluun o vältetään turhilta muutoksilta sovelluskehityksen loppuvaiheessa Käyttäjien mukanaolo Hyvän käytettävyyden saavuttaminen tarkoittaa käytännössä sitä, että sovelluksen oikeat loppukäyttäjät ovat mukana suunnitteluprosessissa - kuitenkaan ei millä tavalla tahansa. Käyttäjien mukanaololla saadaan tietoa käyttökontekstista, käyttäjien tavoitteista ja tehtävistä ja palautetta suunnitteluratkaisuista. Käyttäjien mukanaolo on yleensä tehokkaampaa, mikäli suunnittelijat ovat suoraan mukana käyttäjien kanssa tehtävissä vaiheissa. hite paper v. 210109

11 (13) Mutta käyttäjien mukaan ottamisella on sudenkuoppansa: se ei suinkaan tarkoita käyttäjien mielipiteiden mukaan suunnittelua. Helposti käy, että jos suunnittelee sovelluksen käyttäjän vaatimusten mukaan, tuloksena on sovellus, johon käyttäjä ei ole tyytyväinen. On myös tuloksellisia käytettävyysmenetelmiä, jotka eivät sisällä suoraan käyttäjän mukanaoloa. Ne vievät tyypillisesti vähemmän resursseja kuin käyttäjien mukanaoloon perustuvat menetelmät. Suunnittelija on avainasemassa Käytettävyydeltään hyvien suunnitteluratkaisujen tuottaminen ei ole mekaaninen asia. Yleiset suunnitteluohjeet ja käytettävyyssuunnittelun prosessit (1-4, 6-7) tukevat suunnitteluvaihetta (5) mutta eivät automaattisesti takaa hyvää käytettävyyttä. Käytettävyyssuunnittelu tuottaa monien suunnittelijoiden kaipaamia konkreettisia neuvoja vain rajoitetusti. Hyvän käyttöliittymän aikaansaaminen riippuu siis siitä, missä määrin suunnittelija 4 ottaa huomioon käytettävyysprosessien tulokset ja käyttöliittymäsuunnittelun yleiset periaatteet suunnittelutyössään ja osaa muuntaa ne toimiviksi suunnitteluratkaisuiksi (kuva 2). Kuva 2. Suunnittelija tuottaa käyttöliittymäratkaisut perustuen käytettävyysprosessien tuotoksiin, suunnitteluohjeisiin, rajoituksiin sekä omaan taustaansa, näkemyksiinsä ja luovuuteensa Suunnitteluratkaisujen iterointi Käytännön kokemus käyttöliittymistä on, että ensimmäinen suunnittelu ei koskaan ole hyvä, ei edes kokeneen suunnittelijan tuottamat ratkaisut. Tarvitaan käytettävyyden arviointia ja uudelleen suunnittelua. Iterointi yhdessä käyttäjän mukanaolon kanssa on tehokas väline varmistamaan sovelluksen käytettävyys. 4 Suunnittelijoita ovat kaikki, jotka vaikuttavat suunnittelupäätöksiin. Usein siis esimerkiksi projektin johto. hite paper v. 210109

12 (13) Iterointia tapahtuu myös laajemmin. Esimerkiksi käytettävyysvaatimukset voivat jäsentyä suunnittelun ja saadun käytettävyyspalautteen perusteella. Käytettävyysprosessien tulokset riippuvat niiden tekijöistä Käytettävyyssuunnittelu ja käytettävyysmenetelmien käyttö ei ole mekaanista työtä. Tutkimukset osoittavat, että esimerkiksi käytettävyystestien tulokset vaihtelevat voimakkaasti riippuen testien tekijöistä (Molich, Ede et al. 2006). Kaikkiaan on haasteellista määrittää, onko käytettävyysaktiviteetin esimerkiksi käytettävyystestauksen tulokset laadullisesti hyviä. Hyvä käytäntö voi olla käyttää useampia testien tekijöitä, ja sitä kautta saada laajempaa näkemystä ja oppia. Käytätettävyysmenetelmien projektikohtainen soveltaminen Käytännön suunnitteluprojekteilla on tiukat aikatauluvaatimukset ja rajoitetut resurssimahdollisuudet. Useinkaan ei ole mahdollista toteuttaa käytettävyysmenetelmiä siinä laajuudessa ja tarkkuudessa, miten ne esitetään kirjallisuudessa. Käytännössä käytettävyysmenetelmiä joudutaan soveltamaan projektin kontekstiin; joskus jopa etsimään innovatiivisia ratkaisuja. Tämäkin tilanne korostaa sitä, että käytettävyystyö riippuu paljon käytettävyystyön tekijästä. Käytettävyys ei ole mekaanista tekemistä vaan tuloksiin vaikuttaa tekijöiden henkilökohtaiset ominaisuudet: koulutus, kokemus, henkilökohtaiset näkemykset jne. Kompleksisuuden hallinta Käytettävyyden suunnittelua ei ole mahdollista tehdä täydellisesti käytännön resurssit tulevat vastaan. Käytännössä vaiheita joutuu tekemään yksinkertaisemmin kuin periaatteessa olisi tarpeellista. Esimerkiksi kaikkien käyttäjäryhmien käyttökontekstin analyysi tai yksittäisen käyttäjäryhmän tehtävien kattava analyysi ei useinkaan ole reaalisista. Ei myöskään kattava käytettävyyden testaus. Käytännössä kompleksisuuden hallinta on oleellinen osa käytettävyyssuunnittelua: joudutaan priorisoimaan, mihin asioihin keskittyä ja mitkä jättää vähemmälle. Infrastruktuuri Käytettävyyssuunnittelun infrastruktuuritarpeet ovat suhteellisen pieniä. Useiden käytettävyysmenetelmien suorittamiseen riittää henkilökohtaisessa käytössä olevia tai organisaatiosta muuten löytyviä välineitä: tietokoneita, digitaali- ja videokameroita, ja äänitallennusvälineitä. Työtiloiksi useassa tapauksessa riittää kokoushuoneet tosin jotkut menetelmät edellyttävät pitempiaikaisia tilojen varauksia. Käytettävyystestaukseen on perinteisesti käytetty kahta huonetta, joiden välissä on puoliläpäisevä lasiseinä. Nykyään tällaisetkin järjestelyt ovat tarpeettomia, koska testihuoneen tapahtumat voidaan heijastaa videotykillä tarkkailuhuoneeseen. Usein käyttäjätestit voidaan tehdä tavallisessa kokoustilassa. Viitteet Constantine, L. L. and L. A. D. Lockwood (1999). Software for Use. New York, Addison- esley. ISO/IEC (1998). 9241-10 Ergonomic requirements for office work with visual display terminals (VDT)s - Part 10 Dialogue principles. ISO/IEC 9241-10: 1998 (E). hite paper v. 210109

13 (13) ISO/IEC (1998). 9241-11 Ergonomic requirements for office work with visual display terminals (VDT)s - Part 11 Guidance on usability. ISO/IEC 9241-11: 1998 (E). ISO/IEC (1999). 13407 Human-Centred Design Processes for Interactive Systems. ISO/IEC 13407: 1999 (E). Mayhew, D. J. (1999). The Usability Engineering Lifecycle. San Fancisco, Morgan Kaufman. Molich, R., M. R. Ede, et al. (2006). "Comparative Usability Evaluation." Behaviour & Information Technology 23(1): 65-74. Nielsen, J. (1993). Usability Engineering. San Diego, Academic Press, Inc. hite paper v. 210109