Annonsebestilling på FINN. De ulike kategoriene listes opp, og oppgaven til bruker er kun én ting – finne rett kategori. Å bruke tid på å fortelle fordelene med de ulike valgene er meningsløst, fordi ingen har noen grunn til å velge å selge leiligheten fremfor bilen. Dette er ikke-reelle valg.

Når jeg senere arrangerte en brukertest av abonnementsbestillingen til Aftenposten, dukket problemet opp igjen. Noe forenklet, så er Aftenposten tilgjengelig som både morgen og kveldsavis, eller som en av delene. (Den oppvakte leser oppdager umiddelbart at dette er et reellt valg). Pga. at Aftenposten lages i Oslo, er distribusjonskostnadene ulike i forskjellige deler av landet, dvs. dyrere på vestlandet enn i Oslo. For å spare et steg i bestillingsprosessen kan det være fristende å slå sammen stegene, slik at kunden kan velge mellom ulike “pakker”: morgen + kveldsutgave på østlandet, ditto for vestlandet, sørlandet, osv., og gjenta for alle kombinasjoner av morgen, aften og helg-utgaver. Problemet er åpenbart: Du kan velge om du vil ha morgen eller kveldsutgave, men du kan ikke velge hvor du bor. Å gjøre det på denne måten øker antall valg bruker må ta stilling til, noe som gir økt risiko for at bestillingen ikke fullføres, og at kunden blir usikker på om de har valgt rett.

For å bestille abonnement hos Aftenposten må du først bestemme deg for hvor du bor, deretter for hvilke aviser du vil ha, og deretter hvilken abonnementsperiode du ønsker. Valget om hvilken landsdel du tilhører kunne med fordel være flyttet til en egen side, slik at du slipper å se valg du i praksis ikke kan ta. For de som bor i Oslo er halve siden irrelevant, og for de som bor på vestlander er det enda mer de ikke kan velge.

Følg denne enkle regelen – skill alltid mellom ikke-reelle og reelle valg. Ha dem gjerne på egne sider i en kjøpsprosess, som vist i figuren under:

Brukere klikker seg gjennom ikke-reelle valg svært raskt fordi de allerede har svaret. Resten av prosessen vil oppleves som enklere, fordi alle ikke-reelle valg er tatt.

Se selv:
Sett inn annonse på finn.no
Aftenposten abonnementsbestilling
Hicks lov

Skilt-bilde lånt på Flickr, fra JMC Photos, CC-lisens

I forbindelse med vår nye bok Praktisk brukertesting har vi vært på jakt etter en forside. Selv om forlaget har det endelige ordet i slike saker, har hadde vi som designere selvsagt mange meninger og idéer om hvordan den kunne se ut. I denne bloggposten kan du lese mer om hvordan forsiden ble til og se noen av utkastene som ikke kom gjennom nåløyet. 

Det første forslaget så sånn ut: 

Så gav vi masse innspill til forlagets designer i Lativia. Om Don’t make me think og ander bøker som vi liker. Tegnet og forklarte. 

Mye bedre. Men vi lurte litt på hva de pilene skulle bety. “Kan vi få noen strekmennesker?” Spurte vi. 

I et annet land, lang nærmere oss selv, satt vår illustratør Anders Fagerhus og tenkte så det knakte. 

Slik? 

Eller slik? 

Eller slik ?

Vi synes kjøttkvernen var en artig idé, men fikk det ikke helt til å passe.
Så gikk det en stund. Så fikk vi nytt forslag fra Latvia i to varianter. Dette var fint, men ser de ikke litt nakne ut? 

Litt justering til og så er vi i havn: 

Nå har de fått klær på seg og både  vi og forlaget ble fornøyd. Som du kan se på f.eks. Tanum og Bokkilden  er forsiden allerede tatt i bruk og det er mulig å legge inn en forhåndsbestilling. 

