Utformingsveileder

Kognitiv tilgjengelighet av nettsider og nettsteder

Januar 2010

Aspekter omkring planlegging, systemutvikling og testing

De følgende avsnittene dreier seg om forhold i planleggingsfasen og under utviklingen av selve løsningen. Vi presenterer metoder og teknikker som kan gjøre det lettere å forstå og ta hensyn til brukere med kognitive utfordringer.

Brukermedvirkning og brukersentrert systemutvikling

Brukere i alle aldre skal kunne bruke tekniske løsninger. © Clipart.com

Med brukermedvirkning menes at de som berøres av en beslutning, eller er brukere av tjenester, herunder IKT-baserte systemer og tjenester, får innflytelse på beslutninger og utforming som gjelder systemer eller tjenestetilbudet. Hensikten med brukermedvirkning er at utviklerne skal lære av brukerne. Brukermedvirkning handler om å utnytte kunnskap om brukere til å gjøre hensiktsmessige valg når det gjelder teknologi i bred forstand. Slik bidrar man til utvikling av inkluderende IKT. Grunntanken er at brukermedvirkning og brukersentrert systemutvikling gir brukervennlige systemer og tjenester. Brukerne får også eierskap til systemet gjennom medvirkning. Den brukersentrerte tilnærmingen forsøker å sikre at brukerne er med i systemutviklingsløpet for å bli informert, involvert og hørt, og at de kan bidrar til at systemet blir bra.

Brukersentrert systemutvikling innebærer å involvere brukere i alle faser av systemutviklingen fra kravspesifikasjon til testing og evaluering. Prosessen begynner med en systematisk analyse av brukernes ønsker, krav og behov før utviklingen starter. Brukere er meget sentrale når man skal lage kravspesifikasjoner som forteller blant annet hvilken informasjon som skal gis til systemet, hvilken rekkefølge oppgavene skal gjennomføres og hvilken informasjon brukeren skal motta. Man kan samle inn tilbakemeldinger fra brukerne for eksempel gjennom fokusgrupper, gjennomganger av eksisterende tjenester eller (papir)prototyper. Det er sentralt at man starter med brukernes behov, muligheter og begrensninger i stedet for de teknologiske mulighetene. Spesielt viktig er dette når det er snakk om brukere med spesielle behov, for eksempel personer med kognitive utfordringer.

Ungdom flest er flittige teknologibrukere. © Clipart.com

Grundig brukbarhetstesting er viktig når produktet eller tjenesten begynner å ta form. Brukeropplevelsen av en tjeneste eller et system skapes gjennom brukergrensesnittet og dets interaktivitet. Man kan hevde at jo mindre brukeren legger merke til brukergrensesnittet og dialogen med systemet eller tjenesten, jo mer vellykket er utformingen. Brukere må derfor kunne gi innspill til hvordan informasjonen skal se ut og presenteres (brukergrensesnitt), og hvordan brukeren samhandler med datasystemet (interaktivitet).

Brukersentrert systemutvikling bidrar til høy brukskvalitet. Dette betyr at:

• systemet eler tjenesten er lett å lære, bruke og huske (det vil si lett å bruke selv om man har vært borte fra det en stund), og at
• systemet løser oppgavene på en rask og effektiv måte, at brukeren ikke havner i unødvendige feilsituasjoner under bruk, og at eventuelle feil lar seg rette på en enkel måte.

Brukermedvirkning gir også andre effekter, herunder følgende:

• Når brukere bidrar til utformingen av systemet, skjer læring. Dette gir besparelser når det gjelder opplæringskostnader etterpå (kurs og lignende).
• Læring bidrar til at det blir mindre behov for brukerstøtte etterpå.
• Systemets brukbarhet øker. Brukerproblemer kan identifiseres tidlig, og dette bidrar til færre brukerfeil når systemet eller tjeneste tas i bruk.
• Når brukere selv er med på å utforme kravene til systemet, blir resultatet et system eller en tjeneste som fungerer etter brukernes ønsker. Dette gjør at det kan bli mindre behov for endringer og korrigerende vedlikehold.
• Brukerne opplever at systemet er hensiktsmessig og effektivt.

