Fråga vad användarna tycker – det är okej

Det här är UX-världens kanske mest uttjatade citat (som antagligen inte ens stämmer):

If I had asked people what they wanted, they would have said faster horses.

– Henry Ford

Citatet används ofta för att poängtera att det inte handlar om vad användarna tycker. Man måste förstå användarnas behov för att kunna designa en bra lösning. För användarna är oftast inte designers, de har inte koll på vad som är möjligt att göra och utgår bara från sig själva. De kan inte designa lösningarna själva. Och man kan inte bara utgå från synpunkter och idéer från användare när man väljer lösning. Bra så.

Men det finns också fördelar med att fråga vad användarna tycker och be dem komma med egna idéer:

  • Alla användare är, som bekant, olika. Många är fantasirika och kreativa människor. Många har en grymt bra analysförmåga.
  • Användarna kan ha erfarenheter från webbplatser och system som jag som designer aldrig sett. Om det handlar om ett expertsystem som folk använder ofta så har vissa användare antagligen redan funderat mycket på hur det skulle kunna funka bättre.
  • I en intervju kan frågan Hur skulle du önska att det här skulle funka? dels vara en isbrytare, som får folk att prata. Dels kan den följas upp med frågan Varför skulle du vilja att det funkade så?.

I co-creation tar man det här ett steg längre. Det handlar om att engagera användarna i designprocessen. Istället för att först förstå målgrupper och behov, sedan göra ut en lösning och testa så låter man användarna vara med och designa lösningen. Man kombinerar alltså ”traditionell” research (djupintervju/observation) och konceptdesign till en aktivitet med syftet att förstå både användarnas behov och hur de ser på en lösning.

Sådana här workshops kräver förstås en del planering och tankearbete. Men det kan nog vara ett effektivt sätt att designa på, om det görs rätt. Jag tror ett första steg kan vara att ibland fråga vad folk tycker, och se vart det leder.

Lästips

Co-Creation: Designing With the User, For the User på UX Booth
The UX of Co-Design: Experience Principles for Successful Client Workshops på Adaptive Path
Myth #21: People can tell you what they want på UX Myths

Annonser

Rapport från UX Open 2014

För några år sedan fanns det inga UX-konferenser i Stockholm alls. Nu finns det flera, vilket är helt fantastiskt.

UX Open, som hölls för tredje året i fredags, bygger mycket på deltagarmedverkan. Dels hålls korta blixttal på 10 min, dels är man med i gruppdiskussioner där deltagarna bestämmer ämne. I år var det också paneldebatter där alla fick delta. Väldans bra upplägg, för det kändes som att rummet var sprängfyllt av kompetens. Och man blir också mer på tårna av att inte bara sitta och lyssna på föreläsningar.

Daniel Anundi inledde med att prata om Service Recovery, den del av tjänstedesign som handlar om att hantera när någon går fel i tjänsteleveransen. Insatsen för att få en ny kund motsvarar insatsen för att behålla fem befintliga. Ändå glömmer man ofta bort att designa för de felsituationer som kan uppstå. Daniels exempel var ett hotell som förstörde en klänning i tvätten och inte bara kompenserade genom att betala för köpa nya kläder. De anlitade också en personal shopper och gav paret en oförglömlig upplevelse under ett restaurantbesök.

Man kan fundera på om den här hotellkedjan tjänar på att kompensera kunder på ett så här ambitiöst sätt. Enligt en studie i den här boken ska företagen sluta försöka överträffa folks förväntningar eftersom överträffade förväntningar inte leder till ökad lojalitet. Sant eller ej, hotellkedjan tjänade säkerligen på just den här kompensationen eftersom historien fått så stor spridning.

Sigrun Tallungs jobbade med användbarhet i polissystemet Pust. Hela Pust-Siebel-haveriet är ett bra exempel på vad som händer om man låter beslut kring teknisk plattform styra i alldeles för hög grad. Och om man låter fel personer besluta om teknisk plattform. Målet med föregångaren Pust-Java var att det skulle vara lätt att använda. Målet med Pust-Siebel var billig förvaltning. Men billigt blev det inte. Man räknar med att Pust-Siebel kostat ca 126 miljoner innan det lades ner.

