Insikter om användare är en färskvara – leverera tidigare!

När man ska utveckla en tjänst gör man ofta tidigt researcharbete för att förstå användarnas behov och kunna designa tjänsten rätt. Det är bra. Men vad som är mindre bra är att det ofta går för lång tid från research till leverans och att användarbehoven ”glöms bort”.

Det räcker inte med en powerpoint för att förstå

Visserligen är det så att användares behov förändras över tid. Så kan det ju vara, framför allt om man jobbar med nya och innovativa tjänster som förändras. I min jobbvärld som handlar om bank och ekonomi så händer det dock inte jättemycket, och jag har sett många användargrupper där behoven är mer eller mindre statiska. I kontexten ekonomi vill användarna ha kontroll över sin ekonomi, uppleva ekonomisk trygghet och få en bättre ekonomi. De här sakerna är rätt lätta för folk som jobbar med banktjänster att förstå.

Men det är svårare att se och förstå detaljerna och nyanserna. Vad betyder kontroll för en användare? Vad ger en känsla av kontroll och trygghet? Hur står sig våra tjänster idag – på vilket sätt ger de kontroll och vad är det som gör att användaren inte känner sig trygg?

När man jobbar med att förstå användare lär man sig jättemycket. Men det är svårt att lämna över sin kunskap till någon annan som inte varit med. Vi UX:are är ofta bra på att skapa bra modeller och visualiseringar av användares behov men för att riktigt riktigt förstå de här detaljerna och nyanserna måste man vara med och göra jobbet. Alltså vara med och intervjua, lyssna på användare, analysera och hitta mönster.

Minimera tiden från research till leverans

Vad som händer om man först gör ett insiktsarbete och sedan låter det gå en viss tid innan man levererar en tjänst (eftersom man kanske är upptagen med att göra utredningar, skriva krav eller övertyga företaget om att göra en investering) är att:

  • De som var med i researcharbetet börjar glömma bort de här detaljerna och nyanserna som är så viktiga för att kunna designa en riktigt bra tjänst
  • Folk byter jobb, tar tjänsteledigt eller blir befodrade (oj vad ålderdomligt det låter att bli befodrad men tja, det heter väl så)

De här superbra insikterna försvinner alltså sakta, sakta bort ju längre tid man låter gå. Och till slut är det enda som återstår en stackars powerpoint i en bortglömd mapp i något gemensamt filsystem. Det spelar ingen roll hur bra researchleverabler vi gör (även om bra modeller och visualiseringar är jättebra för de hjälper andra att förstå!). Detaljkunskapen kommer till slut försvinna om vi inte tar oss i kragen och sätter igång att designa och implementera tjänsten.

Om vi dessutom levererar tjänsten tidigt så får vi andra finfina effekter. Tjänsten börjar användas och skapar nytta för användare och affär. Och vi kan utvärdera hur folk använder den på riktigt, så vi kan förstå deras behov ännu bättre.

Så hur gör man?

Vattenfallsprocesser lever tråkigt nog kvar i UX- och affärsutvecklingsvärlden i rätt hög utsträckning. Ibland under täcknamn som ”sprint 0” eller ”vi jobbar agilt, men först måste vi göra research”. Vi börjar med ett researcharbete, sedan kan vi utveckla. Utvecklarna får inte vara med i researchfasen, för i den fasen finns det inget tekniskt jobb att göra, sägs det.

Det är klart att användarresearch behöver göras innan vissa saker kan utvecklas. Men det finns alltid tekniskt jobb som inte är avhängt på att vi gjort en massa research. Vi vet oftast från början vilken typ av tjänst som ska utvecklas och en webbsajt eller en app behöver alltid uppsättning av infrastruktur och tekniska miljöer innan man kan börja utveckla features.

Det bästa är att jobba tillsammans från början och att hela teamet är involverat i både research och utveckling. Och att research görs löpande, parallellt med utveckling och leverans.

Men om man gör tjänstedesign då?

Om man gör ett tjänstedesignjobb så vet man inte från början vilken typ av tjänst jobbet kommer mynna ut i. Ska det bli en app, en webbsida, eller en fysisk butik kanske? Eller allt på samma gång? Här blir det svårare att minimera tiden från research till leverans och att involvera teamet som i slutändan ska realisera tjänsten.

Jag tror ändå man i många lägen från början kan gissa vilka personer som kommer vara med och realisera. Om det finns en digital tjänst och den inte funkar bra så bör det inte behövas månader av research för att inse att den behöver förbättras. Om man ändå inte kan det så bör man en bit in i tjänstedesignjobbet börja ana vilken kanal förbättringarna kommer göras i och i det läget fasa i rätt folk.