Når brukere med nedsatt funksjonsnivå ― for eksempel brukere med kognitive utfordringer ― er med i systemutviklingen, bidrar man til inkluderende utforming av systemer eller tjenester. Brukere med spesielle behov er derfor særdeles viktige medspillere i en systemutviklingsprosess. Økt tilgjengelighet gjennom inkluderende utforming har flere effekter:

• Brukermassen øker (borgere, kunder, ansatte).
• Brukeren finner fram og løser oppgaven selv.
• Kundeservice og brukerstøtte belastes mindre.
• Utvikling og vedlikehold kan bli billigere: bruk av tilgjengelighetsstandarder forenkler utviklingsløpet, og dette kan føre til noe mindre behov for grunnleggende testing.
• Å begynne med tilgjengelighet tidlig sparer ressurser sammenlignet med å måtte tilrettelegge etterpå.

Brukermedvirkning øker med andre ord tilgjengeligheten, og tilgjengelighet er lønnsomt.

Persona-metode

Utvikling og bruk av personas er en velkjent metode for å gjøre seg kjent med en brukergruppe. Innen IKT-området benyttes personas ofte for å representere målgruppen brukere. Personas kan benyttes i forbindelse med kravspesifikasjon, utvikling, testing eller markedsmessige avgjørelser for IKT-baserte produkter eller tjenester. Persona-metoden kan dog aldri erstatte arbeid med ekte brukere. Metoden er et tillegg til andre brukersentrerte metoder.

Bli kjent med Helle (28 år)! © Clipart.com

Personas er altså ikke ekte brukere, men oppdiktede portretter av brukere. Det man faktisk vet om ekte brukerne dokumenteres i form av personas. Malen for personas varierer en del. Her er ett mulig oppsett som kan anvendes når man modellerer personas som skal representere brukere av IKT-baserte produkter eller tjenester:

• Navn
• Foto
• Jobb
• Utdanning
• Sosial status
• Personlighet
• Interesser
• Personlig historie
• Arbeidsbeskrivelse (mål, oppgaver, situasjoner)
• Behov, frustrasjoner, holdninger, verdier (knyttet til det aktuelle området der personas anvendes)
• Sitater (knyttet til det aktuelle området der personas anvendes)

I det følgende kan du laste ned beskrivelser på persona-eksempler.

• Helle [PDF-format, 150 KB]
• Johan [PDF-format, 90 KB]
• Linn [PDF-format, 110 KB]
• Thomas [PDF-format, 100 KB]

Kartlegging av behov er avgjørende når man utformer personas for å gjøre brukergrensesnittet best mulig for brukere med kognitive utfordringer. Det er mulig å utvikle en persona med diagnosen dysleksi, men det er mer formålstjenlig å si at en persona har lese- eller skrivevansker. På tilsvarende måte trenger man kanskje ikke bruke begrepet begynnende demens eller MCI når det er nok å si at en persona sliter litt med å huske ting. Mange kan identifisere seg med en rotekopp, selv om det i virkeligheten kan dreie seg om konsentrasjonsvansker på grunn av ADHD. Utviklingshemming kan være grunnen til at abstrakt tenking eller problemløsing er krevende, men kanskje en hvilken som helst nybegynner har tilsvarende utfordringer som bruker?

Hils på Johan (42 år)! © Clipart.com

Aller viktigst er å lære brukere å kjenne gjennom treffende personas. Personas blir på mange måter arketyper, og de beskriver ofte særegenheter innen den aktuelle målgruppen. Dette kan være spesielt interessant i forhold til kravspesifikasjon for og testing av IKT-baserte produkter og tjenester, fordi ekstrembrukere vil avdekke behov som kommer alle brukere til gode.

Ved hjelp av intervjuer, fokusgrupper, observasjoner, workshops, statistikk og så videre henter man inn informasjon om representanter av målgruppen. Deretter lager man fiktive brukere ― personas ― som uttrykker forskjellige krav, ferdigheter, ønsker og behov. Observasjon av brukere som hører til ekte målgrupper er en metode som kan være til stor hjelp når man skal lage troverdige personas. Ved å observere de relevante brukerne over kortere eller lengre tid vil man få et realistisk bilde av deres situasjon, og man kan lettere se mulige løsninger som man ikke ville oppdaget kun på bakgrunn av intervjuer aller andre analyser.

