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

Rapport från UX Open 2014

För några år sedan fanns det inga UX-konferenser i Stockholm alls. Nu finns det flera, vilket är helt fantastiskt.

UX Open, som hölls för tredje året i fredags, bygger mycket på deltagarmedverkan. Dels hålls korta blixttal på 10 min, dels är man med i gruppdiskussioner där deltagarna bestämmer ämne. I år var det också paneldebatter där alla fick delta. Väldans bra upplägg, för det kändes som att rummet var sprängfyllt av kompetens. Och man blir också mer på tårna av att inte bara sitta och lyssna på föreläsningar.

Daniel Anundi inledde med att prata om Service Recovery, den del av tjänstedesign som handlar om att hantera när någon går fel i tjänsteleveransen. Insatsen för att få en ny kund motsvarar insatsen för att behålla fem befintliga. Ändå glömmer man ofta bort att designa för de felsituationer som kan uppstå. Daniels exempel var ett hotell som förstörde en klänning i tvätten och inte bara kompenserade genom att betala för köpa nya kläder. De anlitade också en personal shopper och gav paret en oförglömlig upplevelse under ett restaurantbesök.

Man kan fundera på om den här hotellkedjan tjänar på att kompensera kunder på ett så här ambitiöst sätt. Enligt en studie i den här boken ska företagen sluta försöka överträffa folks förväntningar eftersom överträffade förväntningar inte leder till ökad lojalitet. Sant eller ej, hotellkedjan tjänade säkerligen på just den här kompensationen eftersom historien fått så stor spridning.

Sigrun Tallungs jobbade med användbarhet i polissystemet Pust. Hela Pust-Siebel-haveriet är ett bra exempel på vad som händer om man låter beslut kring teknisk plattform styra i alldeles för hög grad. Och om man låter fel personer besluta om teknisk plattform. Målet med föregångaren Pust-Java var att det skulle vara lätt att använda. Målet med Pust-Siebel var billig förvaltning. Men billigt blev det inte. Man räknar med att Pust-Siebel kostat ca 126 miljoner innan det lades ner.

Några kortisar:

  • Det pratades mycket om användarundersökningar av olika slag. Alla verkar tycka det är en självklar del av UX-arbetet. Bra!
  • Bästa konkreta tipset var att låta stakeholders spela användare och intervjua varandra inför användarintervjuer. På så sätt upptäcker de vilka (felaktiga) antaganden de gör om användarna. Genialt!
  • Kundundersökningar, målbilder och designprinciper. För att funka måste de repeteras, revideras och jobbas vidare med. Häng t.ex. upp på väggar där folk befinner sig eller repetera i början av varje möte.
  • Vi UX:are borde lägga mer tid på att kommunicera vårt jobb – och mindre på att leverera.

Riktigt bra konferens, tack till arrangörerna! Jag ser redan fram emot nästa år. Eller som Maryam skrev:

Jens Wedin tog en massa fantastiska foton. Kolla in.

Skillnaden mellan tjänstedesign och UX design

På UX Open i höstas lyssnade jag på en föreläsning om vad som skiljer sig mellan en tjänstedesigner och en UX Designer. Jag blev förvirrad. Så jag ska försöka mig på en egen förklaring.

I ett projekt jag gjorde som konsult var jag ensam UX designer (eller ja, titeln hette Interaktionsdesigner). Det var ett nyutvecklingsprojekt och eftersom jag är van vid sådant körde jag direkt igång med att definiera effektmål och målgrupper, göra kundintervjuer, ta fram scenarios, koncept och designprinciper. Efter ett tag insåg jag, utan att någon sa något, att man inte hade förväntat sig att jag skulle ta den rollen. Man förväntade sig att jag snarare skulle jobba med gränssnittsdetaljer som huruvida OK-knappen ska ligga till vänster eller höger.

Jag tror projektet verkligen uppskattade att jag tog en större roll. Projektets kunskap om användarna var nämligen alldeles för liten. Och att jag kunde definiera ett övergripande koncept istället för att grotta ner mig i knapp-positioner gjorde att vi kunde se tjänsten som en helhet från början vilket underlättade planering och förankring.

UX design kan ske på olika nivåer, allt från en nitty-gritty pixelnivå till en strategisk nivå där man tar hänsyn till affärsmål, användarbeteenden och drivkrafter. För mig är den strategiska nivån i UX design fundamental. Det är snudd på omöjligt att göra ett bra jobb utan att på djupet förstå affären och användarnas beteenden, drivkrafter, problem och kontext (oberoende av lösning och ”kanaler”).

De som kallar sig tjänstedesigners betonar det här strategiska jobbet och får det ibland att låta som något unikt för tjänstedesign. Men utgångspunkten för en UX designer som jobbar strategiskt och en tjänstedesigner är, så vitt jag förstår, den samma. Förstå affären och användaren, oavsett lösning (digital eller inte). Ta fram koncept och utvärdera med användare.

