Användningstester och experiment

Interaktionsdesign bygger till stor del på gissningar. Hur rätt man lyckas gissa beror på flera saker. Vilken kunskap man har om målgruppen man designar för, vad man vet om kognition, designprinciper och designtrender. Men kanske framför allt ska den design som gissas fram i slutändan leda till någon slags nytta för beställaren. Så vi måste också ha en djup förståelse för beställarens affärsmässiga mål.

Det låter ju inte så bra det här, att gissa sig fram. Man kan ju gissa fel, och det gör även den mest erfarna UX designer. Därför gör många av oss användningstester, för att testa hur vår målgrupp upplever produkten.

Användningstester räcker inte

Men om vi nu lär oss saker om våra målgrupper, gissar fram design, testar och justerar och gissar igen – betyder det att vår design verkligen kommer leda till den nytta som beställaren tänkte sig? Vi har visserligen eliminerat lite osäkerhet genom att se till att vi designar produkten på ett sätt som tilltalar den tänkta målgruppen. Men har vi säkerställt att målgruppen kommer vilja använda produkten när den lanseras? Inte alls. Visst, vi kan fråga målgruppsrepresentanterna om de skulle kunna tänka sig att använda eller betala för produkten men svaren kommer vara helt värdelösa eftersom människor oftast inte vet vad de vill ha eller kommer använda – speciellt när det gäller nya och innovativa produkter.

Säg att vi ska designa ett Intranät för ett företag som idag inte har Intranät. De anställda förlitar sig på maillistor för att kommunicera, vilket man tycker funkar bra. Det nya Intranätet ska effektivisera folks kommunikation vilket ska göra deras jobb mer effektivt. Efter intervjuer och analyser tar vi fram ett koncept som blir en prototyp som vi testar på olika målgruppsrepresentanter. Efter några iterationer är vi rätt säkra på att vi har ett Intranätkoncept som folk gillar och förstår. Men innebär det att de i slutändan kommer använda det nya Intranätet? Och kommer Intranätet verkligen göra de anställdas jobb mer effektivt jämfört med maillistorna?

Vi behöver sätt att säkra att vi inte bara designar rätt utan designar rätt saker. Användningstester är bra för att förbättra detaljer och lära sig mer om målgruppen men vi kommer ha svårt att testa de stora frågeställningarna. Hur attraktiv är produkten? Hur kommer användningen förändras över tid? Hur kommer den spridas – viralt eller behövs det marknadsföring? Kommer den tänkta nyttan verkligen uppstå? Får vi inte svar på dessa frågor innan budgeten är slut riskerar vi att lansera en produkt som ingen vill ha, som inte ger någon nytta och vi kan inte gör något åt saken.

MVP:er och experiment

För att få svar på dessa frågor behöver vi jobba med design och utveckling parallellt. UX-världen måste komma bort från vattenfallstänket med en lång designfas följt av en lång utvecklingsfas. För att inse om vi bygger rätt produkt innan budgeten är slut måste vi designa, bygga och leverera en minimal version av produkten tidigt – en MVP (minimum viable product). Experimentet används för att  testa hur produkten används och uppfattas på riktigt och över tid. När vi har gjort det kan vi utvärdera, intervjua användare och förbättra inför nästa version. I varje iteration lär vi oss mer om vår lösning och våra målgrupper – och vi kommer närmare att faktiskt testa huruvida den tänkta nyttan kommer uppstå. Det här är kärnan i Ries approach The Lean Startup – en bok jag rekommenderar för alla UX designers.

Groupon är en tjänst som levererar digitala rabattkuponger dagligen till miljontals människor. Men tjänsten började som en WordPress-blogg där en ny kupong publicerades varje dag. Kuponger genererades i databasprogrammet filemaker och mailades ut med hjälp av ett litet script. På så sätt kunde man testa produktidén först och när man visste att det fanns en efterfrågan gick man vidare och implementerade en riktig tjänst.

Den här typen av genvägar är vanliga i MVP-experiment. Istället för att implementera något dyrt så ”fuskar” man och testkör idén genom genvägar eller manuella handhavanden. En MVP kan också vara produktionssatt kod – men med endast den minimala funktionalitet som behövs för att få feedback på sina gissningar. Det handlar om att hela tiden identifiera vilka hypoteser man har vad som är det snabbaste sättet att validera dem.

Likheter och skillnader

MVP-experiment och användningstester är två rätt lika koncept. I ett användningstest tar vi fram ett experiment (en prototyp, interaktiv eller pappersprototyp) för att testa en hypotes – en gissning om vilken design som tilltalar målgruppen. I MVP-experimentet gör vi samma sak. Vi har en hypotes som täcker in produktidé och design. Vi tar fram ett experiment för att testa hur produkten kommer användas.