Minst like viktig som å bli kjent med brukeren, er det å bli kjent med brukssituasjonen der man kan sette produktet eller tjenesten i en realistisk sammenheng. Organisasjoner som har brukerstøttefunksjon vil kunne gi verdifull materiale om brukernes problemer hvorav mange kan bero på kognitive utfordringer.

En mulighet for å angripe brukernes kognitive utfordringer gjennom persona-metoden er å benytte et rammeverk som vi har valgt å kalle RANDI. Hver bokstav representerer en brukerprofil, altså slik:

R

Rotekopp ― dekker konsentrasjonsvansker.

A

Alt mulig ― uspesifisert, men mange små grunner til kognitive utfordringer.

N

Nybegynner ― kanskje en utviklingshemmet person med god funksjonsevne.

D

Dyslektiker ― lese- og skrivevansker, lærevansker.

I

Intet spesielt ― mange med mindre kognitive utfordringer kan ofte fungere svært bra.

Dette er Linn (18 år)! © Clipart.com

Helle, Johan, Linn og Thomas er eksempler på to rotekopp-personas og to dyslektiker-personas. Disse personas ble utformet som potensielle brukere av elektroniske registertjenester og et logistikksystem.

Når personas er utviklet vil de spille rollen som brukere enten i fasen når kravspesifikasjonen lages eller i testsituasjoner, eller begge. Da vil scenarioer kunne danne rammen for dette ― personas er jo ikke levende brukere som man kan snakke med eller som kan sette seg foran skjermen på ordentlig! Scenarioer kan i denne sammenheng være korte fortellinger som nettopp peker på, og begrunner de brukerkravene eller bruksegenskapene man er på jakt etter. Personas engasjerer og øker bevisstheten om hele spekteret av potensielle brukerne når målgruppen kan gjøres mer levende.

Når det gjelder å finne mer informasjon på nettet om persona-metoden vil mange resultater vises ved søkeord personas. Vi ønsker imidlertid å rette oppmerksomheten mot forfatterne Pruitt og Grudin [referanse] samt Quesenbery [referanse] når det gjelder internasjonalt anerkjente publikasjoner om personas.

Scenario-metode

Scenario-metoden kan brukes for å strukturere og kommunisere tanker om framtiden eller situasjoner. Slike situasjoner kan i vår sammenheng handle om IKT-brukerens hverdag eller en arbeidsdag der IKT blir brukt for å løse (arbeids)oppgaver. I scenarioer inngår utviklingsbaner eller mulige hendelser som illustrerer framtiden på en troverdig måte. De er med andre ord helhetlige fortellinger som belyser situasjoner eller sammenhenger på en realistisk måte. I forbindelse med persona-metoden kan scenarioer brukes for å gi personasene omgivelser som kaster lys på bruken av IKT, og utfordringer knyttet til denne. I forbindelse med utvikling av IKT-baserte systemer kan scenario-metoden bidra til utformingen av løsninger som tar høyde for spesielle målgruppers ønsker, krav og behov, for eksempel unge personer med lese- og skrivevansker, eller eldre personer med hukommelsessvikt.

I en prosess der man benytter scenarioer søker man å avdekke samspill og avhengigheter mellom elementer innen et relevant temaområde, for eksempel elektroniske tjenester til innbyggere (for eksempel offentlige portaler), eller IKT-systemer til profesjonelle brukere (for eksempel registrering av kundeinformasjon). Denne type scenarioer er gjerne fokuserte korte fortellinger som beskriver situasjoner på en konkret måte. En mer omfattende teknikk er å utarbeide flere ulike scenarioer som er klart forskjellige alternativer, men samtidig realistiske. To helt ulike, større scenarioer vil kunne være for eksempel Informasjonssamfunn for alle og Informasjonssamfunn for de flinke og vellykkede. I hvert samfunn vil IKT-baserte tjenester framstå helt ulikt. Hvilken tilnærming til bruken av scenario-metoden man benytter, er avhengig av behov og tilgjengelige ressurser.