Idag jobbar tjänstedesignbyråer ibland vattenfalligt. Fokus är att leverera insikter snarare än att leverera tjänster och skapa nytta för användare och affär. Vilket kan bero på att de inte har kompetens att leverera själva, men också på att kunderna är dåliga beställare. Därför tror jag på att bygga kompetens och jobba med service design in-house. Eller hitta en byrå som inte bara är duktig på tjänstedesign utan även intresserad av leverans.

Annonser

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

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.

Skillnaden mellan tjänstedesign och UX design

På UX Open i höstas lyssnade jag på en föreläsning om vad som skiljer sig mellan en tjänstedesigner och en UX Designer. Jag blev förvirrad. Så jag ska försöka mig på en egen förklaring.

I ett projekt jag gjorde som konsult var jag ensam UX designer (eller ja, titeln hette Interaktionsdesigner). Det var ett nyutvecklingsprojekt och eftersom jag är van vid sådant körde jag direkt igång med att definiera effektmål och målgrupper, göra kundintervjuer, ta fram scenarios, koncept och designprinciper. Efter ett tag insåg jag, utan att någon sa något, att man inte hade förväntat sig att jag skulle ta den rollen. Man förväntade sig att jag snarare skulle jobba med gränssnittsdetaljer som huruvida OK-knappen ska ligga till vänster eller höger.

Jag tror projektet verkligen uppskattade att jag tog en större roll. Projektets kunskap om användarna var nämligen alldeles för liten. Och att jag kunde definiera ett övergripande koncept istället för att grotta ner mig i knapp-positioner gjorde att vi kunde se tjänsten som en helhet från början vilket underlättade planering och förankring.

UX design kan ske på olika nivåer, allt från en nitty-gritty pixelnivå till en strategisk nivå där man tar hänsyn till affärsmål, användarbeteenden och drivkrafter. För mig är den strategiska nivån i UX design fundamental. Det är snudd på omöjligt att göra ett bra jobb utan att på djupet förstå affären och användarnas beteenden, drivkrafter, problem och kontext (oberoende av lösning och ”kanaler”).

De som kallar sig tjänstedesigners betonar det här strategiska jobbet och får det ibland att låta som något unikt för tjänstedesign. Men utgångspunkten för en UX designer som jobbar strategiskt och en tjänstedesigner är, så vitt jag förstår, den samma. Förstå affären och användaren, oavsett lösning (digital eller inte). Ta fram koncept och utvärdera med användare.

En intressant skillnad är ”paketeringen” av tjänstedesign:

  • Tjänstedesigners pratar om kunder, inte användare. Kund är ett mer bekant begrepp för de flesta, speciellt höga beslutsfattare som är intresserade av affärsnytta. Det är ju kunderna man tjänar pengar på. Kund inkluderar också inaktiva kunder, som inte ”använder”. Men begreppet kund är också begränsande eftersom det inte inkluderar interna användare som ju också kan bidra till affärsnytta genom användning.
  • Tjänstedesigners jobbar alltid strategisk. UX design är som sagt ett väldigt brett begrepp som inte alltid betyder att man jobbar strategiskt (även om jag tycker att det borde göra det). Så när UX designern ofta är generalist och ska kunna ”allt” från affär till pixlar är tjänstedesignern specialiserad på de strategiska delarna.
  • Tjänstedesign är över huvud taget mer specifikt. Man vet vad man får. Man vet till och med vilken typ av leverabler man kan förvänta sig från en tjänstedesigner (upplevelsekartor).

När det kommer till designkoncept finns en viktig skillnad. Tjänstedesigners kan designa för alla typer av interaktioner, både digitala tjänster och icke-digitala möten som en reception eller ett kölappssystem. UX designern jobbar oftast bara med digitala koncept.

Gränsen mellan det fysiska och digitala suddas ut allt mer. Fysiska produkter blir allt mer digitala och det behövs människor som förstår båda världarna. Betyder det att ”strategiska” UX designers borde bli tjänstedesigners? Jag vet inte. Men jag vet att det är viktigt att vi både förstår vad andra gör och vår egen jobbtitel uppfattas. Annars hamnar vi i kommunikationsproblem. Därför har jag beställt den här boken om tjänstedesign. Hoppas den är bra. Och hoppas att diskussionen dyker upp igen på nästa UX Open den 24 oktober.

Lästips

Breaking up with the User in User Experience Strategy på UXMatters – Om en snarlik begreppsdiskussion på engelska, customer experience och user experience.

Adaptive Paths gratis e-bok Guide to Experience Mapping

Tjänstedesignbloggen – Transformator Designs blogg