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

Värdet av tidig feedback

Man har suttit och jobbat stenhårt på ett designkoncept som man tycker känns helt rätt. Men när det sedan ska presenteras för dem som bestämmer (i konsultfallet, kunden) så kommer det bara negativa kommentarer och man blir tvungen att börja om från början. Det här är riktigt jobbigt. Det sänker ens självförtroende, sinkar projektet och kostar pengar. Och det handlar, enligt min erfarenhet, sällan om att designen verkligen är så dålig utan snarare om brist på kommunikation och förankring.

Lösningen på många problem som man hamnar i som interaktionsdesigner heter tidig feedback, korta feedbackloopar och samarbete. Vi behöver tidig feedback både från kunden, från användarna och från våra kollegor.

Tidig feedback i användarundersökningar

När vi tar reda på vilka användarna är och hur deras behov och egenskaper ser ut är folk som jobbar i organisationen en källa till information. Deras bild av användarna stämmer i vissa avseenden med verkligheten, men är i andra avseenden är helt fel. En organisation som säljer mycket kan t.ex. ha koll på vilka köpbeteenden folk har men inte veta varför kunderna köper just deras produkt. När vi tar reda på vad som ligger bakom är det viktigt att vi får feedback från olika delar av organisationen tidigt.

Dels kan vi ha förstått något fel. Det kan finnas information som vi missat eller misstolkat som andra i organisationen kan hjälpa oss med. Dels blir det lättare för folk att acceptera resultatet av undersökningen (som ibland kan vara kontroversiellt) om vi presenterar det stegvis istället för i ett långt, tråkigt dokument. Dels kan vi om vi tar hjälp av personer från organisationen för att analysera resultatet lyckas få dem att se saker på vårt sätt, ur slutkundens perspektiv. På så sätt kan undersökningen göra nytta långsiktigt genom att bygga en kundorienterad kultur hos organisationen, vilket beskrivs i boken Subject to Change.

Tidig feedback i designprocessen

Alla kan tycka saker om design och oavsett hur mycket användarundersökningar vi har som kan motivera våra designval kommer folk alltid tycka saker om vår design. Ett sätt att reducera tyckandet är att låta tyckarna ge feedback och delta i designprocessen, gärna tidigt. Det blir ju som sagt lättare att acceptera ett resultat när man varit med och fått påverka det under framtagandet. Man behöver inte begränsa sig till feedback utan kan till och med låta tyckarna vara med och designa, t.ex. i en design studio-workshop.

Med hjälp av användningstester kan vi få feedback på designen från de vi designar för; användarna. Användningstester kan också göras riktigt tidigt, när det bara finns en idé om hur tjänsten ska utformas eller en grovskiss på papper. Det behövs inte interaktiva prototyper och det behöver inte ta speciellt lång tid.

Det kan också vara guld värt att få tidig feedback från kollegor. Andra interaktionsdesigners kan hitta designproblem som vi inte tänkt på. Utvecklare och arkitekter kan påpeka tekniska problem som vi måste ta hänsyn till. Vi ska göra det som är bäst för användarna och vill i en perfekt värld inte låta teknik styra design alls men i realiteten behöver vi nästan alltid kompromissa eftersom någon detalj kommer vara alldeles för dyr att implementera.

Rädslan för tidig feedback

Jag tror det finns ett rädsla för att ta emot feedback tidigt och jag tror det beror på någon sorts naiv stolthet. Man vill träffa rätt från början, förstå allt och ta fram rätt design direkt för att känna sig duktig. Vi måste alla inse att det här inte funkar. Interaktionsdesign är alldeles för svårt för att vara ett enmansjobb.

Det finns nog också en övertro på att resultatet av en användarundersökning eller ett designförslag ska tas emot bättre om den presenteras i ett snyggt format. Men vill vi ha feedback tidigt är det bättre om det inte alls ser färdigt ut. Det är lättare att vara kritisk till något som ser enkelt ut att ändra på, som en snabbskiss på ett papper. En avancerad interaktiv prototyp kan till och med tolkas som det färdiga slutresultatet.

Vidare läsning

Tidig feedback, korta feedbackloopar och samarbete är kärnan i det superspännande område som kallas Lean UX eller Agil UX.

Lean UX: Getting Out of the Deliverables Business – om att sluta vara besatt av leverabler och jobba iterativt

Agile UX and the One Change That Changes Everything – om att börja jobba agilt genom korta feedbackloopar

