User Experience, UX, er blevet et buzzword i software udvikling og med god grund; når det bruges rigtigt sætter det brugen af produktet ind i en større kontekst af brugerens liv. Det bidrager til udviklingen af gode produkter med uventede løsninger. God user experience er hele brugerens oplevelse af brugen af produktet – og alle brugeres oplevelse; udviklere, sælgere, brugere, kunder, kunders kunder.
Det betyder at Usability Tests er ubrugelige. I bedste fald identificerer de småproblemer man ikke selv havde set. I værste fald bekræfter usability testen større issues man selv kunne have set. Usability tests fastholder både brugeren og testeren i den eksisterende programtankegang. Dermed står usability tests ofte i vejen for den kreative, geniale, uventede løsning.
En god, traditionel usability test har ofte et færdigt eller halvfærdigt produkt som vises for en række brugere. Til produktet hører der et ark fastdefinerede opgaver hvortil testeren naturligvis har defineret ”det rigtige svar”. Dette påfører et måske ubevidst pres på brugeren, der gerne vil finde det svar til testeren. Både brugeren og testeren mister værdi når brugeren ikke kan finde svaret som systemet er designet for værdien findes i at lade brugeren finde det rigtige svar på sin egen måde.
Ydermere ser usability tests bort fra kontekst – ofte tester man navigationen af systemet og fokuserer på at brugeren skal finde de rigtige knapper og indtaste forudbestemte information andre steder. Her mister vi processen op til – hvordan ved de hvad de leder efter/skal indtaste? Hvordan ville de normalt få værdi ud af det her? Og netop værdibegrebet begynder at åbne op for de rigtige spørgsmål; hvordan understøtter vi hele processen omkring at vores bruger skaber værdi gennem brugen af vores produkt?
God User Experience opstår ikke kun foran computeren
God User Experience er svær at designe til da den netop opstår lige så meget uden om produktet som i selve interaktionen. Brugerens behov opstår oftest i den ”virkelige” verden, gennem relationer med andre, udvikling eller mål.
Behovet opstår før produktet. Dermed skal det gode produkt designes ud fra en forståelse af brugerens liv. Brugeren er ikke længere en anonym ”bruger” men bruger produktet med et formål, med følelser, tanker og refleksion. Og det er dén vi skal have fat i – vi skal ud og stjæle deres viden, antænde deres fantasi og følge deres tanker til ende. Når vi først har lavet produktet er det for sent (og for dyrt) at lære at programstrukturen er ulogisk.
Papirprototyper, workshops og samtaler kan være med til at åbne op for et rum hvor brugeren får plads til at reflektere over egen praksis, forestille sig muligheder og illustrere problemstillinger. Refleksion kan understøttes ved at gå igennem deres hverdag med dem, stille dem spørgsmål om stort og småt. Workshops med genstande og problemstillinger kan få flere brugere til at indgå i dialog omkring et givent felt. Samtaler kan åbnes med grimme tegninger af interfaces som de gerne vil tegne ovenpå (så er det også lettere at fastholde data).
Papir prototyper fastholder tankegange på et lavpraktisk niveau, hvordan er det basale layout og beskriver hvordan interaktionen kan være. De kræver minimalt træning at udføre. Det vigtigste er at de er brugbare som kommunikationsmiddel så de formidler designerens tanker – både over for brugeren, men også over for programmøren, manageren eller hvem der nu ellers måtte være involveret i denne proces. Det er en hurtig afsøgning af mange mulige programstrukturer, som kan testes hurtigt og effektivt – helt uden at kode.
På den måde sikres en non-negotiable programstruktur, der er klart defineret ud fra brugerens analoge såvel som programmørens digitale behov.
Hej, super indlæg.
Har i et tidligere job kæmpet meget med at få de grafiske folk til at lave en serviettegning el. lign. før at de åbnede Photoshop – men det er aldrig rigtig lykkedes.
Hvordan får vi dem til det?
Og så synes jeg at det er vigtigt at vi stadig viser det halv- og kvartfærdige produkt, men det er nok senere i processen …
Rebeller i software test branchen som fx. Carsten (https://qed.dk/gaestebloggen/author/carstenff/), mig mfl. går netop og argumenterer for at bundne scripts IKKE giver hele svaret. Og at man med langt simplere værktøjer nemme kan få fat i hvad der egentligt er vigtigt for brugerne.
Se også:
Om de kontekst drevne principper: – https://qed.dk/gaestebloggen/2014/01/31/om-de-kontekst-drevne-principper/
Testing is like connecting the dots – http://jlottosen.wordpress.com/2013/03/28/testing-is-like-connecting-the-dots/
The day testing died, but didn’t: – http://www.ministryoftesting.com/2014/01/day-testing-died-didnt/
Super indlæg! -Godt indblik i hvordan UX fungerer i praksis. Skarpt fokus og klare konkrete situationer. MERE!!!
Mange tak for kommentarerne 🙂
Og Poul: Super spørgsmål! Jeg er ved at lave en UX-brevkasse, det kan være jeg må gemme det spørgsmål til kick-off af denne? Så kan jeg også gå meget mere i dybden med dit spørgsmål 🙂
/M
Hej Mathilde,
Tak, det er du meget velkommen til. Har tit hørt den her: “Everything starts with the [photoshop] comp”.
Blev gjort opmærksom på at jeg skrev grafiske folk og ikke UX’ere – jeg tror dog tit at det på godt og ondt er de samme folk.
[…] til denne brevkasse besvares fra et User Experience perspektiv. Dagens spørgsmål udspringer af denne artikel. Er der spørgsmål, der ønskes besvaret kan disse finde vej til mig via håndskrevne med tusch […]
“Behovet opstår før produktet. Dermed skal det gode produkt designes ud fra en forståelse af brugerens liv.” Men hvad så med de apps som man ikke vidste man havde brug for, men som man ikke kan undvære efter 10 min 🙂
Jeg er enig med dig i at man ofte får brugerne deltager bedre i en design diskussion når man bruger blyant tegninger og simple mockups, men jeg syntes ikke man kan sige at man skal gøre det istedet for usability tests, de to ting forgår to forskellige steder i udviklingen af et projekt.
Når man med hjælp af blyant tegninger og kunden er kommet frem til nogle user stories, der typisk bliver beskrevet ved hjælp af en række trin, er det vigtigt at få netop den forretnings gang verificeret, det kan gøres ved usability tests. Det er en rigtig god ide at starte usability test med at brugerne kan lege med systemet, men ofte er det specifikke flows som skal afprøves, så som at købe en bog på web sitet, logge ind eller lignende som man skal være sikker på at det bliver gennemgået.
Men skal man implementering der løser et allerede eksisterende behov, så burde man sende spioner ud, som kan kigge folk over skulderne og undersøge hvordan brugerens behov udmønter sig og hvilke arbejdsgange det forgår. Af to grunde for det første er det min oplevelse at brugerne sjældent ved præcis hvad og hvordan disse udføres, og fordi de workshops som holdes, ofte ikke indeholde slut brugeren, eller at kunden og slut brugeren ikke er de sammen, og derfor ikke har samme interesse i at lave en god applikation. Har du oplevet det samme?
EDIT: Efter at have læst din næste post, må jeg hellere sige tusch tegninger istedet for blyant tegninger 😀
Hej Kim,
Det er netop min pointe at man skal ind og kende brugeren så godt at man dermed får mulighed for at se hvor de mangler det fantastiske produkt (dit produkt) som kunne gøre deres liv bedre. Et af de bedste usability-råd jeg har fået er “Never listen to your users”, underforstået – se på hvad de gør, forstå deres motivation fremfor bare at lave den blå fordi det har de sagt de vil have…
Det vil dermed også sige at man tager fat i slutbrugeren – en god UX’er finder overbevisende data til sin kunde som beviser dem om at den skal være rød, selvom brugeren har sagt blå. Igen så er det en inddragelse af hele konteksten omkring applikation både din bruger og dennes miljø, men så sandeligt også de involverede stakeholders – det betyder både kunden, men også dine udviklere som jo også i en eller anden forstand bruger dit produkt. En god UX’er tænker på dem alle når programstrukturen fastlægges og laver et godt produkt; et som et brugbart for slutbrugeren og for alle involverede optil 🙂
viva la (tusch) revolucion <3