Uavhengig av valget mellom scenarioer som situasjonsbeskrivelser eller scenarioer som større alternative fortellinger, skiller scenario-metode seg fra andre, mer formelle metoder. Scenarioer presenteres vanligvis som prosa, gjerne krydret med treffende illustrasjoner. Scenario-metoden er tidskrevende, men den har til gjengjeld mange gode egenskaper:

• Scenarioer gir innsikt. Gjennom egenproduserte scenarioer og tilhørende analyser og diskusjoner, øker forståelsen for emnet man er opptatt av.
• Scenarioer gjør det lette å kommunisere. Framtiden gir en god ramme for en diskusjon samtidig som man kan slippe fantasien løs. Mennesker med ulik faglig bakgrunn kan lettere dele tanker og idéer med hverandre, og stoffet kan systematiseres uten formelle metoder som bare noen mestrer. Spesielt IKT-området er ofte preget av bruken av formelle metoder som utelukker mange deltakere fra analyser og utforming av framtidige systemer og tjenester.
• Scenario-metoden øker kreativiteten. Når man lager scenarioer, får deltakerne mulighet til å diskutere fritt. Nye idéer kan dukke opp, og man er mottakelig for andres idéer. Man har glede av mange ulike måter å tenke på, og det er lov å komme med avanserte idéer.
• Scenario-metoden likestiller deltakerne. Scenarioer er noe alle kan forholde seg til og kjenne seg igjen i. Dette krever ingen spesiell kompetanse. Dette er særdeles viktig i forbindelse med IKT som gjerne oppfattes som spesialistfelt med mye stammespråk.
• Scenarioer er tverrfaglige og gjenspeiler således samfunnet vi lever i. Derfor kan scenario-metode benyttes i forbindelse med praktisk talt alle fag. De inneholder gjerne både økonomiske, sosiale, kulturelle, teknologiske og politiske utviklingstrekk eller trender. Siden IKT benyttes i alle mulige fag og sammenhenger, er metoden et spesielt godt egnet redskap her.

Nedenfor gir vi en liten smakebit av scenario-metoden i forbindelse med utforming av nettbaserte tjenester. Da disse fortellingene ble laget var oppgaven å tenke på kognitive utfordringer og IKT. For å få fram brukerkrav for tilgjengelige nettjenester, ble brukssituasjonen flyttet til bilen og til stuen. På skjermen ser både Tom og Aud en nettside, selv om Tom har mobiltelefonen som sluttbrukerutstyr, og Aud har digital-TV. Etter de to scenarioene finnes spørsmål som ble brukt i analysen av hva tilgjengelighet egentlig betyr.

Scenario-metode blir brukt i mange sammenhenger. Den har blitt dokumentert i boks form og som notater på nettet. Et nettsøk vil gi mange interessante treff.

Scenario 1: DigiKart for Rent og pent fra dør til dør

Tom (28 år) er nesten alltid blid! © Clipart.com

Tom startet i Nordisk Frakt i august 1992. Han hadde fått utmerkelsen Månedens Sjåfør tre ganger i løpet av de siste årene, senest i oktober 2008. Han hadde aldri hatt kundeklager eller uhell med kjøretøyet. På grunn av gammeldags, nedslitt bilpark og byråkratiske rutiner gikk Nordisk Frakt konkurs, og Tom var uten arbeid i flere måneder.

I april 2009 besøkte han arbeidskontoret og fikk registrert seg i Jobbmail som er en tjeneste som varsler arbeidssøkeren på e-postadresse når det kommer inn sjåførjobber som passer ham. Det tok ikke mange dager før telefonen ringte. Tom fikk ny jobb på dagen hos vaskeriet Rent og Pent fra Dør til Dør. Det var akkurat Toms erfaring, kompetanse og personlighet de var på jakt etter.

