Digital produktudvikling uden brugertest ...

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 bliver rykket og budgettet ædes langsomt op af uforudsete ønsker.

Og 9 ud af 10 gange, hvad er det første, der skæres fra?

Brugertesten.

Resultatet er, at du 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.

Hvorfor går det galt?

En af årsagerne er, at digitale projekter stadig bliver udviklet 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, du bedst kan løse med en agil udviklingsproces, hvor du planlægger og eksekverer projekterne dynamisk … men det er et helt indlæg i sig selv, som jeg ikke vil gå i dybden med her.

En reel udfordring med Projekttrekanten er, at den sjældent går godt i spænd med de praktiske processer bag, hvad det nøjagtig indebærer at være ”kundecentrisk”.

Å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 bliver sjældent dedikeret 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 bliver brugertest skåret fra.

Ansvaret er ledelsens

Stil krav til dine ansatte, til dine projekter og til dine 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.

Test ofte, test småt OG SPAR PENGE

Intet er dyrere end at udkomme med et produkt, der er fuld af fejl.

Og sandheden er, at du kan brugerteste for (forholdsvis) små midler, hvis du gør det ordentligt.

Tricket er at brugerteste INDEN, der du koder, så du ikke spilder tid på at udvikle dyre funktioner, der ikke virker optimalt.

Jo tidligere, jo bedre.

Ligesom med udviklingen kan det være en god idé, at du bryder brugertesten ned i mindre iterationer med et tydeligt formål: Opstil en klar og tydelig hypotese for brugerne og deres adfærd. Det er den, du skal have valideret gennem test. Opsæt tydelige mål for succes!

Du skal altså ikke teste alt. Identificér kerneopgaverne, som brugeren skal løse og fokusér på at minimere benspænd.

Kom godt i gang med brugertesten

Brugertests starter oftest med at identificere mønstre for adfærd.

Opsæt din testhypotese på baggrund af eksisterende data eller kvantitative brugertests.

Her er et par eksempler på, hvordan du kan indsamle brugerfeedback:

• Lave A/B splittest
• ’Fake door’-test
• Lave ’surveys’ eller ’polls’ ’onsite’ med fx Typeform
• Gennemse din analytics, og se, hvordan brugeren finder rundt, og hvor de falder fra
• Brug systemer som fx Hotjar til at overvåge brugerens adfærd
• Og nu hvor vi er i gang, hold øje med Trustpilot og andre relevante anmeldelsessider såsom Apples App Store.
  
  

Mange af jer laver sikkert allerede ovenstående i nogen grad, men hvis ikke, så kan det kun gå for langsomt.

Gå i dybden med kvalitative brugertests

Kvalitative brugertests går i dybden på udvalgt funktionalitet. Desværre er det oftest her mange skærer hjørner.

Men kvalitative brugertests behøver hverken være dyre eller komplicerede.

Min personlige favorit er ”tænke-højt-testen.”

Her stiller du brugeren en række spørgsmål og opgaver, som de skal løse. Du observerer, mens brugeren højlydt fortæller om tvivl, iagttagelser og følelser undervejs. Du kan lave testen fysisk eller online.

• Du kan vælge at benytte ”tænke-højt-testen” på dit eksisterende produkt for at lære af tidligere fejltrin.
• Du kan sågar lave ”tænke-højt testen” på konkurrerende produkter for at se, hvad de har gjort godt og mindre godt.
• Du kan teste på tidlige konceptskitser for at validere en ny idé.
• Du bør som minimum altid teste på en prototype, der ligner det færdige produkt.
• Endeligt kan du selvfølgelig også teste på det endelige produkt, når det er udkommet. Men sæt for himlens skyld tid, mandskab og penge af til fejlrettelser.
  
  

Du kan i de fleste tilfælde rekruttere testpersoner alle steder: Sociale netværk og e-mail lister er et godt sted at starte. Men du kan også rekruttere dem i dine fysiske forretninger, når de besøger din hjemmeside eller via et opkald

De kan sågar findes på gaden og på caféer.

Vi anbefaler, at du som minimum altid tester på mindst 6 relevante personer fra hver målgruppe.

Men husk, at det altid er bedre at teste på 1 end slet ingen.

Du kan endog teste på dine kolleger i mangel af bedre! Og du kan teste på alt fra papir til computer, tablet og mobil.

Brugbare, kvalitative brugertests kræver ikke længere et stort, teknisk setup.

Prioritering af fejl

Prioritér fejl efter, hvor vigtige de er for brugeren.

Men hvordan kategoriserer OG prioriterer du egentlig vigtigheden overfor brugeren, før løsningen er lanceret?

Vores venner hos NN Group har identificeret nedenstående faktorer som vigtige, når vi kategoriserer fejl. En metode, som jeg også benytter:

• Frekvens — altså hvor ofte optræder fejlen?
• Påvirkning — hvor svært er det for brugeren at komme videre?
• Vedholdenhed — er det et enkeltstående problem, eller vil det påvirke brugeren gentagne gange?
• Effekt i markedet — hvor meget vil fejlen påvirke produktets eksistensberettigelse? Vil brugere vælge det fra?

På baggrund af ovenstående kategorier kan du give dine fejl en score fra 0-4*:

1. Der er intet ’usability’-problem.
2. Der er et kosmetisk problem, der ikke nødvendigvis skal rettes – medmindre, der er overskydende tid i projektet.
3. Der er et mindre ’usability’-problem.
4. Der er et større ’usability’-problem.
5. Der er et kritisk ’usability’-problem/katastrofe: Fejlen skal rettes, inden produktet kan frigives.

Så: Har fejlen en lav frekvens, der påvirker brugeren i mindre grad, kan du kategorisere det som et kosmetisk eller mindre ’usability’-problem. Et eksempel kan være, at en tekst rykker sig lidt i en mobilvisning i en browser, der ikke bliver benyttet særlig ofte.

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 bliver benyttet ofte.

Need help? Ræk ud!

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 din 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å 1 end slet ingen.