Helt på tampen fikk vi et kreativt forslag fra Jon Gunnar Wolds tidligere kollega. Tydelig inspirert av sagaen om isfolket og annen kiosklitteratur. Dessverre kom det ikke gjennom nåløyet:) 

Konklusjon: Husk å gi innspill til forlag før de begynner å designe forsiden. Husk at det du lager må være tilpasset målgruppen. 

Tusen takk for alle bidrag. 

Les også: 

Ny bok om brukervennlighet – på norsk 

Slik prioritererer du etter endt brukertest 

5 tips for brukertesting av innhold 

Presentasjon: Kjør brukertester i Smidigland 

Hva synes du? Legg gjerne igjen en kommentar nedenfor.

Denne innledningen er en smakebit fra boken Praktisk brukertesting som snart er i salg. Her kan du lese noe som ikke kom med i boken, om hvordan du i praksis kan prioritere hva som må fikses etter at du er ferdig med brukertesten.

I forrige artikkel argumenterte jeg for at trivielle feil kan være viktige å fikse, dersom mange brukere blir utsatt for samme feil. Dessuten har små feil ofte fordelen at de er enkle å gjøre noe med, så du kan gjøre nettstedet eller systemet enklere å bruke med én gang. Men hvordan bestemmer du dette i praksis?

En måte å gjøre det på, er å sette opp alle feil i en slik tabell:

Dette forenklede eksempelet viser fire feil med hver sin alvorlighetsgrad. Du kan gi alvorlighetsgraden en faktor fra 1-4, hvor 4 er mest alvorlig, også ganger du med hvor mange brukere som opplevde denne feilen. Da får du en kritikalitetsfaktor¹, hvor høyest score betyr “viktigst å få fikset”.

Da kan du plassere feilene i en slik matrise:

Figuren illustrerer poenget fra forrige artikkel, men den har en potensiell fallgruve: Hva om det som ligger i “må fikses”-kvadratet faktisk ikke er enkelt å utbedre? Hva om det skyldes samhandling med andre systemer du ikke har innflytelse på? Det er ikke noe vits i å bruke tid på noe du ikke kan gjøre noe med.

Du kan få best effekt av brukertesten dersom du setter i gang med å utbedre det du faktisk kan gjøre noe med, og som vil påvirke en høy andel av brukerne. Dersom du tar resultatet fra forrige tabell og regner med en tilgjengelighetsfaktor, vil du kunne prioritere på denne måten:

Her har jeg gitt feilene poeng på en skala fra 1-10, hvor 10 er enkelt å fikse og 1 er håpløst. Hvis du legger sammen kritikalitetscore og tilgjengelighetspoengene på løsningen, vil du se enkelte forandringer i prioriteringen.

Dette er langt fra vitenskapelig, og det fritar deg ikke fra å bruke hodet. Poengskalaene har jeg bare funnet på, og vær obs på at du ikke kan bruke slike utregninger for å bevise noe som helst. Denne måten å prioritere på fungerer derimot utmerket når en gruppe skal bli enige om hva som er viktigst.

Har du erfaringer med slike måter å prioritere på, eller andre tips om brukertestanalyse? Legg gjerne igjen en kommentar.

¹: I Handbook of usability testing (Rubin & Chisnell, 2010) brukes en antatt prosent av hvor mange brukere som vil bli utsatt for samme feil, som faktor for hvordan man skal regne ut “Criticality”.

Vanlig praksis i analyse av brukertester er å liste alle feil og gi dem en alvorlighetsgrad, for eksempel kritisk, alvorlig, og triviell. Tanken bak klassifisering på denne måten er å se på hva som faktisk hindret brukerne i å gjøre viktige oppgaver. Hvis et regnskapssystem krasjer hver gang du forsøker å betale ut lønn, så er det selvsagt kritisk. Det er åpenbart for alle at det må fikses med en gang. Alvorlige feil kan for eksempel være tap av data, men at bruker til tross for store problemer kan jobbe videre eller omgå problemet. Trivielle feil kan være tvetydige navn på knapper, eller banale skrivefeil.