Rent og Pent fra Dør til Dør er del av en arbeidsmarkedsbedrift, og den tilbyr vask og rens av tekstiler inkludert henting og levering. Størsteparten av kunder er firmaer, hoteller og sykehus, men også enkelte private kunder benytter seg av tjenestene. Spesielt gardinvask for private kunder er en populær tjeneste. Man tar ned gardinene, tar dem til vaskeriet, og henger dem opp igjen. Tom synes at akkurat denne delen av kundetjenesten er spesielt hyggelig når man oftest sitter alene i bilen uten å ha noen å snakke med.

Ellers består jobben av å gå gjennom dagens rute, og å registrere henting, levering og avvik. For alt dette bruker Tom mobiltelefonen. Selve de digitale kartene på mobilen er greie, men han synes at ruteberegning og navigeringsfunksjonalitet er litt krøkkete å bruke. Aller verst er endringer i kjøreruten om han selv vil kjøre i annen rekkefølge enn hva den ferdige ruten viser, og det å skrive inn meldinger om avvik for eksempel når kunden ikke er tilstede. Hjelpetekstene er lange og vanskelige å forstå, og skriving er nesten umulig. Tom har dysleksi, og det hele ender ofte i at han må ringe til kontoret for å fortelle hva problemet er, og få dem til å skrive inn avviksrapporten. Kanskje dette skyldes dysleksi, men faktisk klager andre sjåfører over samme problem.

Uansett, DigiKart fungerer ikke helt som sjåførene ønsker, og det oppstår mye krøll. Informasjonen i systemet blir ikke oppdatert, og inneholder mange feil og mangler. Kundene blir sure, og kontormedarbeiderne hisser seg opp. Noe bør gjøres, men hva?

Spørsmål for god tilgjengelighet for brukere med lese- og skrivevansker, og når det ikke skal vises mye informasjon av gangen (her illustrert med mobiltelefonens lille skjerm):

• Hvordan unngå informasjonsoverflod?
• Hvordan skal hjelpetekster utformes og vises til brukeren?
• Hvordan eliminere skriving generelt, og skriving av samme tekst om og om igjen?
• Hvordan hjelpe i skriving av fritekst?
• Hvordan vise hva som gikk galt og hva som bør gjøres videre?
• Hvordan kan man angre på det som ble gjort feil?
• Hvordan vise hva man har gjort og ikke gjort?
• Hvordan vise hvor man er i prosessen?
• Til slutt: Hvordan benytte disse prinsippene (det vil si svar på spørsmålene over) til nettsider på vanlig dataskjerm?

Scenario 2: Din TV-dag som medieforbruker

Aud (55 år) er en ivrig mediebruker! © Clipart.com

Aud har nylig erstattet sitt gamle TV-apparat med moderne flatskjerm, og abonnert på en digital kanalpakke. Bildekvaliteten er helt fantastisk, og det er mulig å velge blant mange tilbud. Ved hjelp av fjernkontrollen kan Aud velge både blant mange TV-kanaler og kommunale tjenester som også vises på TV-skjermen.

Aud har klart å installere den såkalte set-top-boksen, og hun vet at det er mulig å justere framvisningen til flere samtidige kanaler, bestille spesialprogram, lagre TV-program og så videre. Hun har lyst til å prøve ut alle nye muligheter. Aud er en habil TV-forbruker, men sliter med både hukommelse, syn og hørsel. Den nye TV-guiden er krevende å bruke. Man skal kunne se hva som går nå, eller hva som går snart og lete etter spesifikke program, men den virker rett og slett alt for komplisert for Aud, og hun roter seg bort. Det hun ønsker å få til er først og fremst teksting av alle program, og valg som blir lagret slik at hun ikke trenger å foreta innstillinger om og om igjen. Hun lykkes til slutt, men hun husker over hodet ikke hvordan hun fikk det til.

Heldigvis fant Aud knappen 'Din TV-dag', og våget å trykke på den. Her kunne hun krysse av ulike alternativer som beskrev hennes preferanser både med hensyn til innhold og presentasjon. 'Din TV-dag' er ment for brukere som ikke ønsker å bla gjennom alle mulige alternativer hele tiden, og justere på innstillinger. 'Din TV-dag' var Auds redning. Hun kunne velge teksting av alle program, og velge NRK som startkanal når hun slår på TVen, og vise en klokketavle øverst til høyre på TV-skjermen. Det var alt hun ville. I tillegg fikk hun adgang til kommunens tjenester som hun trengte daglig eller månedlig ― ikke minst en kobling til hjelpemiddelsentralen.

