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.

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

Saker jag lärde mig på UX Open

Igår var jag på UX Open, Martin Christensens UX-konferens som hölls för andra året. I år bestod UX Open av 17 korta inspirerande föreläsningar på 10 minuter, följt av gruppdiskussioner. 10-minuters-formatet är perfekt tycker jag, man hinner aldrig tappa intresse eller zona ut och samtidigt får mängder av olika perspektiv på kort tid.

Jonas Söderström berättade om de designprinciper som den brittiska staten tagit fram och som översatts till svenska. Principerna kanske inte innebär så mycket nytt men jag tycker de är vettiga och välformulerade. Det kan ge tyngd att ha någon sorts auktoritet att peka på istället för att ta fram egna principer.

Begrepp och vad vi kallar oss är nästan en obligatorisk diskussion på sådana här tillställningar. Erik Westerdahl pratade om skillnaden mellan Service Designers och UX Designers och en av gruppdiskussionerna handlade om vad vi kallar oss. Det verkar som att de flesta av oss fortfarande ska ”kunna allt” snarare än att vi är specialiserade på ”ren” interaktionsdesign, informationsarkitektur eller användarundersökningar. Det är både bra och dåligt, förstås. Någon behöver har helhetsbilden. Men hur ska man kunna bli riktigt bra på något om man ska kunna allt? Anneli Olsen fick till roligaste tweeten apropå service design-diskussionen.

Linda Mattsson pratade om Daytonas sätt att göra användningstester hela tiden genom att bjuda in testpersoner en timme varannan vecka. På så sätt blir testerna verkligen gjorda. Bra idé tycker jag, man kan alltid testa mer och det är lätt att slösa för mycket energi på saker som att förbereda testerna och hitta testpersoner när man väl testar.

Quentin Cook pratade om Spotifys nya sätt att kommunicera designbeslut och undvika inkonsekventa gränssnitt. Designbeslut kommer alltid tas, av designers, utvecklare eller chefer. På större företag måste man hitta ett sätt att hantera kommunikationen, ofta med hjälp av en style guide. Problemet med style guides är att de är tungrodda och svåra att underhålla. När nya funktioner ska till som inte passar in måste style guides arbetas om och då måste också produkten jobbas om så det inte finns skillnader mellan produkt och style. Spotifys alternativ är ett antal övergripande designprinciper plus ett front end-ramverk med gränssnittskomponenter (typ Bootstrap) som alltid är synkroniserade med själva produkten.

Det fanns också gott om bra diskussioner, inspirerande historier och bilder på söta katter. UX Open är det bästa som hänt UX-communityt i Stockholm på länge. Tack Martin, bra jobbat!

När projektformen inte funkar

Många digitala produkter slutar utvecklas och glöms bort alldeles för tidigt.

Så här går det enligt min erfarenhet ofta till: När projektet är klart, helst inom tid och budget, firar man (det är bra). Sedan går projektmedlemmarna åt olika håll, med undantag för några som blir kvar och ska jobba med förvaltning. Förvaltning innebär att man hanterar buggar. Ska det till något större behövs ett nytt projekt dras igång. Det leder till att man duckar för större förändringar.

Det finns ofta en övertro på vad som kan levereras inom projektets tid och budget. Klart man är alltid tvungen att prioritera bort saker, det är en sak. Men framför allt har man inte hunnit ta sig tid att lära sig om hur användarna faktiskt använder produkten som levereras, på riktigt.

Det går att göra hur mycket användningstester, djupintervjuer och fokusgrupper som helst under projekttiden. Det är ändå inte förrän när precis hela produkten är färdigimplementerad och har använts under en längre tid som man kan säga hur den används och uppfattas.

Det här är ett extra stort problem när man tar fram komplexa system som användarna jobbar intensivt med varje dag. En sådan situation är svår att användningstesta med en prototyp.

Det är också ett problem när man tar fram en ny och innovativ produkt, eller en social tjänst som bygger på att många använder den samtidigt. Det funkar inte att fråga användarna om de kommer köpa eller gilla produkten, hur ska de kunna veta det?

Resultatet när man inte vet tillräckligt om hur användarna kommer använda produkten blir självklart en dålig produkt med ”dålig UX”, alltså fel funktionalitet presenterad på fel sätt.

Leverera tidigare

Dels behöver man sätta produkten (den riktiga produkten, inte prototypen) i händerna på användarna tidigare. För att komma dit tror jag man måste slarva lite. Inte slarva så mycket med det användaren ser utan med strukturerna och koden bakom. Även om det känns fel måste man prioritera att få ut något snabbt istället för att bygga en perfekt systemarkitektur. Man kan slarva med saker som skalbarhet, dokumentation, driftsäkerhet och annat tekniskt som behövs men inte syns.

För att börja slarva på det sättet måste man prioritera upp kunskap om användandet och prioritera ned teknisk elegans. Alla som jobbar med projektet måste förstå varför.

Kontinuerlig förbättring istället för projekt

Dels tror jag man skulle behöva sluta driva projekt med start och slut. Man behöver se utvecklingen som en investering som börjar men aldrig tar slut. I början bränner man mer pengar, förstås. När det är läge minskar man på tempot gradvis. Kalla det inte förvaltning, utan kontinuerlig utveckling och förbättring i rätt tempo. Självklart kontinuerliga användarundersökningar, utvärderingar och redesign när man lär sig mer om hur produkten används. Inget är slaget i sten.

Det här är klart svårt eftersom beslutsfattare gillar budgetar och deadlines. Det handlar om en förändring i hur man tänker kring IT-satsningar och budgetar i stort.