Så hva er problemet? Alle fokuserer på de kritiske feilene, uten å ta hensyn til frekvens. Det er ikke rart, for hele rapporten er lagt opp til det, hvis du har tilegnet feilene ulike alvorlighetsgrader. Men hvis du tar høyde for frekvens, kan listen plutselig endre seg.

Da vi i finn.no rapporterte fra brukertester, pleide vi å se på hvor mange brukere som gjorde en feil. Det var fordi vi ønsket å se frekvens som en faktor for hvor alvorlig en feil var. Dersom alle brukerne opplevde det samme trivielle brukervennlighetsproblemet, kunne det eskaleres til en høyere alvorlighetsgrad (eller prioritet på to-do lista).

Med andre ord, en triviell feil er ikke triviell dersom alle brukerne i testen ble utsatt for problemet, og en alvorlig feil er ikke nødvendigvis det viktigste å fikse dersom kun én av brukerne kom borti det. Det er ikke dermed slik at du kan avfeie en alvorlig feil, men det kan være grunn til å flytte den ett hakk ned på to-do lista.

Hvis en brukertest har gått fullstendig galt, er det naturlig å tenke at et komplett redesign eller et nytt navigasjonskonsept er nødvendig. Steve Krug hevder i sin bok Rocket Surgery Made Easy at det er mer effektivt å ta tak i de små tingene, fordi du kan gjøre en forskjell raskt. Flytt knappen, kall den noe annet, og ikke minst – rydd opp. På nettsteder og intranett kan du slette unødvendig informasjon, navigasjon og dekorasjon. I større systemer kan du flytte på ting, rydde i begrepene, skjule kompleksitet, og fokusere på de mange små bekkene som til sammen blir en stor å av ubrukelighet. Store problemer tar lang tid å fikse, koster mye penger og det kan ta lang tid å bli enige om løsningen.

Oppdatert: Les mer om hvordan du prioriterer etter endt brukertest

Les mer:
STCSIG sitt klassifiseringskjema for alvorlighetsgrader (.doc)

Norsk versjon, oversatt av Jon Gunnar Wold

Flott blogpost om “Criticality”, som er et produkt av alvorlighetsgrad vs. frekvens:
Do severe problems affect more users than trivial ones?

Rocket Surgery Made Easy, boka til Steve Krug

Hvordan klassifisere brukervennlighetsproblemer, med et fint flytskjema for å fastsette alvorlighetsgrad

Alle artikler om brukertesting: http://www.brukskvalitet.no/?s=brukertest

Praktisk brukertesting er arbeidstittelen på en fagbok som kommer i bokhandelen til våren. Jon Gunnar Wold og Eli Toftøy-Andersen er forfatterne av boken som skal utgis på Cappelen Damm forlag.  

Det er lenge siden sist det ble utgitt en bok på norsk innen fagfeltet brukervennlighet. Helt uten å vite var innholdsstrategiguruen Kristina Halvorsen  den som sparket det hele i gang. Vi fikk utdelt hennes bok på et kurs tidligere i år og Eli hvisket til Jon Gunnar: “En sånn bok burde vel vi også kunne lage”. “Det har jeg også tenkt på”, svarte han. Dermed strømmet idéene på og skrivingen begynte.

Til boken samler vi historier til kapittelet “En testleders bekjennelser”. Har du noen artige, pussige eller uvanlige historier om en brukertest? Del gjerne historiene med oss. Er du heldig, kan navnet og historien din komme med i boken.

Bilde: Flickr by See.ming Lee

