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.

Förstå varandra – bli effektivare

Nu i sommartider blir det lite peace love and understanding här, av typen som man kan lära sig om i managementböcker som heter saker som ”How to Become Successful in 4 Simple Steps”.

Vi börjar med ett citat av världens kanske mest citerade människa, Martin Luther King, Jr:

Peo­ple fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not com­mu­ni­cat­ed with each other.
Det är lätt att hamna i känslan av att någon i ens närhet är ignorant, dum eller ond. Känslan är ibland den reflexmässiga när någon tycker annorlunda, men förstås nästan alltid fel. Därför borde vi jobba mer på att förstå varandra och mindre på att bråka (peace!).

Visa känslor på en oljerigg

Jag lyssnade på en fin historia i podcasten Invisibilia (som är jättebra och handlar om hur människor fungerar). Den handlade om män som jobbade på en oljerigg. Det var en rätt farlig miljö och kulturen var klart macho. Man frågade inte frågor och visade inte känslor, jobbade på. När en arbetare dog i en olycka sörjde kollegorna i 15 minuter, jobbet fick inte stanna upp.

I ett försök att få upp effektiviteten anlitade man en ledarskapskonsult som använde rätt ovanliga metoder, med Shells mått mätt. Hennes mål var att få arbetarna att hantera sina rädslor och börja visa känslor. De fick berätta om sina liv för varandra och göra olika övningar i att visa sig sårbara och erkänna sina misstag och brister. Till exempel fick de i par svara på frågan ”Om du fick förändra en sak med mig – vad skulle det vara?”.

Det här blev en rätt omvälvande upplevelse för oljeriggsarbetarna. Det skapade en helt annat sätt att bete sig och samarbeta på arbetsplatsen. Ökad trygghet, mer kommunikation och känslor. Det gav också resultat. Mängden olyckor gick ner med 84 procent och produktiviteten ökade till rekordnivåer.

Vi är alla en färg (eller flera)

På mitt jobb gjorde vi en DISC-analys för ett tag sedan. Man svarar på en massa frågor och får en färg (röd, gul, grön eller blå) som visar ens jobbpersonlighet. Man fick också träna sig i att identifiera vilka färger andra är och lära sig lite om hur de tänker.

Även om jag kanske inte använder färgtänket så mycket har jag har blivit bättre på att tänka att folk kan ha andra perspektiv och andra mål. Det här är en skill som jag tror vi UX:are är rätt bra på generellt, eftersom vi jobbar med att förstå andra människor. Vi borde bara lära oss att använda den mer på kollegor och andra runt omkring oss.

Förstå hur korkade beslut tas

En grupp som väcker speciellt mycket irritation är de som tar ”korkade” beslut. På konferensen From Business to Buttons i våras pratade Simon Bennett om hur beslutsfattare tänker:

Hur kan vi vara mer som Buddha?

Jag kan rätt lite om buddhism men tänker att en Buddha aldrig blir irriterad på en medmänniska. För att bli mer som Buddha behöver vi förstå varandra genom att kommunicera på ett ärligt och öppet sätt. Berätta vad du är bra på, men erkänn också dina fel och brister. Då blir det blir lättare för andra att förstå ditt perspektiv när ni tycker olika.

Så här kommer det – How to Become Sucessful in 4 Simple Steps:

  1. Inför parterapi i dina agila team
  2. Maila alla kollegor på företaget och berätta varje gång du begår ett misstag
  3. Bjud en kollega på tårta och berätta om din livshistoria varje dag
  4. Gör en DISC-analys och klä dig helt i rött, gult, grönt eller blått

Om stegen känns svåra så kan du börja med att öva dig på att förstå andras perspektiv. Inför ett möte – vilka mål har deltagarna? Och när någon tycker annorlunda – varför tycker hen så?

Trygga grupper presterar bättre

När människor i en grupp vågar visa våra svagheter och brister, känner varandra och kommunicerar så blir vi mer trygga. Och det har visat sig att trygghet är en viktig faktor för att team ska prestera.

Google studerade 180 arbetsgrupper för att förstå vad som fick vissa team att prestera bättre än andra. Deras hypotes var att det handlade om kompetens och att få till den ultimata kombinationen av olika kompetenser. Men man hittade inget sådant samband. Förmågan att prestera hängde snarare ihop med mjuka faktorer, alltså hur teamet samarbetade. Och den allra viktigaste faktorn för att teamet skulle prestera var känslan av trygghet. Alltså om medlemmarna i teamet kunde riskera att ha fel utan att känna sig bortgjorda.