Några kortisar:

  • Det pratades mycket om användarundersökningar av olika slag. Alla verkar tycka det är en självklar del av UX-arbetet. Bra!
  • Bästa konkreta tipset var att låta stakeholders spela användare och intervjua varandra inför användarintervjuer. På så sätt upptäcker de vilka (felaktiga) antaganden de gör om användarna. Genialt!
  • Kundundersökningar, målbilder och designprinciper. För att funka måste de repeteras, revideras och jobbas vidare med. Häng t.ex. upp på väggar där folk befinner sig eller repetera i början av varje möte.
  • Vi UX:are borde lägga mer tid på att kommunicera vårt jobb – och mindre på att leverera.

Riktigt bra konferens, tack till arrangörerna! Jag ser redan fram emot nästa år. Eller som Maryam skrev:

Jens Wedin tog en massa fantastiska foton. Kolla in.

Saker jag lärde mig på kurs i effektkartläggning

Modellen effektkartan är lika enkel som briljant tycker jag. Den har hjälpt mig med problemlösning och med att alltid tänka både affär och användare i allt jag gör. Jag fick upp ögonen för effektkartläggning för första gången runt 2009 och i vintras gick jag inUse kurs i effektkartläggning.

Jag tänkte gå igenom några bra saker jag lärde mig under kursen som inte var självklara för mig. Jag kommer inte gå igenom metoden i grunden här, jag har ju redan skrivit en massa om effektstyrning.

Kombinera intervjuer och workshops för att hitta effektmål

UX handlar inte bara om vad användarna vill och behöver. Lika viktigt, eller viktigare är vilken affärsnytta en satsning ska leda till. Jag börjar alltid med att hitta affärssidan av myntet, det som kallas effektmål. Vilken nytta ska satsningen leda till? Om man tänker sig att vi sitter här om ett år när projektet har levererat, och det är superlyckat. Vilka förändringar har då skett?

När jag tagit fram effektmål i mina projekt har jag kört workshops med intressenter som beslutsfattare, beställare och andra. Men workshops kanske inte är det bästa sättet. Precis som olika användare har olika behov kan olika intressenter vara ute efter olika effekter. Dessutom finns det problem med workshops som arbetsform. Folk blir lätt påverkade av varandra och det kan vara svårt att styra gruppen åt rätt håll.

Det rekommenderades under kursen att istället köra djupintervjuer med intressenter för att hitta förväntade effekter. När man har gjort det kan man samla intressenterna i en workshop för att gå igenom, sammanfatta och prioritera. Absolut något jag kommer anamma, framför allt när det finns intressenter med olika agendor.

Definiera omfattningen först

Innan man börjar jobba med att definiera effektmål är det bra att definiera satsningens omfattning. På kursen pratades det om att omfattningen kan vara en pryl (till exempel ”sl.se”) eller ett verksamhetsområde (till exempel ”SL:s kundtjänst”).

Som UX-konsult är omfattningen ofta tydlig. Man blir anlitad för att lösa en specifik uppgift, som att ta fram ett intranät. Men vad händer i bredare och friare sammanhang, där man får tänka in alla kanaler och verksamhetsområden? Det är ju där man kan skapa riktigt stora nyttor, för affär och användare. När man kan ignorera organisationens stuprör och göra tjänstedesign. Här blir det klurigare att definiera en omfattning. I sådana fall tänker jag att det blir effektmålet i sig som är omfattningen, till exempel ”En effektivare SL-reseupplevelse”.

Effekterna man vill åstadkomma ska vara starkt knutna till omfattningen. De ska vara effekter som prylen eller verksamhetsområdet kan ta ansvar för. Exempelvis kanske sl.se inte kan ta ansvar för att kundnöjdheten i stort ökar, men den kan ta ansvar för att fler är nöjda med webbplatsen.