Boken Rocket Surgery Made Easy – om enkla, snabba och billiga användningstester

Boken Subject to Change – om hur förankring och samarbete kan skapa långsiktig nytta

Boken The Lean Startup – om korta feedbackloopar i produktutveckling

Lärdomar från ett agilt UX-projekt

Jag avslutade nyligen ett webbprojekt där vi jobbade enligt projektmetodiken Scrum. Tidigare har jag berättat lite om hur vi arbetade. Den här gången kommer det handla om lärdomar jag tar med mig från detta projekt till nästa.

Designa för nästa sprint, inte längre

UX-nissen (jag) arbetade med interaktionsdesign för nästa sprints funktionalitet samtidigt som utvecklarna implementerade nuvarande sprints funktionalitet, vilket fungerade bra. Men ofta blir frestelsen att designa för senare sprintar för stor. Resultatet blev att det ofta fanns interaktionsdesign färdig för senare sprintar vilket blev problematiskt. Dels hade mycket av den designen inte behövt göras alls eftersom den senare prioriterades bort. Dels flyttades fokus från det viktigaste, nämligen nästa sprints design.

Anders Ramsay har skrivit om design på rätt nivå här

Kommunikation med utvecklare – User stories på rätt nivå

Utvecklare är olika. Vissa kräver väldigt detaljerade User stories och tycker ”GUI:t” ska specificeras av någon annan. Andra har inga problem med att göra grova estimat baserat på något luddig och är duktiga designers som gärna är med och påverkar.

I det här projektet lät jag mig påverkas lite för mycket av den första typen. Resultatet blev User stories som var väldigt detaljerade. Det ledde till att utvecklarna i vissa fall slutade reflektera över vad de implementerade och det finns ju alltid rum för feltolkningar i textuella specifikationer så i många fall blev det fel. Vi försökte lösa problemet genom att införa en princip. Innan man börjar implementera en User story ska man alltid ta en diskussion kring den med UX-nissen. Det gjorde saken bättre men jag tror man skulle vunnit på att hålla nere detaljerna och ta den detaljerade interaktionsdesignen i diskussion med utvecklaren. En User story ska ju trots allt inte vara något mer än en överenskommelse om ett framtida samtal.

Alltså: De svåra och övergripande delarna av interaktionsdesignen, t.ex. navigationsmönster eller auto-completion, förbereds. Detaljerna, t.ex. exakt hur en formulärvalidering ska ske, tas fram i samarbete mellan utvecklare och designer innan utvecklaren börjar implementera User storyn.

Anders Ramsay har skrivit om kommunikation i agila projekt här

Testa ofta

Tanken var att vi skulle göra ett användningstest varje sprint, och sprintarna var tre veckor långa. Testerna gjordes på föregående sprints resultat (implementerad funktionalitet) eller designskisser och skedde oftast i början av sprinten. Här fanns två problem. Dels var det svårt att få tag på testpersoner, dels var trögheten stor. Det tog ju tre veckor att utveckla en funktion, tre att testa och sedan tre för att implementera en åtgärd.

Man skulle kort sagt testat oftare och mer. Usabilla publicerade nyligen en artikel om testning i agila projekt där det pratas om att testa varje vecka. Man låter en dag i veckan vara test-dagen och gör testerna tillräckligt begränsade för att klaras av på en dag inklusive förberedelse, åtgärdsförslag och allt. Det låter inte helt dumt.

Bestäm en formell produktägare

I mitt projekt fanns ingen formell produktägare, vilket var ett problem. Jag var oftast den tillgängliga resursen som hade bäst koll på funktioner och prioriteringar. I praktiken var jag som UX-nisse produktägare men ibland när diskussioner uppstod kring designdetaljer tyckte utvecklarna inte att jag hade tillräckligt mandat.

Det bästa hade varit om beställaren alltid hade haft en respresentat tillgänglig och det funnits ett produktägarteam bestående av den personen och mig.

Förmedla visionen till teamet

Det är viktigt att hela teamet kan skriva under på att projektmetoden och projektets riktning är bra. I det här projektet var det inget större problem, de flesta utvecklarna var väldigt intresserade av användarna, efter varje användningstest bombarderades man med frågor om hur det gick och vad man kom fram till.

Vi satte upp bilder på Personas och på Wire frames i rummet vilket jag tror hjälpte. Men effektkartan som togs fram i förstudien hamnade lite i skymundan, jag tror man skulle kunnat koppla till den oftare för att ge en ännu tydligare bild av målgruppernas och det övergripande syftet med projektet.

