Käyttöliittymän tekeminen tietojärjestelmään tai muuhun tietotuotteeseen on vaativa työ, joka vieläkin liian usein tehdään kuvainnollisesti vasemmalla kädellä.
Miksi nähdä vaivaa yhden käyttöliittymän takia? Kannattaa miettiä, miksi tuote ylipäätään tehdään. Mikä sen tarkoitus on? Jos se on Web-sivu, käytettävyys on sen elinehto. Vaikeakäyttöistä sivustoa ei kukaan käytä, ja siihen käytetyt rahat on heitetty hukkaan.
Esimerkki elävästä elämästä takavuosilta: Eräs yhdistys oli menettämässä paljon jäseniä. Keinoksi pitää heidät yhdistyksessä keksittiin teettää yhdistykselle uudet, informatiiviset Web-sivut, joihin vain jäsenet pääsevät. Sivusto tehtiin ja teettäjäpuolen ostaja-suunnittelijan mielestä niitä oli hyvin hankala käyttää. Resurssit eli raha ja aika oli tässä vaiheessa käytetty loppuun. Ostaja-suunnittelija kääntyi tässä vaiheessa esimiehensä puoleen pyytäen rahaa käytettävyysarviointiin ja tuotteen korjaamiseen. Esimies oli sitä mieltä, että rahaa on jo nyt käytetty niin paljon, ettei lisää tuhlata, ja sivusto on myöhässä jo muutenkin. Ostajapuolen suunnittelija oli valistunutta ja sinnikästä tyyppiä, ja organisaatiossa ymmärrettiin, että on hyödytöntä julkaista sivustoa, joka ”karkottaa loputkin jäsenet”. Sivustolle tehtiin ensin asiantuntija-arvio ja siitä korjattiin arvioiden perusteella asiat, joiden korjaaminen oli helppoa. Lopuksi sivusto vielä testattiin potentiaalisten käyttäjien avulla. Arvioinnissa ja testeissä löydettiin paljon käytettävyysongelmia, joista osa oli vakavia. Jotkin ongelmista olisivat yksinäänkin todennäköisesti karkottaneet suuren osan käyttäjistä pois sivustolta, olihan sen käyttö täysin vapaaehtoista. Sivustolta korjattiin pahimmat ongelmat. Sivusto oli onneksi rakenteeltaan terve eli kunnolla suunniteltu, ja siitä saatiin kohtuullisella työllä hyvä.
Tyypillinen aiemmin evaluoimaton ja ilman osaavaa käytettävyysasiantuntijaa tehty valmis Web-sivusto pitää sisällään 50–200 tuhoisaa, vakavaa, merkittävää, vähäistä tai kosmeettista käytettävyysongelmaa, jotka kaikki häiritsevät tämän sivun käyttöä.
Operatiivisien järjestelmien tapauksessa käyttäjiltä ei juuri kysytä, haluavatko he käyttää järjestelmiä vai eivät. Niitä on pakko käyttää riippumatta siitä, kuinka huonosti ne soveltuvat tarkoitettuihin tehtäviin. Sekä vanhoissa merkkipohjaisissa että graafisissa järjestelmissä ja intraneteissä koko työnteon teho riippuu tietojärjestelmän tehokkuudesta, ja tehoton työ on sitä kalliimpaa, mitä enemmän näitä käyttäjiä on tekemässä tehottomasti työtä. Huonot järjestelmät myös stressaavat käyttäjiä ja pahimmillaan jopa sairastuttavat käyttäjänsä. Omissa tutkimuksissamme on nähty, että huonoista intraneteistä johtuen tehdään myös riskipäätöksiä. Saattaa esimerkiksi viedä liian kauan aikaa tarkistaa asioita intranetistä asiakkaan ollessa paikalla. Riskipäätös on paitsi taloudellinen riski myös stressitekijä.
Kaikista tuotteista kaikkein huonoimmin suunniteltuja näyttävät olevan räätälöidyt operatiiviset järjestelmät — juuri ne, jotka olisi teoriassa mahdollista tehdä kaikkein parhaiten. En pysty arvioimaan, paljonko tyypillisessä graafisessa järjestelmässä on ongelmia, koska yhdessä testissä voidaan käydä läpi vain osa operatiivista järjestelmää. Oma näppituntumani on, että ongelmia on moninkertaisesti Web-sivustoihin verrattuna.
Melkein kaikki käytettävyysongelmat ovat korjattavissa, kunhan ne löydetään ja tiedetään, miksi ne ovat ongelmia. Hyvä ammattimainen ja kokenut käytettävyysyritys antaa myös huolella mietityt korjausehdotukset virheisiin. Aina kaikkiin virheisiin ei ikävä kyllä voi antaa parempaa korjausehdotusta kuin että nyt vain pitäisi määritellä ja suunnitella tuote uudestaan alusta. Tämä ohje on turhauttava antaa ja turhauttava saada. Tuotteen prototyyppejä pitäisi evaluoida alusta lähtien ja niin, että ne kaikkein vaikeimmin korjattavat virheet löytyvät niin ajoissa kuin mahdollista. Tyypillisin syy, miksi jokin virhe jää korjaamatta, on tekniikan rajoituksissa. Tällöin joudutaan tekemään kompromisseja, mutta se täytyy vain hyväksyä. Työssäni on kyllä nähty sekin ihme, että piirre, joka on ollut likimain mahdotonta saada tuotteeseen, on saatu siihen kolmessa viikossa sen jälkeen, kun koodista vastaava henkilö oli ollut seuraamassa käytettävyystestejä.
Mutta ensin hieman teoriaa: Käytettävyys
Käytettävyys on tuotteen laatuominaisuus, jolla kuvataan, kuinka helppoa ja tehokasta tuotetta on käyttää. Koska käytettävyys on melko abstrakti ominaisuus, sitä on purettu konkreettisemmiksi osakokonaisuuksiksi, jotka voivat kaikki tai osittain toteutua tuotteessa.
- ISO 9241-11 -standardin mukaan käytettävyys on mittari, jolla mitataan tuotteen käytön tuottavuutta, tehokkuutta ja miellyttävyyttä. Nämä arvioidaan aina suhteessa käyttäjiin sekä työhön ja käyttöympäristöön, joille ja joihin tuote on tarkoitettu.
- Tuottavuus tarkoittaa sitä, että tehtävät tulevat tehdyksi täydellisesti ja virheettömästi.
- Tehokkuus mittaa sitä, paljonko resursseja tuotteen käytössä tarvitaan henkilöinä, rahana ja aikana.
- Miellyttävyys kertoo, kuinka miellyttävä tuotetta on käyttäjien mielestä käyttää.
- Jakob Nielsen antaa käytettävyydelle seuraavat viisi laatukomponenttia: opittavuus, tehokkuus, muistettavuus, virheettömyys ja miellyttävyys. Käytettävyyden lisäksi Nielsen puhuu tuotteen hyödyllisyydestä.
- Opittavuus:Kuinka helppoa käyttäjien on tehdä tuotteen avulla perusasiat ensimmäisellä käyttökerralla?
- Tehokkuus: Kun asia on opittu, kuinka nopeasti käyttäjät pystyvät tekemään tehtävät?
- Muistettavuus: Kun käyttäjät palaavat tuotteen ääreen oltuaan käyttämättä sitä jonkin aikaa, kuinka kauan heiltä menee saman tuottavuuden saavuttamiseen uudelleen?
- Virheettömyys:Kuinka paljon käyttäjät tekevät virheitä, kuinka vakavia ne ovat ja kuinka helppoa niistä on toipua?
- Miellyttävyys: Kuinka miellyttävä tuote on käyttää?
- Hyödyllisyys: Kuinka hyvin tuote sopii työhön, johon se on tarkoitettu? (Nielsenin käsite ”hyödyllisyys” vastaa suunnilleen ISO-standardin ”käytettävyyttä”. Tässä tekstissä käytetään vakiintuneempaa ISO-standardin nimeämistapaa jo ihan siitä syystä, että on turha mitata sellaisen tuotteen ”käytettävyyttä”, joka ei ole hyödyllinen ja sopiva tarkoitukseensa.)
Muita käytettävyyteen liitettyjä ominaisuuksia ovat muun muassa johdonmukaisuus, hallittavuus, tehtäviin sopiva esitystapa, pieni muistettavien asioiden määrä ja joustavuus. Nämä ominaisuudet ovat kaikki johdettavissa kuitenkin tehokkuudesta, tuottavuudesta ja miellyttävyydestä niin kuin Nielseninkin määrittelemät käytettävyysominaisuudet.
Käytännössä kaikkein tärkeimmät ja käytetyimmät käytettävyysmuuttujat ovat tuotteen intuitiivisuus (eli Nielsenin ”opittavuus”), käytön tehokkuus (ei vain tehokäyttäjien tehokkuus, vaan myös aloittelijoiden) ja virheettömyys. Tehokkuus itse asiassa kattaa intuitiivisuuden.
Käytettävyys-käsitteellä on joukko rinnakkaiskäsitteitä, joissa niissäkin on kyse tuotteen ominaisuuksista:
- Palvelevuus (availability): Aiemmin käytettävyys, esimerkiksi onko verkko toiminnassa 24 tuntia vuorokaudessa
- Houkuttelevuus (attractiveness): Tuote houkuttelee ostamaan, käyttämään. Esimerkiksi Webissä tämä tarkoittaa sitä, että käyttäjä selaa etusivua syvemmälle.
- Helppokäyttöisyys (ease-of-use): Suunnitteluperiaate, jonka mukaan käyttäjä saavuttaa tavoitteensa tehokkaasti on hän millä osaamistasolla tahansa.
- Esteettömyys (accessibility): Kaikki pystyvät käyttämään tuotetta mukaan lukien vammaiset ja ikääntyvät käyttäjät.
- Käyttäjäkokemus (user experience): Kokonaiskuva, jonka yrityksen palvelusta, mukaan lukien esimerkiksi Web-sivut, saa.
- Käyttökokemus (use experience): Käyttöön liittyvät tunneaspektit.
Käytettävyysohjeet ovat nyrkkisääntöjä, joita tuotteen suunnittelussa tulisi noudattaa. Ohjeisiin on upotettu erilaista tietoa niille suunnittelijoille noudatettavaksi, joilla ei ole mahdollisuutta perehtyä ihmisen ominaisuuksiin tuotteen käyttäjänä. Tällaiset ohjeet voivat olla tuoteriippumattomia, tuotekulttuuriin sidottuja, yrityskohtaisia tai tuote- ja tuoteperhekohtaisia. Yleinen ohje voi esimerkiksi sanoa: ”Anna käyttäjälle aina hyvä palaute.” Web-kulttuurin ohje saattaa sanoa: ”Sivun otsikon ja siihen viittaavan linkin tulee vastata toisiaan niin, että käyttäjä ymmärtää tulleensa oikealle sivulle.” Talon ohje voi sanoa: ”Saman avainsanan täytyy olla sekä otsikossa että linkissä.” Jokaisella ammattikäytettävyysarvioijalla on tällainen ohjekokoelma takaraivossaan, tosin harvoin eksplisiittisessä muodossa. Se on yleensä sitä hiljaista tietoa, jota käytetään, kun lähdetään tekemään asiantuntija-arviota tuotteesta.
Käyttäen tuotekehitysprosessissa käytettävyysmenetelmiä tehdään järjestelmästä niin käytettävä kuin mahdollista. Tuotekehitysprosessia voidaan kutsua käyttäjälähtöiseksi. Tämä tarkoittaa, että käyttäjä on tarpeineen otettu huomioon, kun järjestelmää kehitetään. Tarkemmin on määritelty käyttäjäkeskeinen suunnitteluprosessi, joka kuvataan seuraavassa kohdassa.
Miten käytettävyys rakennetaan tuotteeseen
Tuotteen helppokäyttöisyyttä ei rakenneta pelkällä hyvällä tahdolla, joskin jo oikea asenne on paljon parempi kuin ei mitään. Käyttöliittymän suunnittelu on vaikeaa, ja siksi sitä varten tarvitaan kunnolliset menetelmät ja ammattitaitoa menetelmien soveltamiseen. Lisäksi tarvitaan niin paljon kuin mahdollista tietoa siitä, miten ihminen ylipäätään toimii. Ideana on, että lisäämällä tuotekehitysprosessiin tietyt asiat ja panostamalla tuotekehitysprosessin alkuvaiheeseen varmistutaan, että tuote on käytettävä eli tuottava, tehokas ja miellyttävä käyttäjälleen. Lisäksi se on pitkäikäisempi.
Käytettävyysongelmissa pätee sama laki kuin missä tahansa muissa tuotteen virheissä: mitä myöhemmin ne havaitaan, sitä kalliimmaksi ne tulevat korjata. Sama pätee myös toisessa muodossa: mitä varhaisemmassa vaiheessa tuotekehitystä virheet ovat syntyneet, sitä kalliimpia ne ovat korjata tuotekehityksen lopussa. Nykytilanteessa käyttöliittymäongelmat tulevat tyypillisesti esille vasta ohjelmiston valmistumisen jälkeen.
Käytettävyyden rakentaminen ei edellytä mitään rajua kokonaisuudistusta tuotekehitysprosessiin. Asiat täytyy edelleenkin ensin määritellä, sitten suunnitella ja sitten toteuttaa. Monesti ongelmat ovat seurausta siitä, että käyttöliittymää ei missään vaiheessa suunnitella eikä sen soveltumista käyttötarkoitukseensa testata ennen kuin vasta sitten, kun järjestelmä otetaan käyttöön. Ennen kuin lähdetään toteuttamaan järjestelmää, täytyy käyttöliittymä tehdä kuntoon, niin että työn teettävä osapuoli tietää sen toimivan. Sitä, että käyttöliittymä on kunnossa, ei voi ratkaista missään johtoryhmässä demon ääressä eikä katselmoinnein, vaan se on testattava.
Standardi (ISO DIS 13401) jakaa tuotekehitysprosessin seuraaviin vaiheisiin 1–4 (kommentit ovat omia täsmennyksiäni):
1. Tuotteen käyttökontekstin määrittely: käyttäjät, heidän tehtävänsä ja käyttöympäristö
Nämä on tutkittava oikeasti. Yleensä nämä oletetaan tunnettavan, mikä käsitys pitää paikkansa hyvin harvoin. Syntyneiden kuvausten täytyy olla rikkaita ja konkreettisia kuvauksia käyttäjistä ja heidän työstään ja työolosuhteistaan. Käyttäjän arjesta nykyhetkellä tehdään toimintatarinoita (scenarios), jotka muuntuvat suunnittelutyössä tuotteen käyttötarinoiksi (use scenarios), jotka molemmat ovat käyttötapauksia (use cases) rikkaampia kuvauksia ja sisältävät tarpeelliset tiedot erityyppisten käyttäjien ominaisuuksista (persoonat), tehtävistä ja tavoitteista sekä eri toimintaolosuhteista. Tieto kerätään havainnoinneilla, haastatteluilla ja vanhan tuotteen läpikäynneillä. Myös toimintatarinat voi kerätä suoraan käyttäjiltä.
2. Käyttäjävaatimusten määrittely: käyttäjän ja organisaation järjestelmälle asettamat vaatimukset
Tässä täytyy huomata eri näkökulmat ja yksilölliset tarpeet sekä olosuhteet, joissa toimitaan. Tavoitteet koskevat yleensä opittavuutta — esimerkiksi tietyt toiminnot pitää osata tehdä heti ja ilman käsikirjaa, jotkin muut käsikirjaa käyttäen, tai järjestelmäkoulutus saa viedä vain tietyn ajan — tehokkuutta tai virheettömyyttä. Täsmällisten käyttäjävaatimusten asettaminen saattaa olla hieman hankalaa, eikä sitä Suomessa juuri harrasteta. Kohtuullinen vaatimus voisi olla esimerkiksi se, että järjestelmä ei saa heti alkukäytössä olla hitaampi kuin vanha, ja kun käyttäjät tottuvat tuotteeseen, sen pitää olla 30 prosenttia nopeampi. Selaintuotteissa asetetaan usein sellaisia rajoituksia, että kaikkien toimintojen tulee olla korkeintaan kolmen napsautuksen päässä. Tosiasiassa napsautusten määrä ei ole ratkaiseva tuotteen tehokkuudelle; tärkeämpää on se, kuinka osuvasti linkit on nimetty.
3. Suunnitteluratkaisujen tuottaminen
Suosittelen, että järjestelmästä tai sen osasta tehdään ensin kokonaissuunnittelu: jaetaan tieto sivuihin tai ikkunoihin, suunnitellaan valikoiden sisällöt, annetaan sivuille tai ikkunoille otsikot sekä suunnitellaan sisältö karkeasti. Kun tähän asti tehty työ on evaluoitu, aletaan suunnitella ikkunoiden tai sivujen sisältöjä tarkemmin, minkä jälkeen ne evaluoidaan.
4. Suunnitteluratkaisujen evaluointi
Tämä pitää tehdä joko käyttäen oikeita asiantuntijoita arvioijina ja/tai tehdä hyvin suunnitellut käytettävyystestit. Ostajille näytetty demo ei ole käytettävyystesti. Arvioinneista saadut palautteet pitää ottaa mukaan tuotteen jatkosuunnitteluun, pelkkä testaaminen ei paranna tuotetta. Suunnittelu-arviointi-analysointi-suunnittelu-vaiheita tulee toistaa, kunnes tavoitellut taso on saavutettu. Vasta kun käyttöliittymä on kunnossa, jäädytetään määrittely-suunnitteluprosessi ja aletaan tehdä koodia käyttöliittymän taakse.
Hyvän käyttöliittymän suunnittelu tehdään siis pitkin tuotekehitysprosessia eikä se ole erillinen toiminto, jossa liimataan käytettävyys tuotteeseen. Kysymys on ennemminkin siitä, että tuotesuunnittelun alkupään vaiheet tehdään huolellisemmin, eli juuri se vaihe projektissa pitäisi tehdä tarkasti ja huolella, jossa tällä hetkellä kaikkein eniten loikitaan ja fuskataan: määrittely ja suunnittelu. Käyttöliittymäsuunnittelu sijoitetaan projektin alkuun, ennen toteutuksen tai esimerkiksi tietokantaratkaisujen suunnittelua, jotta käyttöliittymäratkaisuja ja järjestelmän soveltuvuutta käyttötarkoituksiinsa voitaisiin testata niin varhaisessa vaiheessa, että testitulosten vaatimat suuretkin muutokset olisivat vielä helposti toteutettavissa. Tarvittavien muutosten tekeminen prototyyppeihin on huomattavasti vaivattomampaa ja edullisempaa kuin toimivan ohjelmakoodin käyttäminen asiakasvaatimusten tai käyttöliittymäkehityksen iterointivälineenä.
Tuotekehitysprojekti muuttuu siis selvästi alkupainotteisemmaksi, mikä on hyvä aikataulujen ennakoitavuuden takia. Huonoa on tietysti se, että kun esimiehet ja asiakkaat ovat tottuneet koodaamisen aloittamiseen tietyssä vaiheessa, voi joutua selittelemään monta kertaa, että aikataulussa ollaan.
Tässä on muutama erittäin tärkeä asia:
- Aikatauluja ei saa tehdä liian kireiksi. Tulee yleensä halvemmaksi tehdä asiat asia kunnolla kuin paikkailla sitä myöhemmin.
- Teettäjäpuolen pitää olla työssä aktiivisesti mukana. Miten muuten saadaan varmistettua, että työn tulos on sellainen kuin pitää?
- Tekijä- ja teettäjäpuolen työnjaon pitää olla selkeä ja myös selvä kummallekin osapuolelle: teettäjäpuolen pitää huolehtia siitä, että omat käyttäjät saavat kunnon järjestelmät, tekijäpuolen siitä, että sekä systeeminsuunnittelu että tekninen suunnittelu pelaa. teettäjäosapuoli on siis käyttäjän työn asiantuntija, tekijäpuoli tekniikan, tietokantasuunnittelun ja vastaavien osa-alueiden. Teettäjäosapuolella saatetaan tarvita kuitenkin myös tekniikan asiantuntemusta, jos tekijäosapuolella on tapana vedättää teettäjäosapuolta.
· Järjestelmästä tulee syntyä prototyyppi, jota sekä käytetään kommunikointivälineenä teettäjän suuntaan että arvioinnin pohjana iteraatioissa.
- Sen joka vastaa käyttöliittymän määrittelystä ja suunnittelusta, pitää saada olla kontaktissa käyttäjien kanssa.
- Käyttäjien hyödyntämisen projektissa pitää olla suunniteltua. Ei ole hyödyllistä kysellä käyttäjiltä, mitä he haluaisivat, vaan käyttäjiltä selvitetään heidän nykyinen toimintatapansa, ongelmansa sekä tarpeensa ja heitä käytetään käytettävyystesteissä testikäyttäjinä.
- Käyttöliittymän käytettävyys testataan tai ainakin se arvioitetaan asiantuntijalla. Testattu prototyyppi toimii syötteenä jatkotoimenpiteille kuten käsiteanalyysille ja ohjelmistoarkkitehtuurin suunnittelulle.
Menetelmät
Käytettävyyssuunnittelun tärkeimmät menetelmät ovat
- käytettävyystutkimus
- iteroiva suunnittelu eritasoisia prototyyppejä käyttäen
- käytettävyyden arviointi
- käytettävyystestaus.
Käytettävyyden arviointimenetelmät ovat
- heuristiset arviot (heuristic evaluation)
- ohjeistojen ja standardien käytön tarkistus (standard reviews)
- tarkistuslistat (check-lists)
- yhtenäisyystarkistukset (consistency review)
- kognitiivinen läpikäynti (cognitive walktrough).
Kolmessa ensimmäisessä arviointimenetelmässä evaluoija tai evaluoijat (heuristisessa arviossa tyypillisesti kolme) käyvät käyttöliittymän läpi muutamaan kertaan ja tarkastavat, täyttääkö se tietyt vaatimukset. Kohdat, joissa nämä säännöt eivät täyty, raportoidaan. Heuristiikoista tunnetuimmat ovat Nielsenin 10 heuristista sääntöä. Yhtenäisyystarkistukset on helpointa ja järkevintä tehdä käyttöliittymästandarditarkistuksena, ts. yhtenäinen käytäntö määritellään talon (tai tuoteperheen tai projektin) sisäisessä käyttöliittymästandardissa ja jokainen käyttöliittymä tarkastetaan, että se noudattaa tätä standardia.
Kognitiivinen läpikäynti puree tuotteen intuitiivisuuteen. Se on menetelmä, jossa simuloidaan käyttäjän toimintaa ja kun törmätään kohtaan, josta aloitteleva käyttäjä ei selviäisi, se raportoidaan. Tuotteen asiantuntija-arvio on käytännössä useimmiten heuristisen arvion ja kevennetyn kognitiivisen läpikäynnin yhdistelmä. Näillä käytettävyyden asiantuntija-arvioinneilla pyritään pureutumaan kuvan 1 kolmion viivan alapuolella olevien ominaisuuksien huomioon ottamatta jättämiseen.
Kuva 1: Ihmisen ominaisuuksia: viivan yläpuolella olevat ominaisuudet ovat sellaisia, jotka täytyy selvittää käyttäjätutkimuksin, ja selvitetään käytettävyystestein. Viivan alapuolella on asioita ja vaatimuksia, joiden rikkomukset löytyvät yleensä parhaiten asiantuntija-arvioin.
Käytettävyystestillä selvitetään, miten tuotteen todelliset käyttäjät sen kanssa toimivat. Testin tavallisimmat tyypit ovat ääneenajattelutesti, ryhmäläpikäynti ja avoin läpikäynti. Ääneenajattelutestissä käyttäjä suorittaa joukon ennalta laadittuja testitehtäviä ajatellen samalla ääneen. Ryhmäläpikäynnissä on mukana useita käyttäjiä, joista kukin suorittaa ennalta laaditut tehtävät erikseen paperiprototyypeille (tai näyttömalleille) ja kertoo vuorollaan, miten tehtävän suorittaisi. Avoimessa läpikäynnissä ei valmiita tehtäviä ole, vaan käyttäjä suorittaa järjestelmällä omia tavanomaisia tehtäviään tai tehtäviä, joita hän luulee tuotteella voitavan tehdä. Kaikki nämä testit tallennetaan ja tallenteet analysoidaan ja löytyneet ongelmat raportoidaan.
Koska käytettävyystestinä markkinoidaan palveluita, jotka eivät ole käytettävyystestejä lainkaan, tai testejä, joita ei tehdä oikein ammattitaitoisesti, olen kerännyt tähän joukon asioita, joista hyvän käytettävyystestin tunnistaa:
- Käyttäjiä on korkeintaan 20 (ellei kyseessä ole laaja testi, jonka tarkoituksena on kerätä määrällistä aineistoa), yleensä 3-9.
- Testi taltioidaan videolle tai digitaalimuotoon ja asiakas saa tallenteen halutessaan itselleen.
- Testin suorittavat koulutetut, kokeneet käytettävyystutkijat.
- Testitulokset käydään yhdessä lävitse niin, että testin ostajaosapuoli ymmärtää varmasti, mistä on kysymys ja miksi.
- Ostajaosapuoli pääsee seuraamaan testejä, jos ne tehdään laboratorio-olosuhteissa.
- Raportissa annetaan korjausehdotuksia ja kerrotaan syyt ongelmiin.
- Testissä löytyy paljon virheitä, jos tuotetta ei ole testattu aiemmin tai sen teossa ei ole käytetty (testattua) käyttöliittymästandardia.