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

Varför man ska ha ett in-house UX team

För någon månad sedan gick Adaptive Path ut med att de köpts upp av storbanken Capital One. Det här kan vara en del av en trend i USA och jag anar en trend även i Sverige. Företagen skaffar egna UX-team i högre grad, när man tidigare oftare förlitade sig helt på konsulter och byråer utifrån. Själv gick jag från konsult till in-house för något år sedan.

Det finns klart bra saker med att anlita konsulter och byråer. Man kan ta in en expert på ett specifikt område. Man slipper en jobbig anställningsprocess och kan snabbt sätta ihop ett ”dream team” med rätt kompetens utifrån vad som ska göras i ett projekt.

Så varför ska man som företag ha ett eget UX team?

Alltid jobba användarcentrerat, överallt

En UX designer som jobbar i flera år på samma ställe kommer lära sig att navigera i organisationen, ha stenkoll på alla satsningar som görs och få en god känsla för när något inte stämmer. Men framför allt kan man bygga upp ett arbetssätt som garanterar att allt som utvecklas på företaget tas fram enligt en användarcentrerad metod. Annars riskerar man att vissa satsningar görs utan att man alls involverar användare eller har UX kompetens. Det är trots allt rätt jobbigt att ta in konsulter och lätt att ”glömma bort” området UX där kompetensen är lite luddig och svårare att förstå än t.ex. projektledare eller testare.

Levandegöra insikter, principer och strategier

Kontinuiteten blir extra viktig när man jobbar övergripande eller strategiskt. Under min tid som konsult har jag sett en del styrdokument med fina namn som ”webbstrategi”, ”målbild” eller ”personas” som bara ligger och skräpar i ett hörn. Människors beteenden, förväntningar och problemområden förändras hela tiden. Så efter ett tag blir styrdokumenten inaktuella och glöms bort, oavsett hur välförankrade de var en gång i tiden. UX teamet kan se till att kunskapen om användarna alltid hålls aktuell och att styrande principer faktiskt används när nya tjänster tas fram. Oavsett om det är en konsult eller en anställd som gör jobbet.

Samma sak gäller interaktionsprinciper och UI guidelines. Om man jobbar med komplexa tjänster kan man spara mycket tid på att inte bara ta fram principer och guidelines inom ett specifikt projekt utan låta dem leva kvar när tjänsten vidareutvecklas i framtiden. Men de måste förstås hållas aktuella och jobbas med, annars dör dem snabbt.

Långsiktig förändring

We believe in delivery, not deliverables. Some people practice user-scented design, not user-centred design. They churn out documents – sitemaps, wireframes, specifications – but they’re not interested in what happens next. UX is a mindset, not a process – it lasts all the way until the site is live, and after.

Från boken Undercover User Experience Design.

Som konsult vill och ska man leverera. Och visst, det finns jättebra och ansvarsfulla konsulter som också vill förändra organisationer och leverera långsiktig nytta. Men som del av ett in-house UX team blir det extra viktigt att bygga något långsiktigt. Det kan som sagt gälla arbetssätt och strategier, men också organisationens förståelse för användarperspektivet. In-house UX teamet kommer vara mer intresserade av det långsiktiga eftersom de kommer påverkas på längre sikt. De har också, förstås, bättre möjligheter att jobba långsiktigt eftersom de jobbar kvar under en längre tid.

Adaptive Path-gängets bok Subject to Change handlar om långsiktig organisationsförändring – att bygga en användarcentrerad designkultur. Deras tanke om långsiktig nytta och vilja att ta UX design vidare gick till slut så långt att de blev uppköpta av Capital One. Så här skrev Jesse James Garrett i pressmeddelandet:

In many ways, this is exactly the kind of problem Adaptive Path was created to solve: helping a company with the resources, but more importantly the will, to reimagine its strategies, processes, and design solutions to create better experiences for millions of people. It’s a level of impact we’ve never had before, and we’re excited to be here at this moment.

Så om du är ett företag som vill fokusera på användarens behov och göra långsiktig nytta – skaffa ett eget UX team! (och ge teamet utrymme att göra ett bra jobb, men det är en annan historia)

Lästips

Soldiers & Hessians, Ronin & Ninja – jämförelse av att ha eget team vs. konsulter,  på boxesandarrows

The 3 Qs for Great Experience Design – om vad som utmärker framgångsrika UX team, på UIE

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

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

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.