Effektkarta och User story map – två modeller för prioritering

Jag älskar modeller. En bra och tydlig modell kan göra kommunikationen i ett projekt så mycket lättare.

Effektkartan är en modell jag jobbat mycket med. Den har hjälpt mig (och andra) att kommunicera och nå delad förståelse. Den har också hjälpt mig i prioritering av lösningar. En annan modell som jag lärt mig på allvar på senare tid (genom att läsa den briljanta boken User Story Mapping av Jeff Patton) är User story map. En Story map kan också underlätta delad förståelse och prioritering. Men på lite andra sätt.

Delad förståelse

Hur håller vi reda på vad som ska utvecklas och ser samtidigt till att alla i teamet vet vad som ska göras? Att mommunicera via många och långa dokument fungerar inte, det vet vi. Teammedlemmarna måste prata med varandra. Men om tjänsten är komplex, vilket den ofta är, behövs det någon form av dokument att kommunicera kring. User stories är ett vanligt sätt, men en User story i en vanlig backlog har ett problem. Den saknar kontext. Hur passar den här storyn in i helheten? Alltså, vilka andra stories hänger den ihop med, och vilka användarbehov löser den? Effektkartor och Story maps är modeller som ger en bättre helhetsbild av vad som ska göras.

Det är viktigt att tänka på att varken Effektkartor eller Story maps (eller andra modeller för den delen) är kompletta kravdokument. De är stöd för konversationer mellan människor. Det innebär att de aldrig kommer innehålla alla detaljer. Du kommer aldrig kunna maila modellen till någon utomstående och förvänta dig att den ska fatta. Du, eller någon annan som varit med om att bygga modellen, måste förklara med hjälp av modellen. Jeff Patton liknar det vid ett semesterfoto. Om du ger någon en av dina foton från en resa kommer den aldrig förstå var bilden är tagen, vad som hände före och efter. Men det blir lättare för dig att förklara om du har ett foto att visa.

Prioritering

Att jobba mot en stor ”big bang”-release av sin tjänst är inget vidare. Tidiga releaser mot riktiga användare är bra på flera sätt. Dels kan vi lära oss om hur tjänsten den möter användarnas behov innan den är klar (vilket boken Lean UX av Jeff Gothelf handlar om). Dels tar pengarna ändå alltid slut innan man hunnit utveckla allt man vill, så det är lika bra att från början öva på att leverera något begränsat.

Men för att kunna släppa något innan hela tjänsten är helt klar måste man prioritera vad som ska släppas. Då krävs koll på helheten. Vilka användarbehov är viktigast? Hur hänger olika stories ihop? Vi vill ju släppa något som är tillräckligt komplett för att användarna ska kunna (och vilja) använda tjänsten.

Effektkartan

Grundidén med effektkartan är att åskådliggöra kopplingen mellan en lösning och verksamhetsnytta. Modellen har tre nivåer:
  • Effekt – vilken nytta ska tjänsten göra för verksamheten? Halvdåligt exempel från kattmatsbranschen: ”Fler som köper kattmat hemifrån”.
  • Användning (beteenden och användningsmål) – hur beter sig människor som påverkas av tjänsten, och vilka mål har de? Beteenden och användningsmål ska förstås bygga på vad man vet om användarna – inte bara vad man tror. Prioritering sker också på denna nivå. Vi kan till exempel göra lite user research och komma fram till att vi har en beteendegrupp ”Finsmakaren” som vill uppleva exklusivitet och gärna får detaljer som kattmatens smak och näringsinnehåll. En annan grupp ”Budgetkatten” vill bara betala så lite som möjligt. Vi väljer att prioritera ”Finsmakaren” eftersom vi tror den gruppen tilltalas mer av vår ganska dyra och fina kattmat.
  • Lösning – vad ska utvecklas för att stödja användningen? Lösningar formuleras på en från början hög nivå (till exempel ”tydligt hur näringsinnehåll skiljer sig mellan produkter” eller ”design som upplevs som exklusiv”) och kopplas till de användningsmål de tillgodoser. En fin princip är att lösningarna ska formuleras som egenskaper som går att mäta. Upplevs designen som exklusiv? Det kan vi ju ta reda på genom att fråga användarna. Om den gör det så kommer vi antagligen lyckas locka ”Finsmakaren” att köpa kattmat och – tada! – nytta för kattmatsbutiken som tjänar deg!