Jag tycker det här visar att vi borde satsa mer på gruppdynamik när vi skapar och jobbar i team. Speciellt om teamet ska jobba under en längre tid och läget är pressat, teamet ”måste” prestera. Det är förresten i de tillfällena vi ofta struntar i saker som kick-offer, fikor och after work. Det finns inte tid.

Innovation genom goda idéer från olika håll

Innovation. Känn på det. För min egen del mår jag lite illa när jag hör ordet. Lite på samma sätt som jag kräks lite i munnen när jag hör ordet brainstorming. Det låter som att man bara ska samlas ett gäng sköna personer och komma på ett gäng sköna idéer. Gärna utan mål, utan att veta vad användarna behöver eller vad som är möjligt att realisera.

Samtidigt är förstås nya goda idéer (som uppfyller verksamhetens mål och dessutom är realiserbara) bra och inte alltid lätta att komma på. Det är lätt att bli miljöskadad. Om man jobbar med att anlägga tulpanrabatter hela dagarna och dessutom har en lång och gedigen utbildning i tulpaner är det svårt att inse när något annat skulle passa bättre. Som pelargoner. Eller kanske till och med en fräsig buske.

Vissa har patent på nya idéer

Som en smart kollega sa när vi snackade innovation igår; det svåra är inte att komma på nya idéer utan att få ta dem vidare. I de allra flesta företag gör man skillnad på de som får komma på idéer (affärsfolk, produktägare, designers m.fl.) och de som realiserar idéer (utvecklare, arkitekter, testare m.fl.). Vissa företag har till och med delat upp sig i grupper som ”creatives” (usch!) och ”tech”.

Det här är förstås dåligt eftersom nya goda idéer kan komma från olika håll. Från en utvecklare som har koll på användarbehoven, från någon på supporten eller t.o.m. från användarna själva.

Innovationstävlingar och hackathons

I veckan var jag på ett frukostseminarie på KnowIt där Björn Lindqvist (accedo.tv, tidigare Avanza) snackade om innovation.   Han organiserade innovationstävlingar för att få fram nya idéer. Alla på företaget fick möjlighet att vara med. Det enda som krävdes var en god idé och ett team som kunde realisera idén hela vägen till produktionsfärdig kod på en vecka.

De som ville vara med fick samla ihop ett team och skicka in sin idé till tävlingen. Sedan röstade företaget på idéerna. Teamen som vann fick en veckas ostörd arbetstid för att realisera idén som pris.

Tävlingen blev en succé. På Avanza skapade man till exempel ett nytt sätt att visualisera innehav, och på accedo.tv ett nytt sätt att generera leads från sin webb. De flesta idéerna från tävlingarna sattes faktiskt i produktion, så bra var de.

Tvärfunktionella team (på riktigt)

Det här med tävlingar och hackathons låter ju kul och bra men uppdelningen mellan idéskapare och implementerare finns kvar. Hur ofta orkar man köra såna här events? Det blir rätt mycket administration eller ”waste”. Och som en annan smart kollega sa, man kan inte styra över när goda idéer kommer.

Bästa lösningen är förstås att ha team som inte jobbar med en idé som någon annan utanför teamet kommer på. Team där inte bara utveckling utan även affär och design ingår, där teamets uppdrag är att uppfylla ett verksamhetsmål eller tillgodose ett behov hos en målgrupp. Resten är upp till teamet och alla är med i alla faser, inklusive idégenerering och design.

Är det här innovation?

Men har det här något med innovation att göra egentligen? Ja, typ. Om man involverar fler personer i att komma på idéer, som dessutom samarbetar tvärfunktionellt, kommer det dyka upp fler olika (och goda) idéer. Det löser inte tulpankillens grundproblem. Även om han början samarbeta med pelargontjejen kommer det inte bli några buskar. Men det är ett bra steg på vägen.

UX handlar (också) om affärsnytta

Ibland så stöter man på tanken om att bara vi gör tjänster som användarna behöver och gillar så kommer det gynna företaget. Do good stuff and good stuff will happen. Det låter ju fint. Vi som jobbar med att få företagen att tänka mer på användarna ibland behöver kommunicera så för att få dem att förstå att tjänsterna framför allt måste vara riktigt bra och nyttiga för användarna. Det inte spelar någon roll hur många features din tjänst har eller hur väl du marknadsför den mot rätt segment om den inte möter användarnas behov.

