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:

 

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:

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

Bygga en användarcentrerad designkultur

Under tiden jag filade på det här postade Christopher McCann på EPiServer den här texten på samma ämne. Jag tyckte den var bra, så läs gärna den också 🙂

Som UX designer brottas man ofta med att förändra en organisations designkultur till att bli mer användarcentrerad. Att ta med användarna mer i processen, basera beslut på vad man vet om användarna, öka kunskapen om användarnas behov och kommunicera utifrån ett användarperspektiv. Det kan vara svårt.

Process

Alla UX designers har nog en bild av hur den ultimata processen ser ut. Men alla som försökt jobba enligt sin ”drömprocess” vet att det är svårt. Vi är alltid begränsade till trista saker som budget och tid.

Jag tror man ska vara tuff, följa drömprocessen men banta ned den. Göra alla moment. Om det inte finns tid eller budget så kompromissa inte genom att ta bort moment. Gör momenten kortare, enklare, snabbare. En djupintervju med en kompis mamma är bättre än ingen alls. Ett användningstest med en kollega är bättre än inget alls. Om man gör alla moment så kommer folk runt omkring börja förstå processen, även om det kan kännas futtigt och löjligt ibland.

Inkludera andra i processen så mycket det bara går. Det är energikrävande och tar tid men folk som jobbar tillsammans förstår varandra så mycket bättre. Att ensam få till en förändring är snudd på omöjligt. Man måste skaffa sig allierade och då gäller det att få folk att förstå, på riktigt. Speciellt beslutsfattare vill man ha som allierade. Om en beslutsfattare högre upp fattar så kan det få riktigt bra ringar på vattnet.

Beslutsfattande

Beslut om vad som ska utvecklas och när sker oftast i flera nivåer. Någon i ledningsgruppen kanske beslutar om att en tjänst ens ska börja utvecklas. Mindre beslut kring utformning tas oftast längre led, t.ex. av en utvecklare eller UX designer.

Det är vanligt att designbeslut bygger på magkänsla eller personliga tyckanden. Eller i alldeles för hög grad utgår ifrån tekniska förutsättningar. För att besluten på alla nivåer ska bli mer användarcentrerade och leda till tjänster som folk faktiskt gillar måste man förstås jobba användarcentrerat på alla nivåer. För att det ska hända måste man sprida kunskapen om användarcenterad design i alla led. Och för att det i sin tur ska hända måste folk förstå värdet.

I en liten eller platt organisation tror jag helt enkelt olika kompetenser ska börja jobba tillsammans så man förstår varandra bättre. En utvecklare/arkitekt och en UX:are kanske ska vara aktiv i ledningsgruppen. Eller ledningen kanske ska besöka projekten regelbundet och vara med på användarundersökningar.

När detta inte går får man missionera. Att få utvecklare att förstå är oftast enkelt, speciellt om man jobbar agilt, eftersom man har ett tight samarbete. För beslutsfattare ”högre upp” kan man försöka dra paralleller mellan användarcentrerad design och nytta. Jag har ibland använt effektkartan, som jag skrivit en massa om. Den kan funka bra för att visa kopplingen mellan affärsnytta, kunskap om användare och designbeslut på ett tydligt sätt.

Konkreta goda exempel och framgångssagor kan också funka bra. Men det är viktigt att fokusera på varför man jobbar som man gör och hela tiden relatera till nyttan så den som lyssnar inte får känslan av att man bara gör en massa onödigt extrajobb.

Lästips

Boken Subject To Change av Merholz och Wilkens handlar om precis det här och är svinbra

Applied UX Strategy Part 1: Maturity Models på UXMatters handlar om UX-mognad i organisationer

Mapping Business Value to UX på UXMatters handlar om att mappa UX till affärsnytta

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

Sälja effekt – inte projekt

Lyckade projekt kan vara onödiga

Ett IT-projekt börjar med att någon i en organisation har en idé. Idén är ofta något i stil med ”Vi behöver ett nytt intranät” eller ”Vår gamla webb är så trist, vi behöver en ny”. Om man inte har egen kompetens vänder man sig till en leverantör. Leverantörens säljare svarar glatt på kundens förfrågan. Ett projekt startas och man levererar ett resultat, allt verkar bra.

Men vänta nu, var det här en bra investering? Vad händer när det visar sig att det nya intranätet inte visar sig göra folks jobb lättare? Eller när den nya webbplatsen visserligen är snyggare men inte säljer bättre eller leder till fler jobbansökningar? IT är inte billigt, man kan plöja ner flera miljoner i något som ger liten eller ingen nytta.

De beställningar som görs mot leverantörer, oavsett om det handlar om en webbplats eller ett tungt stödsystem, svarar sällan på vilken effekt man vill skapa. Och ett lyckat projekt är ett projekt som levererar i tid och inom budget. En ny webbplats kan alltså vara lyckad, till och med vinna priser för sin förträfflighet, men samtidigt bidra till minskad försäljning. Det här är förstås fel.

Men vems fel är det? Leverantören har ju levererat enligt specifikation, och i tid dessutom! Så det måste vara kundens fel. Men kunden hade ju inte kompetensen, det var ju därför leverantören anlitades. Något är galet.

Fabric säljer resultat

I veckan lyssnade jag på Rickard Almér från Fabric. Han pratade om webbyråvärlden där många byråer producerar snygga och coola webbplatser utan att fråga eller ta hänsyn till vilken effekt kunden vill skapa. Så länge byråerna kan fortsätta leverera webbplatser som ser snygga ut kan man fortsätta dra in nya uppdrag. Nya kunder tittar ju på de snygga referenscasen, det finns ingen anledning att mäta faktiska resultat.

Fabrics idé är att istället hjälpa sina kunder skapa resultat. Man börjar med att identifiera de KPI:er kunden vill skapa. Baserat på dessa mål tar man fram en ettårsplan för vilka resultat man tror sig kunna uppnå. Sedan jobbar Fabric med att kontinuerligt förbättra webbplatsen, samtidigt som man kontinuerligt följer upp KPI:erna.

Lättare att sälja traditionellt

sälja effekt

Ett problem är att det är så enkelt att fortsätta sälja som man alltid gjort. Leverantörerna har säljare som är duktiga på att säga det kunden vill höra. Vill man sälja effekter måste kunden utmanas och börja tänka nytt. Leverantören måste våga lägga briefen eller kravspecifikationen åt sidan och fråga vad kunden vill uppnåKunden måste våga släppa den lösning man fantiserar om och ge leverantören mer utrymme. Är det ens ett intranät som ger mest effekt för pengarna? Det kanske behövs en organisationsförändring? Eller ett bättre videokonferenssystem?

Och så länge leverantören vill tjäna pengar är det förstås svårt att ifrågasätta kundens tänkta projekt. Leverantörens säljare mäts ju på hur många projekt de drar in, inte hur mycket kundnytta de bidrar till. Men de leverantörer som kan börjar fokusera på effekter kommer kunna plocka många poäng hos sina kunder. Om några år kanske vi behöver börja konkurrera med faktiska resultat, när beställarna lär sig att snygga referenscase inte är speciellt intressanta.