Effektkartan kan hjälpa oss att konversera om nytta och prioritera de lösningar som leder till maximal nytta för verksamhet och användare. Att lösningarna är på en hög nivå gör att modellen går snabbt att förklara utan att gå in alltför mycket på detaljer. En bra modell att använda för att beskriva tjänsten för någon oinsatt eller intressenter utanför teamet (till exempel ledningsgruppen).

User story map

Story maps gör det lättare att jobba med User stories i projekt genom att strukturera upp dem istället för att bara lägga dem i en rad (klassisk ”platt” backlog, alltså).

Kartan beskriver vad användaren gör steg-för-steg. Om vi tar en e-handel för kattmat skulle stegen kunna vara ”Hitta kattmat”, ”Köpa”, ”Betala”, ”Få leverans”, ”Mata katt”. Under varje steg finns sedan saker som ska utvecklas (User stories) av olika prioritet.

För att tjänsten ska fungera för användaren måste varje steg fungera, det duger inte att släppa tjänsten utan att ha med steget ”Få leverans” – det skulle användarna aldrig acceptera. Men av de User stories som hör till varje steg är inte alla kritiska. Till exempel behövs SMS-avisering av leveranser inte i en första version av tjänsten. User storyn ”Få SMS-avisering inför leverans” kommer vara lägre prioriterad än t.ex. ”Få kvitto på leverans”. Det här hjälper oss att välja vad som behöver utvecklas för en tidig release av tjänsten som ändå upplevs som komplett.

En Story map ger en helhetsbild av hur tjänsten fungerar utifrån vad användaren gör steg-för-steg. Det gör det lättare att kommunicera då de User stories vi jobbar med i teamet får struktur och kontext på ett sätt som alla kan förstå. Det blir också mer fokus på användningen jämfört med en vanlig ”platt” backlog.

Effektkartor och User story maps i en härlig harmoni

Man kan förstås kombinera de här två modellerna eftersom de är bra på olika saker. Effektkartor är bra för konversationer om nytta och användning, inom teamet eller med intressenter utanför. Story maps är bra för konversationer om detaljer och i vilken ordning saker behöver levereras, inom teamet.

Nina Boljang höll ett bra blixttal om det här på senaste UX Open (2016). Nina pratade bland annat om att prioritering utifrån användares mål är det viktiga med effektkartan, men en Story map underlättar planering av releaser. Väger man in båda perspektiven får man en riktigt vettig total prioritering.

Lästips

Boken User Story Mapping borde vara obligatorisk läsning för alla som jobbar med digitala tjänster.

Handfast guide med exempel på User story map av Steve Rogalsky

Exempel på effektkarta från Huddinge kommun

Bra färsk artikelserie om Effektkartläggning av skaparen Ingrid Domingues:

 

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.

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:

Snabb och långsam förbättring

Som in-house UX:are finns det en fråga som återkommer hela tiden. Nämligen var gör jag mest nytta? – framför allt gällande förbättringar, inte nyutveckling. Jag hade en lunchdiskussion med en kollega om det här som fick mig att fundera lite extra.

Jag tänker att jag kan göra nytta för kund och affär på följande olika sätt:

Små, snabba förbättringar

Man kan göra snabba och mindre förbättringar utifrån vad jag kan om designprinciper, kognition och best practices. Typ se över ett formulär eller ett flöde som verkar dåligt. Testa resultatet på användare och bygga. Det bästa med den här typen av förändring är att den går snabbt och om utgångsläget är dåligt kan man få riktigt bra effekter. Lågt hängande frukt.