Men samtidigt kan vi inte bara ta hänsyn till vad användarna behöver när vi designar tjänster. Vi jobbar inte bara med att göra världen till en bättre plats där fler tjänster är anpassade till människors behov och effektiva att använda. Vi jobbar också med att hjälpa företag som gör investeringar för att tjäna pengar eller spara pengar. Kanske för att nå ett nytt marknadssegment eller komma ett steg närmare sin vision, eller ta marknadsandelar från en viss konkurrent. De här sakerna måste vi också förstå för att företaget ska få ut maximal nytta av sin investering. Om vi inte gör det kommer vi antagligen lösa fel problem och bygga fel lösning, oavsett hur mycket vi vet om användarnas behov.

Hjälpa (och ta hjälp av) affären

Att balansera de här två perspektiven, vad kunderna behöver och vad affären vill uppnå, är inte alltid lätt.

De som bestämmer över affärsmålen tänker inte alltid långsiktigt, och de förstår inte alltid styrkan i att ha en långsiktigt nöjd och lojal användare. Per Axboms bloggpost Det osynliga problemet med sagolika användarupplevelser (läs den!) handlar om att det inte får bli för enkelt för användaren. Vi måste ibland låta användaren stanna upp och reflektera över sina val för att inte senare bli besviken. Om man lägger fokus på att skapa kortsiktig nytta, som att optimera köpprocessen genom konverteringsoptimering, riskerar man att få missnöjda användare som inte kommer tillbaka. Det perspektivet har inte alltid affären.

Det kan också vara så att det inte finns några tydliga tankar om vilken nytta man vill uppnå, att en satsning görs utifrån ett teknikperspektiv eller utifrån någon chefs idé om vad som vore bra.

I båda fallen tror jag vi som designar tjänster måste hjälpa och samverka med affärssidan. Vi kan hjälpa dels genom att lyfta användarperspektivet, lyfta värdet av bra tjänster. Dels genom att hjälpa till att kartlägga affärsmål och affärsstrategier, i de fall tydliga mål saknas. Det minsta vi kan göra är att alltid kräva (och hjälpa att ta fram) effektmål för de projekt vi jobbar med. Det är inte svårt. Man kommer rätt långt med den magiska lilla frågan Varför?.

Tips

Jag har skrivit om:

Andra om effektsyrning:

Bygga en nyhetsaggregator-sajt

Under semestern har jag jobbat med ett litet hobbyprojekt, webbplatsen justidag.nu som aggregerar nyheter och bloggar om Hammarby Fotboll. Ett alldeles lagom litet projekt för mig som inte har kodat på ett tag och inte vill tappa det helt.

Sajten är byggd i PHP och jag har använt följande:

  • one.com – Billigt webbhotell.
  • Bootstrap – Front end-ramverk som hanterar layout, responsivitet och styling.
  • SimplePie – RSS-parser i PHP som parsar och cachear 16 RSS-feeds. Jag skrev lite kod för att filtrera fram intressanta nyheter via nyckelord och extrahera bilder från feedsen.
  • EasyCron – Det tar rätt lång tid (typ 15s) för SimplePie att ladda om alla feeds så man vill inte göra det varje gång sidan laddas. Vissa webbhotell erbjuder schemaläggning av script men det gör inte one.com. Så jag använder den här tjänsten som var 10:e minut anropar min sajt med en parameter som får SimplePie att ladda om alla feeds och cachea.
  • Twitter widgets – Twitter-feedsen är färdiga widgets från Twitter.
  • Svensk Fotboll widget – Tabellen är också en färdig widget.
  • Google Analytics – För att hålla koll på trafiken.

Boktips: Content Strategy for Mobile

Böcker och artiklar om mobil webb handlar ofta om responsive design eller huruvida man ska ha en native app. Viktiga frågor, men det är rätt skönt att läsa Content Strategy for Mobile som inte alls svarar på sådana frågor. Den handlar om kärnan i många webbplatser, appar och intranät, nämligen innehållet.

Content Strategy for Mobile

Många CMS ser ut som något i stil med Microsoft Word (en WYSIWYG-editor, alltså). Men webben är något helt annat än ett papper eller en PDF. Webbinnehåll behöver kunna publiceras till flera olika plattformar, allt från smarta klockor till fullskaliga webbplatser. Och olika plattformar har olika möjligheter och begränsningar. Vissa är bra på att förmedla ljud, andra är bättre på text eller video.