Hugg i där det behövs

Oavsett om man är utvecklare, testare, projektledare eller UX-nisse är det bra att kunna ta arbetsuppgifter man inte normalt har när det behövs. Speciellt i ett agilt projekt är det en grym fördel. När man arbetar inkrementellt blir det naturligt att vissa sprintar är extra test-tunga, andra innehåller mycket front end-utveckling o.s.v. Jag tror speciellt vi som pysslar med design på olika sätt tjänar på att testa eller utveckla lite, det kan finnas fördomar om att vi är snobbiga och vägrar göra något annat än design.

Dessutom blir alla gladare när folk hjälps åt, bra stämning är viktigt!

Fler lästips

Integrating UX into agile development – UXMatters snillen spekulerar kring agil UX. Innehåller även en massa bra länkar.

Conference review: IA Summit 2011 – på IA Summit 2011 handlade mycket om agil UX – kolla t.ex. resultaten från workshopen där ett agile UX manifesto skulle tas fram!

Anders Ramsay – har skrivit en massa bra om agil UX

Ha en skön sommar!

Det bästa av två världar – användarcentrerad Scrum

Jag skrev för ett tag sedan lite om kombinationen användarcentrerad och agil utvecklingsmetodik. Nu har jag haft turen att få jobba i ett sådant projekt, tänkte skriva lite om fördelarna jag ser med denna kombination.

Projektet började med en tre veckors förstudie. Den bestod av:

  • Effektkartläggning – ett antal workshops med beställarna för att förstå deras syfte med projektet och hur de såg på sina målgrupper och deras behov. En effektkarta producerades.
  • Målgruppsanalys – målgruppsintervjuer med framtida användare ur olika målgrupper, som blev input till effektkartan.
  • Design – designprinciper, övergripande utkast till en interaktionsdesign utifrån effektkartan.
  • Teknisk analys – förberedelse för implementation, teknisk genomförbarhet.

Efter förstudien satte utvecklingen igång och projektet började följa den agila utvecklingsmetoden Scrum i tre veckors-sprintar. Utvecklarna kunde sätta igång direkt eftersom det fanns tillräckligt mycket design från förstudien. Under tiden fortsätter jag som interaktionsdesigner designa vad som ska finnas med i nästa sprint, i tight samarbete med beställarna. Jag jobbar samtidigt med att stödja utvecklarna och förklara hur jag tänkt.

Hittills har projektet fungerat riktigt bra och jag gillar det här arbetssättet skarpt:

Samarbete och kommunikation

Istället för att designen är helt klar innan utvecklingen börjar jobbas den fram efter hand. När man sitter i ett tvärfunktionellt team med både utvecklare och designers finns det möjlighet att samarbeta. Designern kan ta hjälp av utvecklarna för att avgöra hur svår en designlösning är att implementera. Utvecklarna kan ta hjälp av designern för att förstå hur denne tänkt. Bättre förståelse mellan designers och utvecklare.

Användningstester

Det kan ibland vara svårt att göra användningstester på en prototyp, speciellt om man utvecklar något komplext och dynamiskt. Enligt Scrum ska en fungerande version av produkten levereras i varje sprint. Jättebra, då kan vi göra tester på den fungerande produkten för att rätta till mindre designproblem som vi inte upptäckte i prototyptesterna. Och eftersom Scrum uppmuntrar föränderliga krav är det inga problem att implementera en korrigering i nästa sprint.

Kortare förstudie

Det är inte alltid lätt att sälja in en lång förstudie, beställare förstår inte alltid vikten av interaktionsdesign. Lägger man in stora delar av designtiden i utvecklingsfasen av projektet kan det bli lättare att sälja in och beställaren kan få en första fungerande version av produkten snabbare.

Det bästa av två världar

Agila och användarcentrerade utvecklingsmetoder har egentligen samma mål; att åstadkomma en bättre slutprodukt. Agila metoder genom förändring och bättre kommunikation mellan projektmedlemmar, UCD genom att fokusera på användare och behov.

Mer läsning

Clash of the Titans: Agile and UCD av Richard F Cecil på UXMatters

Bringing User Centered Design to the Agile Environment av Anthony Colfelt på boxesandarrows

dConstruct – Questions on Agile UCD av Leisa Reichelt på disambiguity

God Jul!