Men hur vet man var man ska börja? Man vill förstås prioritera sådant som är viktigast för kund och affär, och som dessutom innebär en minimal insats att förändra tekniskt. Gör en översyn. Vad vill affären? Var har användarna störst problem? Och hur ser de tekniska förutsättningarna ut? Ibland finns det saker som inte ens kräver kodlyft som ger stor nytta, till exempel ledtexter.

Konceptuella förbättringar

Större och mer konceptuella förbättringar, som ett helt nytt webbkoncept, kräver förstås större insatser och är ibland kostsamma. Men de kräver också mer i form av användarundersökningar. Dels för att man vill vara helt säker på att användarna kommer förstå det nya konceptet. Men också för att på en konceptuell nivå finns inga best practices, det handlar om att förstå målgruppens behov och designa för dem.

Om jag till exempel får i uppgift att förbättra kontaktformuläret på stockholm.se så kan jag komma på några saker direkt. Det är mycket att läsa och ta ställning till trots att det bara finns två fält, vilket antagligen gör formuläret svårt att ta sig igenom. Jag tror till exempel att många användare inte kommer läsa texten ”det du skickar till kommunen blir allmän handling”. Så om användaren verkligen måste förstå detta skulle jag hanterat det annorlunda. Om användaren inte måste förstå skulle jag flytta texten och göra den mindre framträdande.

Det går alltså att göra rätt mycket bara utifrån kunskap och erfarenhet. Jag behöver inte veta ett jota om användarna på stockholm.se för att kunna göra ordentliga förbättringar av ett sådant här formulär. Men om jag istället ska förbättra informationsarkitekturen eller startsidan eller förbättra hur hemsidan passar in i ett större sammanhang med Stockholms stads övriga tjänster så skulle det genast bli svårare. Nu måste jag veta vilka som besöker sidan och hur deras behov ser ut. Och det finns inga best practices för hur man gör en startsida för Sveriges huvudstads hemsida. Förstås.

Att veta vilka konceptuella förbättringar som är viktigast att göra är klurigare. Visst, webbanalys kan avslöja en hel del om hur väl ett koncept funkar. Men den säger till exempel inget om huruvida det finns användarbehov som tjänsten missar att tillfredsställa helt. Där måste man göra användarundersökningar för att förstå hur glappet ser ut mellan användarnas behov och tjänsterna som tillhandahålls.

Ibland kommer man till och med fram till att det finns nya målgrupper, som man inte visste om. Som när inUse hjälpte Hemnet att förbättra sin sajt. Man kom fram till att många användare bara är inne för att de är intresserade av inredning eller bara tycker om att titta på hur andra har det. Så idag finns en inspiration-flik för den här målgruppen, där Hemnet tjänar pengar på reklam.

Organisationsförbättringar

För ett tag sedan skrev jag om att bygga en mer användarcentrerad designkultur. Att förändra en organisations kultur och processer går ofta långsamt men är också kanske den mest långsiktiga nytta jag kan göra.

Här kan man också fråga sig var man ska börja. Högst upp, skulle jag säga. Även om organisationen inte är hierarkisk så lyssnar folk på chefer. Men man kan också börja gräva där man står, oavsett om man jobbar med småförbättringar eller konceptuella förbättringar. Inkludera kollegor i UX-aktiviteter som intervjuer och användningstester, visualisera och kommunicera vad man gör och varför.

Så vilket sätt att göra nytta på är bäst? Som vanligt beror det på. Men jag tänker att de här tre sätten kan komplettera varandra på ett fint sätt. Om man gör småförbättringar och levererar nytta snabbt så bygger man förtroende som leder till att man får jobba mer övergripande och konceptuellt. Och under tiden, hela tiden tänka på hur man kan sprida ringar på vattnet och förbättra organisationen.

Tips

The Modern UX Organization – föreläsning av Leah Buley om UX-mognad hos organisationer

Boken Subject to change – ett måste för alla

Building UX culture within an organization – av Chris McCann

Effektmål för att styra teamet åt rätt håll

En viktig del av en bra designprocess är tydliga effektmål. Det finns ju alltid anledningar till att man väljer att sätta ihop ett team för att designa och utveckla något. Men det är tyvärr vanligt att beställare och beslutsfattare inte lyckas rama in varför på ett tydligt sätt. Varför vill vi plöja ner en massa pengar i att byta ut det där Intranätet – egentligen? Vad vill vi uppnå?