Använda användarbeteenden

I effektkartan är en målgrupp är en samling drivkrafter. Men begreppet målgrupp är inte jättebra. Dels används målgrupp på andra sätt i andra sammanhang, ibland av marknadsavdelningen för att beskriva en grupp kunder där man ofta använder demografiska uppdelningar. Dels handlar det inte alltid om att beskriva en grupp människor utan oftare om att beskriva ett beteende som en människa kan ha, och en person kan röra sig mellan olika beteenden.

På sl.se skulle man till exempel kunna tänka sig beteendet Snabbresaren, den som snabbt vill ta sig till punkt B. Ett annat beteende skulle kunna vara Reseplaneraren som i god tid innan resan vill undersöka hur lång tid resan tar, vilka byten man ska göra o.s.v. Vilket av dessa beteenden en person har beror ofta på situation och man kan röra sig från ett beteende till ett annat.

Det här var i sig inget nytt. Tanken med att sätta namn på en samling beteenden är samma i Coopers Personas. Men jag tror man kan tjäna på att använda begreppet användarbeteenden snarare än målgrupper. Jag tror också det kan underlätta att fråga efter olika situationer som användare kan befinna sig i för att hitta olika användarbeteenden.

Beskriva lösningar som egenskaper

När man vet tillräckligt mycket om användarbeteenden och användningsmål så är det dags att beskriva lösningar. Lösningar kan beskrivas i flera nivåer och på den översta nivån bör lösningen beskrivas så generellt som möjligt och som en egenskap snarare än en funktion.

Om man till exempel har ett användningsmål ”Vill undvika trafikstopp på resan” i SL-exemplet så skulle lösningen kunna vara ”Hjälper användaren att enkelt få reda på när något hänt i trafiken”. Konkreta lösningar som ”Pushnotiser i mobilen” kommer in på en längre nivå. Man kan ställa frågan ”Hur ska tjänsten vara?” istället för ”Vad ska tjänsten innehålla?” för att hitta egenskaper.

En fördel med att beskriva egenskaper först är förstås att man kan undvika att fokusera på specifika lösningar tidigt.

En annan fördel är att egenskaper kan göras mätbara. Vi låta kunderna använda tjänsten och fråga ”Upplever du att du får reda på när något händer i trafiken?” (ledande fråga ja, men ni fattar) för att ta reda på om egenskapen finns. Vi kan bestämma oss för att när 8 av 10 kunder svarar ja på frågan så har vi lyckats med egenskapen. På så sätt vet vi när vi jobbat tillräckligt mycket med en del av tjänsten för att kunna bocka av den och gå vidare till att realisera nästa egenskap. Rätt coolt, känns som att detta sätt att mäta och förbättra egenskaper passar väldigt väl in i Lean UX-tänket.

Kursen i effektkartläggning

Facebook-gruppen Business Impact Mapping & Management

En kort beskrivning av effektstyrning på webbstrateg.nu

Föreställningar om användarundersökningar

I torsdags var jag på World Usability Day-seminarier på KTH i Stockholm, som i år hade temat Inspiration. Det var superintressant och bra, hög lägsta nivå. En av de mest intressanta föreläsningarna var den inledande som hölls av Jared Cole från Adaptive Path. Han sågade temat och ville prata om insikter istället för inspiration. Sunt. Andra föreläsare var inne på samma spår.

Vi som jobbar med användbarhet inser att insikter om användarna som baseras på undersökningar (intervjuer, observationer, enkäter, o.s.v.) är viktiga. De utgör ju själva fundamentet i vårt arbete och när jag förklarar hur jag arbetar för en kund börjar det ofta med något i stil med ”Jag undersöker vad era användare behöver för att …”. Men många företag lägger alldeles för lite krut eller inget krut alls på användarundersökningar. Varför är det så?

Det finns ett antal vanliga föreställningar om användarundersökningar som vi måste vara beredda på och kunna bemöta:

Användarna förstår inte vad de behöver, så det ger inget att fråga dem