Husker du de gamle “tykke” applikasjonene vi brukte før? Overraskelse: de finnes enda og nettleseren din er en av dem. Når vi lager nye lettbente webapplikasjoner av de gamle tykke applikasjonene skal disse kjøre inne i en annen tykk applikasjon – nettleseren. De som skal bruke webapplikasjonene vi lager trenger tastaturnavigasjon for å være effektive og unngå skader. Men utviklingen går i feil retning: Før mus ble vanlig var alle applikasjoner styrt med tastatur. Nå er vanlige hurtigtaster som “sitter i fingrene” allerede tatt i bruk til nettleserfunksjoner. Og for å gjøre vondt verre har ikke de ulike nettleserne de samme tastekombinasjoner.

Det lar seg løse, men det krever en innsats: Her finner du våre tips til hvordan lage tastaturnavigasjon i webapplikasjoner.

Money talks
Når økonomisjefen og IT direktøren skal kjøpe regnskapsystem som kjører i nettleseren, eller systemarkitekten skal velge rammeverk er det ett argument de hører på: Penger. Presentér et regnestykke som viser kostnadene ved å velge et rammeverk uten full støtte for hurtigtaster som fører til tregt arbeid og i verste fall sykdom og oppsigelse.

Planlegg tastaturnavigasjon fra starten
Støtte for tastaturnavigasjon må være et krav på et så tidlig tidspunkt at rammeverket som velges har full støtte for dette. Brukerhistorier må ta høyde for det, og det må testes med tastatur i utviklingen.

Må det være en nettleser?
Nettlesere har “tatt” alle de beste hurtigtastene. Det gjelder skifte av faner, lagre, skriv ut osv. slik at det som sitter i fingrene fra de tykke applikasjonene ikke lengre kan brukes. Men kanskje du har mulighet til å bruke et annet kjøretidsmiljø? Et eksempel er rammeverket Flex fra Adobe som kan kjøres i Adobe Air-miljøet.

Gi hint om hurtigtaster i applikasjonen
Understreking av en bokstav viser at en tastekombinasjon aktiverer menyen eller funksjonen. Tooltips i menyer kan gi hint om at tastatursnarveier kan benyttes. Dette støtter gradvis læring og hurtigtaster oppdages lettere uten å pugge brukerveiledningen.

Vær konsekvent
Dersom Alt+bokstav eller Ctrl+bokstav kombinasjonen ikke er tilgjengelig fordi den er lagt beslag på av nettleseren kan du bruke Alt Gr. tasten eller shift som et alternativ. Hvis du gjør dette helt konsekvent vil bruker kunne huske at det er Alt Gr + en bokstav som fungerer. Dersom lagrefunksjonen bruker Ctrl+S i din applikasjon mens alle andre bruker Shift+bokstav vil det trolig være enklere om alle brukte Shift+S.

Pass på Tab-rekkefølgen
Tab-navigasjon gjelder ikke bare innenfor skjema, selv om det er viktig nok. Navigasjon mellom komponenter i skjermbildet skal også fungere. Dersom du på ikke kan bruke standardkombinasjoner for lagre, skriv ut m.fl. er det desto viktigere at Tab-rekkefølgen er effektiv. Det beste er å kunne bruke Tab for å skifte fokus mellom f.eks. to tabeller, og at eksempelvis piltastene lar deg navigere i selve tabellen.

Kast musa
Koble fra musa di og bruk en applikasjon eller webside utelukkende med tastatur. Det er lærerikt og gir god innsikt i hvordan du kan gjøre tastaturnavigasjon enkel og effektiv for brukerne. Først da får du sjekket om samtlige kontroller i applikasjonen er tilgjengelig via tastatur.

Andre tips

• Plassér automatisk markøren i første felt i skjemaet og spar bruker for et klikk
• Validér skjema etterhvert som bruker fyller ut. Det gir mer effektiv tastaturnavigasjon
• Ikke glem feilmeldingene – Flytter de markørens fokus uten at bruker vil det? Kan de lukkes med Esc-tasten?
• Lær deg rammeverket – det kan ha innebygget støtte for tastaturnavigasjon. Finn ut hvilke taster det er som brukes
• Bruk standarder! Brukerne forventer spesiell oppførsel fra Enter, Tab, Mellomrom, PgUp, PgDn osv.