Med tydliga effektmål från början blir teamets jobb lättare:

  • Effektivare diskussioner. Vilka användarbeteenden är viktigast? Vilken designlösning är bäst? Utan mål blir det lätt att hamna i tyckanden. Med tydliga mål kan man ställa sig frågan ”vilket alternativ uppfyller målet bäst?”, vilket är ett effektivare sätt att lösa problem på än att tycka.
  • Beslutsfattare behöver inte detaljstyra. Chefer, styrgrupp och andra som ska ta ”större” affärsmässiga beslut behöver sätt att styra resultatet. Om de får besluta om effektmål och man kan visa kopplingen mellan designbesluten och effektmålen så får de den möjligheten, de får kontroll. Om de inte har möjlighet att styra på en högre nivå så finns risken att de börjar tycka till om detaljer.
HIPPO – Highest Paid Person’s Opinion
  • Fokus på nyttan. Det är vanligt att man startar ett projekt av tekniska skäl. Infrastrukturen är föråldrad, CMS:et supportas inte längre, Intranätet är byggt i ett obskyrt programspråk som utvecklarna inte förstår. Föråldrad teknik kan vara ett jätteproblem, men ett tekniklyftet är alltid ett medel för att uppnå något, inte ett mål i sig. Vi uppgraderar inte Intranätet bara för att det är kul med ny teknik utan för att till exempel få gladare, effektivare medarbetare och lägre förvaltningskostnader. Det är lätt att hamna i att teknikbeslut får styra, speciellt om många av projektmedlemmarna kommer från tekniksidan. Om teknikbesluten (och designbesluten) kan kopplas till effekter blir det lättare att ta rätt beslut – det vill säga de beslut som leder till mest nytta.

Det är inte helt lätt att definiera ”bra” effektmål. Alltså mål som kan styra teamet i rätt riktning, som teamet kan använda för att ta rätt beslut och lösa problem. Så hur ska man tänka? Så här tror jag:

  • Målen ska representera vad organisationen vill (till exempel ökad effektivitet hos medarbetarna) men man vill också att det ska ha en stark koppling till satsningen. Visst, ett Intranät kan bidra till att folk blir mer effektiva men medarbetarnas effektivitet beror ju också på så mycket annat. Till exempel arbetsledning och utformning av processer och rutiner. Bättre då att bli lite mer konkret och definiera hur Intranätet kan bidra till ökad effektivitet. Kanske genom ökad kommunikation mellan kollegor eller ökad kännedom om rutiner och processer.
  • Målen ska inte peka ut specifika lösningar, till exempel lättare att söka. Varför vill vi att det ska vara lättare att söka på Intranätet? Kanske för att det ska bli lättare att hitta, vilket kan bidra till ökad kännedomen om rutiner och processer. Sök är en lösning och det kan absolut finnas andra lösningar. Till exempel e-postnotifieringar när en rutin ändras.
  • Målen ska förstås också vara något som kan kopplas till nytta för organisationen, vilket oftast innebär en koppling till ökade intäkter eller minskade kostnader. Om det är få som idag använder Intranätet kan man frestas att sätta målet ökad användning. Men ökad användning i sig är inte något som kan kopplas till nyttan. Det kan ju till exempel bero på att det har blivit ännu svårare att hitta, man måste spendera mer tid på Intranätet för att komma åt de där rutinerna och processerna.
  • Det är också en klar fördel om målen är mätbara, så man vet när man har lyckats. När man måste sätta en siffra på målet blir det också mer konkret, till exempel 8 av 10 medarbetare har under en månad tagit del av någon rutin på Intranätet. När metoder för att mäta saknas får man förstås skapa sådana, till exempel genom förbättrad statistik eller enkätundersökningar.

Tips

Aligning UX Strategy with Business Goals på UXPA
Boken Impact Mapping
inUse:s kurs i effektstyrning

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