Spørsmål for god tilgjengelighet for brukere med orienteringsvansker og nedsatt hukommelse, det vil si når det ikke skal vises mye informasjon av gangen:

• Hvordan veilede nye brukere?
• Hvordan velge blant et stort antall alternativer?
• Hvordan vise mye informasjon på en målrette måte?
• Hvordan spare på valgene til neste gang?
• Hvordan lage en brukerprofil for akkurat meg?

Papirprototyping

Papirprototyper er modeller laget av fysiske materialer. Papirprototyper brukes ofte i dialogen med brukerne når man ønsker å utforme IKT-baserte systemer og tjenester. Særlig utforming av brukergrensesnittet sammen med brukere er et anvendelsesområde av denne metoden. Da brukes papirprototyper for eksempel for å:

• Illustrere skjermbilder som finnes.
• Vise fram mulig navigering fra ett skjermbilde til et annet.
• Representere handlinger som gjør at noe skjer (for eksempel at brukeren trykker på en tast).
• Illustrere hvilken informasjon som brukeren kan eller skal gi, og hvilken informasjon brukeren kan få.
• Vise hvor og hvordan informasjonen lagres.
• Vise hjelp og meldinger som er tilgjengelig når feil oppstår.

Papirprototyp er faktisk laget av papir eller lignende materiale i stedet for å for å være programmert ved hjelp av en datamaskin. En slik prototyp kan naturligvis ikke inneholde illustrasjoner av alle funksjoner som det ferdige systemet skal ha, men det er likevel mulig å illustrere sentrale elementer i utformingen. På overflaten kan papirprototypen se nokså fullstendig ut, men den mangler vanligvis mange funksjoner som den ferdige løsningen til slutt kommer til å ha.

Papirprototyper er på lik linje med andre prototyper nyttige hjelpemidler for å illustrere og kommunisere utformingsidéer til de involverte i en utviklingsprosess. Prototypene konkretiserer muligheter, og gjør det lett for de involverte å gi tilbakemeldinger.

Papirprototyper er lett å lage i forhold til programmerte prototyper, og de krever ingen spesiell dybdekunnskap om selve teknologien som man til slutt skal benytte. Det uferdige utseendet av papirprototyper forteller klart at utformingen ikke er ferdig. Dette gjør det også lettere for de involverte å kommentere prototypen.

Papirprototyper egner seg godt til å undersøke om brukere forstår betydningen av de ulike elementene i skissen til brukergrensesnittet (for eksempel knapper, overskrifter og så videre.), De egner seg også godt til å se om utformingen inneholder alle de opplysningene testpersonene behøver, eller om det er mulig å mate informasjon inn i systemet på en logisk måte. Gjennomgangen av en slik prototyp kan også gi informasjon om dette er det brukerne trenger.

Det er også morsomt å lage papirprototyper sammen med andre. Kreativiteten blir stimulert, og deltakerne henger seg ikke så lett opp i detaljer og tekniske begrensninger. Deltakerne kan til og med definere sine egne arbeidsmåter, symboler og teknikker. Det finnes ingen regler som sier hva gule lapper kan eller skal representere, eller om man skal bruke teip eller tråd for å illustrere navigering.

Papirprototyper har selvsagt også sine begrensninger. Det er mange ting som ikke så lett lar seg illustrere på papir. Eksempler på dette er multimedia og interaktivitet generelt, animasjon, lyder og skrolling. Papir lever ikke. Det er heller ikke lett å måle hvor raskt systemet vil fungere, nettopp fordi papirprototypen mangler de tekniske begrensningene som reelle IKT-systemer har. Videre må deltakerne klare å forestille seg at papirprototypen er et virkelig system eller tjeneste, selv om det kun er laget av papir. Målet med papirprototypen er å komme fram til et godt utgangspunkt for videre utvikling.

Her er noen illustrasjoner av papirprototyper:

Fra http://mickmcquaid.com/paper-proto.jpg.