I båda fallen är det viktigt att vi är medvetna om vad våra experiment syftar till att testa. Om vi inte vet vad vi vill lära oss om målgrupperna blir det svårt att ställa rätt frågor och analysera på rätt sätt. Precis som i ett användningstest har vi en hypotes – en gissning vi vill testa. Gissningen kan avse en målgrupp, ett behov eller någon designdetalj. Men i MVP-experimentet täcker hypotesen inte bara in användarupplevelsen och användbarheten vid testtillfället – vi försöker som sagt testa hela produktidén över tid.

Jag tror att om vi som jobbar med UX kan jobba parallellt med utvecklare och lägga till MVP-experiment i vår verktygslåda får vi lättare att vara med i diskussioner om affärsmål och produktstrategi. Det blir lättare för beställare att inse hur vårt arbete hänger ihop med affären när de kan se konkreta resultat, konkreta siffror, och inte bara positiva kommentarer i ett användningstest.

Vidare läsning

The UX of MVP:s av Anders Ramsay

Experiments 101 av Simon Cast

Lean Startup is Great UX Packaging av Tomer Sharon

Lean UX is not just for lean startups av Jeff Gothelf

Att skissa för hand

I förra veckan besöktes HiQ-kontoret av interaktionsdesignern Mårten Angner som pratade skissteknik (tack Mårten!), vi fick bland annat lära oss rita raka linjer och cirklar. Men kursen handlade också om fördelarna med att skissa för att bli mer effektiv i sin kommunikation.

Delad förståelse

En grupp personer sitter i ett möte och diskuterar ett komplicerat problem. Trots att alla är superkompetenta så lyckas man inte komma överens. Men plötsligt händer något. En av personerna går fram till whiteboarden och börjar rita. Plötsligt inser man att man egentligen inte var oense, det handlade bara om att man hade olika bild av problemet. Många känner nog igen situationen.

En bild gör i många lägen ett bättre jobb än ord eller text för att få en grupp människor att nå samförstånd. En bild säger ibland mer än tusen ord. Om vi som jobbar med att kommunicera komplexa idéer har närmare till skissblocket och pennan blir vi helt enkelt mer effektiva på att kommunicera. Men de riktigt bra effekterna uppstår om vi även kan få andra runt omkring att börja kommunicera visuellt. Det handlar om att skapa en miljö där alla känner att de kan och vill skissa för hand.

Så hur får man folk att börja skissa? Det finns nog flera sätt. Man kan, som Mårten, utbilda och inspirera folk i hur man skissar snyggt och begripligt. Man kan också försöka skapa en miljö där det inte är så viktigt att det ser snyggt ut, det handlar inte om hur utan om att man över huvud taget kommunicerar visuellt.

Fånga visionen

Ett IT-projekt börjar ofta med en idé eller vision om hur nytta kan skapas. Ofta är det någon eller några i ledningen som sitter på visionen, kanske en VD, marknadschef eller teknisk chef. Visionen ligger ofta på en hög nivå som ”vi måste ha ett nytt intranät” eller ”vi behöver en mobilanpassad webb” men det finns alltid också förväntningar och föreställningar om hur slutresultatet kommer bli, även om de inte är artikulerade.

Som interaktionsdesigner vill jag förstås vara den som gör jobbet och konkretiserar visionen till något som ger organisationen affärsnytta. Men det är också viktigt att det jag jobbar fram inte skiljer sig för mycket från beställarens förväntningar. Då kommer det bli svårt att förankra och jag kanske missar att tänka på någon viktig aspekt som gör slutprodukten nyttig. Mitt jobb blir alltså lättare om jag från början förstår förväntningarna.

Jag tror skissworkshops kan vara ett bra sätt att fånga visionen och förväntningarna. Samla ihop de från organisationen som känner starkast för projektet och som fattar besluten, desto bättre ju fler olika perspektiv som finns representerade. Låt alla rita hur de tror att resultatet kommer se ut, visa upp för resten av gruppen och diskutera hur olika skisser skiljer sig från varandra och varför.

Rita wireframes för hand eller digitalt

Som interaktionsdesigner tar man fram wireframes för att kommunicera hur ett gränssnitt ska fungera, se ut och kännas. Efter skisskursen har vi i HiQ:s UX-grupp pratat en del om att rita wireframes för hand kontra i ett digitalt verktyg som Balsamiq, Omnigraffle eller Axure.

Handritade wireframes kan vara lättare att få feedback på eftersom de inte ser lika slipade ut, även om man också kan få digitala wireframes att se handritade ut. Papper och penna är flexibelt, man begränsar sig inte till ett komponentbibliotek, och de uppmuntrar till samarbete, man behöver ju inte ha något visst program installerat på datorn för att kunna bidra till skissen.

Men digitalt producerade wireframes och prototyper har också fördelar. De är lättare att uppdatera, det går ofta t.ex. att ändra på hur sidfoten ser ut på alla sidor. De är lättare att sprida till folk som inte sitter på samma plats. Det är lättare att få en känsla för hur t.ex. en webbplats hänger ihop och fungerar när man kan klicka sig igenom en interaktiv prototyp. Användningstester blir också lättare att utföra och mer realistiska när den som testar faktiskt kan klicka på knapparna, inte bara säga var man skulle klicka.