En intressant skillnad är ”paketeringen” av tjänstedesign:

  • Tjänstedesigners pratar om kunder, inte användare. Kund är ett mer bekant begrepp för de flesta, speciellt höga beslutsfattare som är intresserade av affärsnytta. Det är ju kunderna man tjänar pengar på. Kund inkluderar också inaktiva kunder, som inte ”använder”. Men begreppet kund är också begränsande eftersom det inte inkluderar interna användare som ju också kan bidra till affärsnytta genom användning.
  • Tjänstedesigners jobbar alltid strategisk. UX design är som sagt ett väldigt brett begrepp som inte alltid betyder att man jobbar strategiskt (även om jag tycker att det borde göra det). Så när UX designern ofta är generalist och ska kunna ”allt” från affär till pixlar är tjänstedesignern specialiserad på de strategiska delarna.
  • Tjänstedesign är över huvud taget mer specifikt. Man vet vad man får. Man vet till och med vilken typ av leverabler man kan förvänta sig från en tjänstedesigner (upplevelsekartor).

När det kommer till designkoncept finns en viktig skillnad. Tjänstedesigners kan designa för alla typer av interaktioner, både digitala tjänster och icke-digitala möten som en reception eller ett kölappssystem. UX designern jobbar oftast bara med digitala koncept.

Gränsen mellan det fysiska och digitala suddas ut allt mer. Fysiska produkter blir allt mer digitala och det behövs människor som förstår båda världarna. Betyder det att ”strategiska” UX designers borde bli tjänstedesigners? Jag vet inte. Men jag vet att det är viktigt att vi både förstår vad andra gör och vår egen jobbtitel uppfattas. Annars hamnar vi i kommunikationsproblem. Därför har jag beställt den här boken om tjänstedesign. Hoppas den är bra. Och hoppas att diskussionen dyker upp igen på nästa UX Open den 24 oktober.

Lästips

Breaking up with the User in User Experience Strategy på UXMatters – Om en snarlik begreppsdiskussion på engelska, customer experience och user experience.

Adaptive Paths gratis e-bok Guide to Experience Mapping

Tjänstedesignbloggen – Transformator Designs blogg

Design som förändrar beteenden

Nyår känns långt bort just nu, men jag kom att tänka på nyårslöften idag. Ni vet, 2014 ska jag köpa mer ekologiskt, gå ner i vikt eller sluta röka. Nyårslöften är intressanta för de sätter fingret på något. Ett beteende man vet att man vill förändra.

Nyårslöften ska vara tydliga, de ska enkelt kunna artikuleras på fyllan med ett champagneglas i handen. Men det finns alltid ett motstånd av något slag. Ett nyårslöfte ska inte vara för enkelt. Här är de vanligaste enligt SIFO 2013:

  1. Äta hälsosammare (48 procent).
  2. Börja träna (42 procent).
  3. Stressa mindre (19 procent).
  4. Läsa fler böcker (12 procent).
  5. Få ordning på ekonomin (10 procent).
  6. Dra ner på alkoholen (9 procent).
  7. Ge vänner och familj mer tid (9 procent).
  8. Sluta röka eller snusa (8 procent).

Det här är alltså beteende förändringar som folk vill göra men inte alltid lyckas med. Vi UX designers letar ju efter beteenden hos de vi designar tjänster för. Och jag tänker att vi kanske skulle kunna inspireras av den här listan. För om hjälper folk med de här beteendeförändringarna samtidigt som vi gör en bra tjänst i övrigt tror jag vi kan glädja våra användare lite extra. På Kano-modellens språk, fler delighters.

Ett av mina favoritexempel på en produkt som gör något ”extra” för att glädja mig är min våg. Den heter Withings Wireless Scale och är en smart våg som är uppkopplad mot mitt WiFi så man kan se en viktkurva i en webapp. För några månader sedan kom en automatisk uppdatering. Plötsligt visar den ett litet paraply om det kommer regna under dagen.

Withings Scale

Jag älskar det här. Dels för att det inte var något jag förväntade mig när jag köpte vågen. Men mest av allt för att vågen förändrar mitt beteende. Det är lika enkelt att väga sig som att ta fram telefonen och kolla om det ska regna. Så jag väger mig oftare. Och går runt och tjatar om min fantastiska våg.

Vi pratar ofta om drivkrafterna som får en användare att välja att använda en tjänst. En drivkraft kan ju vara något snabbt och flyktigt, som jag vill snabbt veta min vikt. Och vi kan tillfredsställa den drivkraften på ett superenkelt och effektivt sätt. Men för att göra något extra, något innovativt och verkligen få nöjda användare behöver vi veta varför folk vill veta sin vikt. Vi behöver jobba med mer grundläggande drivkrafter, som jag vill ha kontroll på min vikt eller kanske jag vill gå ner i vikt. Det är vad en våg är till för.

På samma sätt kan en yogakurs vara till för att stressa mindre, en träningsapp vara till för att motivera mig till att börja träna, och en internetbank till för att få bättre ordning på min ekonomi. Eller kanske göra tid för roligare saker än bankärenden. De som förstår det, genom att satsa på att förstå sina användare och deras drivkrafter på djupet, lyckas oftare än andra.

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.