Fra http://www.nngroup.com/reports/prototyping/video_stills.html.

Vi viser også til forfatteren Carolyn Snyder med utfyllende informasjon [referanse].

Testing av løsningen

Målet med brukertesting er å komme fram til et mest mulig feilfritt og brukervennlig system, produkt eller tjeneste. Veien fram dit går via kravspesifikasjoner og utvikling, til testing og forbedring. Brukertesting av kan legges opp og vinkles på mange ulike måter. Nedenfor presenteres en huskeliste som kan benyttes når man skal planlegge og gjennomføre testingen av et IKT-basert system, produkt eller tjeneste.

Brukertesting kan deles opp i fire hovedfaser:

Planlegging

Her er det aktuelt å tenke på hva man skal få vite noe om (hva som skal testes), hvilke testoppgaver skal brukeren gå gjennom, hvordan rekrutterer man testbrukere, hvem skal gjennomføre (lede) testingen, hvilke testmetoder skal benyttes og hvordan man rapporterer eller beskriver resultatene. Se veiledning nedenfor.

Gjennomføring

(Se konkret veiledning senere)

Resultatanalyse

Det er viktig å ha systematisk innsamlet materiale fra testsesjonene. Dette kan være alt fra notater til lydopptak og videoopptak. Det er videre viktig å presentere resultatene på en måte som viser hovedfunn og gir anbefalinger til tiltak. Etterarbeidet består i å oppsummere brukertestens resultater (for eksempel hva som var problematisk og hva som fungerte bra) analysere testresultatene grundig (hva var problemet og hvorfor oppstod det). Dokumentasjon er vanligvis en testrapport.

Kontroll

Tilsvarende test bør gjennomføres etter at systemet eller tjenesten eventuelt er endret eller forbedret. Hvis nye brukertester ikke viser bedre testresultater, er det svikt i testopplegget, analysen eller tiltaket.

Hovedbudskapet er at det er viktig å planlegge testingen godt, og gjennomføre den på en systematisk måte. I tillegg til det praktiske som presentert ovenfor, bør man fokusere på følgende momenter i den konkrete planleggingen av brukertesting:

Rekruttering

Resultatene fra testing blir like gode som rekrutteringen. Den lettvinte løsningen blir alt for ofte å rekruttere venner, kolleger, studenter eller familiemedlemmer. Dette er risikofylt med hensyn til påliteligheten av resultatene. Testbrukere skal representere framtidige brukere på en realistisk måte. Spesielt viktig er dette når testingen skal avdekke bruksegenskaper for brukere med kognitive utfordringer.

Avslappede og tillitsfulle testbrukere

Til tross for god planlegging, er testsituasjonen gjerne kunstig for testbrukeren. Omgivelsene er laboratorieaktige, og det er uvanlig å måtte snakke høyt om det man gjør. Mange testbrukere kan være redde for å gjøre dumme ting. For å skape en så god testsituasjon som mulig er brukerveiledningen viktig. Denne dekker alt fra beskrivelsen av hva testingen går ut på og hvor lang tid det kan ta, til den menneskelige siden av saken. I all skriftlig og muntlig kommunikasjon bør fagsjargong unngås.

Myk landing

Før man begynner med de tunge testoppgavene, kan det være lurt å spørre testbrukere hva deres forventninger til et slikt system eller teknologi er. I selve testsituasjonen vil spørsmål om førsteinntrykk være en praktisk vei videre. En myk avslutning vil være like verdifull for brukeren. En måte å gjøre dette på er å be om brukerens generelle kommentarer og eventuelle forslag.

Meningsfylte oppgaver

For testbrukere vil testing gi mening når den er organisert rundt konkrete oppgaver, som for eksempel bestilling av et produkt eller innhenting av informasjon. Selv om testingen skulle dreie seg om tekniske ting, er det viktig at testbrukere får meningsfylte oppgaver. Testbrukerne bør vanligvis ikke utsettes for mer enn én avgrenset oppgave av gangen.

Praktisk veiledning