Vad är bäst då? Självklart beror det på. Det absolut viktigaste att tänka på är syftet med de leverabler man tar fram. Hur ska de användas, för att kommunicera, samarbeta eller testa på användare? Vem är mottagaren? Hur ser arbetsprocessen ut? Kommunikationsvägarna? Vilka andra dokument kommer tas fram? Framför allt: Vad är det minsta möjliga jag kan producera för att nå syftet just nu? Vad blir mest effektivt?

Om man inte funderar på syftet med leverablerna eller hur man mest effektivt når dit, utan bara slentrianmässigt kör på i sitt favoritverktyg, blir det lätt att man lägger för mycket tid på att producera onödiga dokument som ingen kommer läsa. Det gäller så klart oavsett om man ritar skisser för hand eller tar fram avancerade digitala prototyper.

Vidare läsning

The messy art of UX sketching på Smashing mag

Introduction to Design Studio på UX Magazine

Design Studios: The good, the bad and the science på UX Booth

Design Studio and agile UX på UX Magazine

The big think: Breaking the deliverables habit på Samshing mag

Boktips: Subject to Change

Subject to Change (2008) är skriven av fyra Adaptive Path-medarbetare och handlar om hur man gör för att vara framgångsrik genom att fokusera på kundupplevelse och uppmuntra förändring. Eller ja, egentligen snarare varför det är bra att fokusera på kundupplevelse och förändring än hur. Poängerna är ungefär:

Att företagen måste inse att kundupplevelse är fundamentalt för att lyckas och börja tänka på hela upplevelsen, inte bara att en produkt eller en avdelning ska leverera kvalitetsupplevelser. För att kunna ta ett upplevelseperspektiv fullt ut måste man göra kundundersökningar och kunskapen om slutkunderna ut i organisationen. Den får inte begränsas till researchers eller UX designers.

Att design och prototyping är viktigt då det låter oss testa många lösningar, förstå kundupplevelsen och samarbeta kring en lösning.

Att agil och iterativ utveckling innebär lägre kostnad, lägre risk och högre kvalitet eftersom misstag som görs under vägen inte behöver påverka slutresultatet.

Poängerna beskrivs med en massa exempel på företag och produkter som har eller inte har lyckats. Och jag tycker det var lätt att relatera det som skrivs till hur jag skulle kunna jobba på ett bättre sätt, trots att det inte finns så mycket praktiska beskrivningar av arbetssätt.

Den del som gav mig mest var den om kundundersökningar och vikten av att inte jobba isolerat. Vi som gör kundundersökningar kan leverera så mycket mer nytta om vi t.ex. involverar de som fattar besluten och de som möter kunderna varje dag.

Kort, bra, inspirerande, mycket läsvärd. Tack för lånet, Martin.

Boktips: A Project Guide to UX Design

På kurserna i Människa-Dator Interaktion på Umeå Universitet lärde man sig en massa teorier och filosofier. Jag kände redan då att något fattades och det blev riktigt uppenbart senare när man fick för sig att jobba med användbarhet ”på riktigt”. Boken Användbarhet i praktiken (som nu finns som wikibok) blev en ögonöppnare men det skulle lika gärna kunna varit den här boken, A Project Guide to UX Design, som handlar om hur man jobbar användarcentrerat i projekt. I motsats till Don’t Make Me Think som jag skrev om här innehåller den inga design-guidelines, istället handlar den om best practices för hur man kan arbeta. Den handlar om hur du fångar upp behov från beställare och användare, hur du använder dessa behov och landar i en prototyp via Personas, Site maps och Wireframes och hur du testar designen på dina användare.

Boken är släppt 2009 vilket är skönt. Innehållet känns aktuellt både i exemplen och i metoderna, man pratar aktuella designverktyg och agila projektmetodologier.

Det märks att författarna har stor erfarenhet. Boken tar ofta upp sådant som kan vara svårt i arbetet och i kommunikationen med andra projektmedlemmar. Den presenterar ofta många olika arbetssätt och listar för- och nackdelar, många böcker framför bara ett arbetssätt. I metoder för användarresearch presenteras t.ex. sex olika metoder.

A Project Guide to UX Design är som titeln antyder en guide till användarcentrerade projekt, ovärderlig för en nybakad interaktionsdesigner. För den som redan hittat ett arbetssätt man trivs med innehåller den dels alternativa arbetssätt och dels har den en massa bra insikter när det gäller relationen och kommunikationen mellan projektmedlemmar.

Är det något jag saknar så är det kopplingen mellan affärsnytta och användarnas behov, och mer om hur man prioriterar. Effektkartan skulle göra den här boken ännu bättre!