Allment tilgjengelige apps med tastaturnavigasjon:

• Google Reader
• Gmail
• Remember the milk

Mer om tastaturnavigasjon

• W3 validatorens hurtigtaster
• Navigasjon og tilgjengelighet (Engelsk)
• UK Government access keys standard (Engelsk)
• Wikipedia om Access keys (Engelsk)
• Microsoft GUI-standard for tastaturnavigasjon (Anbefales)

Kjenner du til flere applikasjoner som har tatt i bruk tastaturnavigasjon? Del dem med oss i kommentarfeltet. (NB: Fler enn to linker i en kommentar blir tatt av spam-filteret, si i så fall fra dersom den ikke dukker opp så vi kan godkjenne den manuelt).
*****************
Oppdatert: Her er lenke til presentasjonen jeg holdt på Javazone 9/9-2010: Keyboard navigation in web apps is NOT optional (PDF med engelske kommentarer, 2471 KB)

Må webredaktøren bli en webdiktator for å stoppe publisering av uinteressant innhold? Foto: Flickr by mpldesign

I følge Gerry McGovern bør vi kutte kraftig ned på antall sider
som publiseres på et nettsted fordi kun et fåtall faktisk blir lest. Uinteressant innhold gjør det vanskelig for brukerne å finne det de trenger. Webredaktører som har forstått dette må være strenge. Å bestemme hva som skal få plass en webside for en stor organisasjon er som å pakke til langtur i en litt for liten koffert. Det er ikke plass til alt.

Avslag og sletting kan føles urettferdig for flittige innholdsprodusenter som ikke får sine publiseringsønsker oppfylt. Det er likevel strengt nødvendig. Litt til og litt til blir ganske mye til sammen. Selv etter en grundig opprydning er fort gjort å komme i en ny kaossituasjon der det blir vanskelig å finne frem og umulig å holde kontrollen.

10 gode grunner til å gi avslag
1. Informasjonen er ikke beregnet for noen av målgruppene
2. Informasjonen hjelper ikke målgruppene å ta beslutninger eller å nå sine mål
3. Kvaliteten på teksten er ikke god nok (følger ikke retningslinjene)
4. Teksten er for lang
5. Informasjonen finnes allerede på et annet sted i strukturen
6. Erfaringstall viser at denne typen informasjon ikke blir lest
7. Den nye informasjonen vil bryte med logikken og prinsippene for hvordan forsiden spesielt og websiden generelt er bygget opp. (f.eks. vi skal ikke ha bannerannonser)
8. Informasjonen er konfidensiell
9. Informasjonen er gått ut på dato
10. Den totale mengden informasjon på websiden må holdes nede, vi kan ikke få plass til alt.

En webredaktør må med andre ord tørre å si nei til innhold. Som interaksjonsdesignere er vi også med å påvirke den totale informasjonsmengden gjennom kartlegging og informasjonsstrukturering. Kanskje det vi trenger egentlig er webdiktatorer?

Vil du dele din erfaring eller synspunkter?  Skriv gjerne en kommentar.

Flere artikler fra brukskvalitet.no
5 tips for brukertesting av innhold
Slik skaper du en god brukeropplevelse
Redd miljøet med bedre informasjonsdesign

Relevante lenker
Work accessibility into your content strategy (26.05.2010)
Hata information. Att skriva för webben är att skriva för effekt. (26.05.2010)
What is the Long Neck and why should you care? (26.05.2010)

Dette er en enkel instruksjonsvideo som viser de mest grunnleggende trinnene i det å planlegge en brukertest.

For tilgjengelighetens skyld er filmscriptet gjengitt her:

Stein på stein – hvorfor rekkefølgen av tingene som må planlegges er viktig