En modern webb kräver en typ av CMS som låter innehållet vara separerat från visningen av innehåll, vilket inte är fallet med många CMS som WordPress eller EPiServer. Det innebär att innehållet kan hämtas från din Apple Watch eller från en webbläsare i din laptop. Men visningen av innehåll sköts separat, så varje plattform kan visa innehåll på det sätt som passar bäst. I en Apple Watch med hjälp av en native app, i en webbläsare med hjälp av HTML och CSS.

Content Strategy for Mobile handlar dels om varför det är viktigt att bygga sitt innehåll på ett anpassningsbart och återanvändningsbart sätt. Men den handlar också om hur man bygger upp användbart innehåll som är strukturerat för att kunna levereras till olika plattformar.

Konkret och bra för den som inte bara vill bygga bra tjänster utan också skapa innehåll på ett effektivt och långsiktigt sätt.

Tips

Författaren Karen McGranes brandtal på From Business to Buttons.

Bli bättre på presentationer

Jag tycker det är läskigt att hålla presentationer, det är jag inte ensam om. Men det finns också få saker i jobbet som kan få en att känna sig kompetent och viktig som när man gör en bra presentation. Och så älskar jag hantverket, att bygga presentationer som får folk att förstå. Tyvärr har alldeles för många bara blivit liggande eftersom jag inte kommit över tröskeln att presentera.

I onsdags var jag på Mike Monteiros workshop Presenting Design Like Your Life Depends On It (Because It Will), i samband med From Business to Buttons. Vi fick öva på att presentera för varandra och lärde oss massor. Här kommer de viktigaste sakerna jag lärde mig:

Var ordentligt förberedd

Du som presenterar måste ha riktigt bra koll på materialet. Det kommer alltid hända oväntade saker under en presentation. Oväntade frågor kommer komma, oväntade personer dyker upp, någon vill att du hoppar över delar av materialet eller förklarar något på djupet. Ha inget manus, för då tvingas du kunna materialet riktigt bra och du får lättare att hantera det oväntade. Utan manus blir det också lättare att presentera på ett engagerande sätt.

Var öppen för att oväntade frågor och diskussioner kommer upp. Men försök se till att rätt frågor dyker upp genom att inleda presentationen med att berätta varför alla är här, vilken roll folk har och vilken typ av frågor du vill få.

Känn till folks drivkrafter

Alla som deltar har ett mål, ibland kan målet vara att bara komma därifrån. Ett sätt att både göra bättre presentationer och hantera oväntade situationer (som att någon håller en 20-minuters monolog om något du tycker är irrelevant) är att förstå de olika agendor folk har. Som presentatör eller workshopledare är det lätt att skaffa sig en drömbild av vilka diskussioner som kommer komma upp. Den drömbilden bygger på din agenda, ditt perspektiv, designperspektivet. Men om du presenterar för icke-designers kommer åhörarna naturligtvis ha andra perspektiv och andra agendor.

Använd användarcentrerade designmetoder. Analysera målgruppen, deras drivkrafter och designa presentationen för dem, inte för dig själv. Ibland krävs det att du intervjuar deltagarna inför en presentation.

Workshopen i onsdags fokuserade på att presentera design för beslutsfattare/kunder. I den situationen vill de som lyssnar känna sig trygga i att du har gjort ett bra jobb, att allt är genomtänkt och att din design kommer göra företaget framgångsrikt. Det handlar inte om att gå igenom varje liten designdetalj del för del. Det handlar om att sälja – både designen och dig själv som experten som har gjort ett fantastiskt jobb.

Ta kontroll över rummet

Kroppsspråk och röstläge spelar roll. Stå alltid upp när du presenterar. Visa att du är i fokus genom att gestikulera och tala tydligt. Men du behöver inte försöka vara någon annan. Var dig själv, men dig själv när du är som mest engagerad. Om du visar att du brinner för det du pratar om så smittar det av sig.

Det är svårt att bryta sådana här mönster. Jag tror det handlar mycket om att öva, och få feedback.

Be om feedback

Den viktigaste saken i en process är att den förbättras kontinuerligt. Det gäller också ditt sätt att presentera. Tyvärr är det sällan man får någon annan typ av feedback än en klapp på axeln. Riktig feedback kommer inte av sig självt, den måste du be om.

Sammanfattning

För att sammanfatta ska jag bli bättre på att:

  • Vara förberedd och skippa manus
  • Tänka på åhörarna och deras drivkrafter inför en presentation
  • Vara medveten om hur jag presenterar och öva oftare
  • Be om feedback

Tips

Mike Monteiros 13 Ways Designers Screw Up Client Presentations som artikel på medium, som video från From Business to Buttons

Mikes podcast Let’s Make Mistakes