Testbrukeren trenger en god veiledning til oppgavene som skal gjennomføres. Testoppgavene kan gjerne plasseres i en oppgavesammenheng. For eksempel: Du har fått ny arbeidsgiver. For å unngå 50% skatt i første lønning, må du bestille nytt skattekort. Det du skal gjøre for å komme i gang er ... Dersom brukssituasjonen i virkeligheten ville kreve input fra omverdenen, som for eksempel epost som inneholder et passord, et brev eller lignende, må dette gis til testbrukeren så realistisk som mulig.

Avklarte roller

Det er viktig at testbrukeren vet at testteamet ønsker å finne ut hva som ikke fungerer eller fungerer dårlig. Testbrukeren må ikke føle skyld for dårlig utførte oppgaver. For å avdekke svakheter bør testbrukeren vanligvis ikke hjelpes videre med småtips eller forslag, med mindre testen fortsetter på en naturlig måte etterpå. Kommunikasjon for å få testbrukeren til å uttrykke seg klarere er selvsagt tillatt.

Teste egen test

Sist, men ikke minst er det viktig at testoppgavene kvalitetssikres av testteamet før testbrukere skal gjennomgå testen. Testopplegger bør prøves ut på minst en normalt fungerende person før man tester det ut.

Brukertesting kan for eksempel dreie seg om å utføre tester innenfor ett eller flere av følgende emneområder (med eksempler):

Navigering

Det skal være enkelt å vite hvor man er, returnere til start, og avslutte.

Det skal være enkelt å søke.

Funksjonalitet

Funksjonene skal være klart navngitt.

Funksjonene må kunne fullføres uten avbrytelser.

Brukerkontroll

Brukeren må kunne angre på en handling.

Det må finnes klare avslutningspunkter.

Språk og innhold

Viktig informasjon og viktige oppgaver skal presenteres først.

Lenkene må fortelle hva som skal skje.

Språket må være enkelt og godt.

Hjelp og veiledning

Hjelpefunksjoner og veiledning skal være lett tilgjengelig.

Det må finnes enkel nybegynnerhjelp.

Tilbakemeldinger, interaktivitet

Systemet må gi tilbakemeldinger om hva som skjer.

Brukeren må få bekreftelse på levert informasjon.

Konsistens

Samme kode eller navn må brukes for samme funksjonalitet overalt.

Lenker/knapper skal gis selvforklarende navn.

Overskrifter skal forklare det aktuelle innholdet.

Forebygging og behandling av feil

Systemet må tåle ulike brukerstiler.

Systemet må gi klare veiledninger, inklusiv formkrav til input.

Feilmeldinger skal være synlige og med forståelig språk.

Feilmeldinger må gi en veiledning for å komme videre.

Arkitektur og visuell klarhet

Presentasjonen må være luftig nok (ikke tettpakket).

Animasjoner må unngås.

Lenkene må angi status ’brukt’ eller ’ubrukt’.

Spesialeffekter (for eksempel utheving og kursiv) skal brukes sparsomt.

Andre kriterier

Kriterier for universell utforming kan gjerne anvendes i brukertesting. Se for eksempel Deltasenterets veiledere.

Innenfor hvert emneområde bør man bestemme seg for hvilke temaer eller egenskaper som skal stå i fokus. Derfor er det viktig å avgrense testingen, og å utforme klare kriterier for karaktersetting. Dette kan gjøres ved hjelp av et skjema som observatører eller testleder bruker mens testbrukere gjennomfører sine oppgaver, for eksempel slik:

Resultatene skal presenteres gjennom grafiske sammendrag som følger:

Per utformingsprinsipp eller prinsippkategori (for eksempel navigering eller feilmeldinger) kan fordeling av karakterer vises visuelt. Ulike varianter av trafikklys blir ofte benyttet i presentasjonen av testresultater:

I den samlede evalueringen vil fordelingen av karakterene gi en pekepinn på hvor god utformingen er.

Det er selvsagt mulig å utvikle mange ulike presentasjoner av systemets eller tjenestens egenskaper. Det viktigste er dog å kunne peke på det som er vellykket, og å kunne gjøre forbedringer der hvor problemene vises tydeligst. Innenfor problemområdene må vurderingene rettes både mot innholdet av de ulike prinsipper og anvendelsen av dem.