Ethvert digitalt udviklingsprojekt starter med gode intentioner. ”Vi skal følge processen. Gøre det rigtigt den her gang. Alt skal sidde lige i skabet…”
Men ak og ve, tidsplanen rykkes og budgettet ædes langsomt op af uforudsete ønsker.
Og ni ud af ti gange, hvad er det første, der skæres fra?
Brugertesten.
Resultatet er, at man udkommer med subpar produkter, der spænder ben for brugerne. I værste fald resulterer det i dyre fejl og tidskrævende, manuel håndtering efterfølgende.
Med andre ord, det ender i en skilsmisse: Brugeren bliver utilfreds og skifter til konkurrenten.
Årsagerne er mange og varierer selvfølgelig fra projekt til projekt.
Men her er nogle af de vigtigste, der ofte går igen — du er mere end velkommen til at dele dine egne erfaringer i kommentarfeltet.
Til sidst får du også et par helt lavpraktiske råd med på vejen til, hvordan du kommer godt i gang med brugertests. Også her er du selvfølgelig velkommen til at tilføje dine erfaringer i kommentarerne.
En af årsagerne er, at digitale projekter stadig udvikles efter den gamle model — Projekttrekanten.
Hvor der er fast scope, fast budget og fast deadline.
Og når tidsplanen og budgettet uundgåeligt skrider, så skal der prioriteres, og funktioner bliver helt sikkert prioriteret over brugertest.
Det er et problem, der bedst løses af en agil udviklingsproces, hvor projekter planlægges og eksekveres dynamisk… Men det er et helt indlæg i sig selv, som jeg ikke vil gå i dybden med her.
Årsag nr. to: Vi kender alle til virksomheder, der har det strategiske pejlemærke, at de vil sætte ’kunderne i centrum.’
Men faktum er desværre, at det ofte bare er noget, vi leger.
Der dedikeres sjældent tid, penge, ressourcer og arbejdskraft til at indsamle viden om brugerne, deres behov, deres forventninger, adfærd og ikke mindst, de adfærdsændringer virksomheden ønsker at skabe med de nye projekter. Igen skæres brugertest fra.
Stil krav til jeres ansatte, til jeres projekter og til jeres samarbejdspartnere!
Dygtige ledere ved, at brugerindsigter og -tests bør prioriteres på strategisk plan.
Ledelsen skal udstede tydelige retningslinjer og målsætninger for, hvordan de ansatte skal løfte barren på vegne af kunden: Både før, under og efter brugeren er blevet kunde.
De ansatte skal altså vide, hvordan de aktivt støtter forretningens strategiske mål i deres arbejde med brugeren. Og de skal vide, at de bliver målt på det.
Alle afdelinger skal støtte op om projektet og forstå, at de også skal hjælpe med indsigter og rekruttering af brugere til test: Det er ikke en solodisciplin – alle skal bidrage på tværs af organisationen.
Opsæt derfor også gerne mål på tværs af organisationen.
Intet er dyrere end at udkomme med et produkt, der er fuldt af fejl.
Og sandheden er, at brugertests kan gøres for (forholdsvis) små midler, hvis det gøres ordentligt.
Tricket er at brugerteste INDEN, der kodes, så der ikke spildes tid på at udvikle dyre funktioner, der ikke virker optimalt.
Jo tidligere, jo bedre.
Ligesom med udviklingen bør brugertesten brydes ned i mindre iterationer med et tydeligt formål: Opstil en klar og tydelig hypotese for brugerne og deres adfærd, det er den vi skal have valideret gennem test. Opsæt tydelige mål for succes!
I skal altså ikke teste alt. Identificér kerneopgaverne, som brugeren skal løse og fokusér på at minimere benspænd.
Brugertests starter oftest med at identificere mønstre for adfærd.
Opsæt jeres testhypotese på baggrund af eksisterende data eller kvantitative brugertests.
Her er et par eksempler på, hvordan man kan indsamle brugerfeedback:
Mange af jer laver sikkert allerede ovenstående i nogen grad, men hvis ikke, så kan det kun gå for langtsomt.
Kvalitative brugertests går i dybden på udvalgt funktionalitet. Desværre er det oftest her, der skæres hjørner.
Men kvalitative brugertests behøver hverken være dyre eller komplicerede.
Min personlige favorit er ’tænke-højt testen.’
Her stiller man brugeren en række spørgsmål og opgaver, som de skal løse. Der observeres, mens brugeren højlydt fortæller om tvivl, iagttagelser og følelser undervejs. Testen kan laves fysisk eller online.
Testpersoner kan i de fleste tilfælde rekrutteres alle steder: Sociale netværk og e-mail lister er et godt sted at starte. Men de kan også rekrutteres i jeres fysiske forretninger, når de besøger jeres hjemmeside eller via et opkald.
De kan sågar findes på gaden og på caféer.
Vi anbefaler, at man som minimum altid tester på mindst 6 relevante personer fra hver målgruppe.
Men husk, at det er altid bedre at teste på én end slet ingen.
I kan endog teste på jeres kollegaer i mangel af bedre! Og I kan teste på alt fra papir til computer, tablet og mobil.
Brugbare, kvalitative brugertests kræver ikke længere et stort, teknisk setup.
Fejl bør prioriteres efter vigtighed for brugeren.
Men hvordan kategoriserer OG prioriterer man egentlig vigtigheden overfor brugeren, før løsningen er lanceret?
Vores venner hos NN Group har identificeret nedenstående faktorer som værende vigtige, når vi kategoriserer fejl. En metode som jeg også benytter:
På baggrund af ovenstående kategorier kan man give sine fejl en score fra 0-4.*
0. Der er intet usability problem
1. Kosmetisk problem, der ikke skal nødvendigvis rettes medmindre, der er overskydende tid i projektet
2. Mindre usability problem
3. Større usability problem
4. Kritisk usability problem/Katastrofe: Fejlen skal rettes inden, produktet kan frigives
Altså, har fejlen en lav frekvens, der påvirker brugeren i mindre grad, kan det kategoriseres som et kosmetisk eller mindre usability problem, et eksempel kan være, at en tekst rykker sig lidt i en mobilvisning i en browser, som benyttes i lav grad.
Er der en høj frekvens, har det en høj påvirkning med høj vedholdenhed og/eller har det en stor effekt i markedet, så er usability problemet større og skal rettes med det samme, et eksempel kan være, at brugerne ikke kan logge ind i en browser, der benyttes ofte.
Jeg håber, at ovenstående er med til at give et lidt tydeligere billede af, hvor vigtige brugertests er, og at du sagtens gå komme i gang i det små, uden at det behøver medføre en komplet omstrukturering af jeres proces.
Og husk, tager du kun én ting med dig herfra, så lad det være det her:
Det er altid bedre at teste på én end slet ingen.
Charlotte Staun Christensson
Head of Strategy & Experience
csc@pentia.dk
+45 3164 0108