Det är sant att användarna inte förstår vad de behöver. Det finns ett gammalt citat av Henry Ford:

If I’d asked customers what they wanted, they would have said ”a faster horse”.

Användarna vi pratar med är oftast inte IT- eller designexperter och har svårt att föreställa sig vad tekniken kan åstadkomma. Men det är inte värdelöst att prata med dem. Fråga varför är nyckeln. När användaren vill ha en snabbare häst frågar vi Varför? och förhoppningsvis får vi ett svar i stil med:

– För jag vill kunna ta mig från plats A till plats B snabbt

– Varför vill du det?

– För jag har ont om tid och mår bättre om jag slipper stressa

Vi strävar hela tiden efter att ta reda på vad personen behöver, inte vad personen vill ha. Istället för att låta användarna komma på vad vi ska skapa samlar vi in behov och använder vårt kunnande inom design och teknik för att skapa något som möter behoven. När vi tror att vi har en design som tillfredsställer våra användares behov skapar vi en prototyp som vi testar på användarna för att undersöka om vi hamnat rätt.

Alla användare tycker olika, så det är omöjligt att komma fram till något vettigt genom att fråga dem

Det är sant att användarna kommer tycka olika men frågar vi varför de tycker som de gör hittar vi oftast samma grundläggande behov. Vissa kanske vill ha en snabbare häst, andra en snabbare kamel men alla behöver kunna ta sig snabbt från en plats till en annan för att slippa stressa och få mer tid.

Vår uppgift här blir att designa ett transportmedel eller annan tidseffektiviserande produkt som tilltalar både de som gillar häst och de som gillar kamel.

Användarundersökningar tar för lång tid/kostar för mycket

När man pratar om användarundersökningar eller ännu värre etnografiska metoder tänker många kunder på något som tar lång tid och är dyrt. Så kan det vara, vill vi verkligen vara säkra på att vi hittat rätt behov måste vi göra stora undersökningar. Men en liten undersökning får mycket större effekt än ingen alls. De flesta användare ur en målgrupp har ju, som sagt, ungefär samma behov och mål.

Djupintervjuer är en typ av undersökning som ger snabba och goda resultat, om intervjuaren är duktig förstås. En djupintervju tar ungefär en timme, plus några timmar för sammanställning och analys. Enligt min erfarenhet kommer man rätt långt med tre intervjuer per målgrupp. En så kort undersökning går ofta att sälja in även om det förstås är bättre med en längre studie.

Är det fortfarande svårt att sälja in användarundersökningar kan vi göra en djupintervju där beställaren (den vi vill övertyga) får vara med som åskådare. Det brukar göra susen.

Tips för målgruppsintervjuer

Den senaste tiden har jag gjort en hel del målgruppsintervjuer. Här kommer några note-to-self för framtida intervjuer.

Skriv unikt intervjuunderlag för varje ny intervju

Intervjuunderlag behövs, tänkte jag. För att effektivisera skrev jag ett underlag som skulle gälla för alla intervjupersoner. Det innehöll specialfrågor för olika målgrupper.

Det här funkade bra under den första intervjun men efter att ha använt samma underlag med några småförändringar flera gånger insåg jag att frågorna måste anpassas mer. Man lär sig mycket under processen så det måste finnas tid att skriva nytt underlag mellan två intervjuer. Kasta bort det gamla underlaget, skriv helt nytt. En massa nya delar man inte tänkt på tidigare kommer upp.

Anteckna på flera papper samtidigt

Under intervjun vill man föra anteckningar dels om vad personen säger och dels vill man anteckna saker som dyker upp i huvudet men som inte direkt passar att fråga direkt då det skulle förstöra det naturliga samtalet. Anteckna sådana frågor på ett separat papper så faller de inte bort lika lätt.

Gå igenom anteckningarna direkt

Vi var alltid två som intervjuade och det gav mycket att gå igenom intervjun, via anteckningarna, direkt efteråt. Man inser att man inte har samma bild av allt intervjupersonen sade och kommer in på intressanta diskussioner och tankar.