1. Hva er formålet med brukertesten?
Er det å skaffe innsikt i faktisk bruk, eller vil vi vite om systemet er lett å lære for nye brukere? Det er viktig at formålet med testen er forankret hos alle beslutningstagere.

2. Hvilken funksjonalitet skal testes?
Vi kan ikke teste alt. Ut fra hvilket formål vi har med testen, må vi bestemme hvilke funksjoner i systemet som skal testes.

3. Hva slags system skal du teste på?
Hvor er den funksjonaliteten som skal testes tilgjengelig? Er det en spesiell versjon av systemet, er det test eller produksjonsdata, eller kanskje en prototype?

4. Hva slags brukere skal få komme og teste?
Hvem er den funksjonalitet som skal testes tiltenkt? Definér målgruppen og andre kriterier for utvelgelse av brukere, og hvor du skal få tak i dem.

5. Hva slags testutstyr skal brukerne benytte?
For å gjøre testen så realistisk som mulig for målgruppen må du gjenskape faktisk bruk. Det er ikke sikkert alle har en 24-tommer skjerm og bredbånd slik som du har.

6. Hvilke oppgaver skal brukerne få?
Lag realistiske oppgaver som dekker den funksjonaliteten som skal testes. Du må også definere hva som er sukesskriteriene for disse oppgavene.

Som du ser er planlegging en sekvensiell prosess. Valgene du tar underveis påvirker de neste og hjelper deg å holde fokus. Dersom det ikke er tydelig hva formålet med testen er, vil du ha store vanskeligheter med å beslutte de neste trinnene.

Slik planlegger vi en brukertest. Lykke til.

Som systemeier ønsker man å vite hva som er de mest vellykkede og de mest problematiske funksjonene til et system i forhold til oppgavene det er tenkt å løse:

• Hjelper systemet den tiltenkte målgruppen?
• Hva slags problemer har brukerne?
• Hvem bruker egentlig systemet?
• Hvorfor blir ikke systemet brukt slik vi ønsker?
• Hva slags spørsmål får superbrukerne våre?
• Hva kan gjøres for å korte ned opplæringen?
• Finnes det funksjonalitet som ikke brukes og kan fjernes?
• Har vi nådd målene for effektivitet/brukskvalitet/saksbehandlingstid?
• Kan innspill fra brukerne systematiseres på noen måte?

Vanligvis har den forutseende systemeier sørget for at viktige metrikker logges når systemet brukes. Men logganalyser kan bare fortelle deg halve historien – dvs. du ser hva som blir brukt, men aldri hvordan eller hvorfor. Med undersøkelser som brukerintervjuer og brukertester får du innsikt i hvilke områder av systemet som trenger forbedring. Da kan du bruke forvaltningsbudsjettet på å videreutvikle det som er viktig for at systemet forblir en suksess.

Brukerintervjuer med representanter fra målgruppen er en enkel og positiv måte å få innsikt i hvordan systemet ble mottatt og hva brukerne sliter med og de setter pris på å få dele sine erfaringer.

Brukertester gir stor innsikt i hvordan systemet egentlig brukes og kan for de som observerer for første gang bli en åpenbaring. Innsikten gjør at man enklere kan prioritere hva som skal utvikles.

Brukerdagbøker systematiserer tilbakemeldingene fra brukerne. Man kan velge ut enkelte brukere som fører dagbok over sin bruk av systemet, eller man kan be superbrukerne skrive en logg over alle spørsmål de får – når informasjonen er samlet inn og systematisert har du et godt bilde av hva brukerne trenger.

Konklusjon
Forvaltning er mer enn bare oppetid, det handler også om å forvalte brukeropplevelsen. Hvordan vet du hvilken funksjonalitet som er mest brukt, hvilken funksjonalitet folk sliter med og hva du kan fjerne? La brukerne medvirke slik at forvaltningsbudsjettet kommer dem til gode.