Efter delaktighet i många olika sorters webbproduktion har jag med tiden sett några återkommande fenomen.

1. Arga användare. De är arga för att något inte fungerar som det ska, för att de ville att vi skulle ha byggt något annat, för att de är tvungna att betala. Summa summarum har ofta blivit en våldsam upprorsstämning där rösterna skalla ’It’s not fair, it’s not worth it!!!’.
2. Uppgivna utvecklare och team. Teamen används som en fabrik som får en specifikation som de ska utföra. De vet inte varför och förstår inte vad poängen är. De är inte det minsta varken stolta eller nöjda med det de har byggt. De undrar bara ’Why on earth are we doing this?’
3. Uppgivna utvecklare 2. Halvvägs in i projekt dyker det upp önskningar om lite nya saker som utvecklarna svarar att det är helt omöjligt att producera. Mantrat låter ’Vi måste vara med tidigare i processen’.  När de har varit med tidigare i processen har de ofta suttit tysta och inte kunnat bidra.
4. Idéer utan effekt. Anställda kommer fyllda med energi och vill visa en idé som de har prototypat på kvällstid – idéer som nästan alltid är helt oanvändbara, som inte kommer att generera ett skit för företaget hur trevliga de än må vara. Idéerna genomförs aldrig och medarbetarna känner sig obesvarade och slutar komma med goda idéer alls.
5. Pengar kastas i sjön. Enorma satsningar på stora team som producerar nya spännande produkter under lång lång tid och när projekten releasas… om de releasas alls… floppar de. Hur vet man att man gör rätt sak?

När jag backar tillbaka de frågorna till rotorsaken lyder de

Hur ska vi kunna garantera en kvalitetsprodukt i slutändan?
Hur ska vi utnyttja kunskaperna hos varje team-medlem på bästa sätt?
Hur ska vi få alla att fokusera på rätt mål?
Hur vet vi att vi gör rätt sak?

När jag började på Barnkanalen, SVT, för tre år sedan dök jag rakt in i att det väl beprövade och framgångsrika konceptet broadcast stod inför totala beteendeförändringar i och med mobila device. Det behövdes större grepp än att ändra tablåläggningen. Vi fick uppdraget att skapa bästa möjliga barnspelarupplevelse online. En av de stora utmaningarna i detta är att vi i vårt public service-uppdrag jobbar för att vara tillgängliga för just nu 260 olika browserversioner, för iOS, Android och Windows phone på samtliga olika device. Det är svårt att få det bra och hålla standard för samtliga. Dessutom skulle vi nu lägga mycket tid och arbete på en helt ny tjänst, vilket alltid är läskigt. Hur vet vi som sagt, att vi gör rätt sak?

Den här gången har inget av de tidigare mantran och frågetecknen uppstått. Vi

• lyssnar på och engagerar våra användare

o   börjar med att göra research på och prata med målgrupperna och summerar några insikter att utgå ifrån. Det visade sig t ex att barnspelaren endast skulle erbjuda hela program och inte klipp och att den skulle ligga placerad på barnkanalen.se och inte i svtplay för att det skulle vara möjligt att bygga på bästa sätt för målgrupperna.

o   testar med användare varje vecka. Alla i teamet deltar när de kan och vill för att se hur barn interagerar med det som ska byggas eller har byggts. Vi har även haft testfamiljer som har sänt in sin feedback från hemmiljön, såväl som vi har besökt familjer i deras hem.

o   mäter allt som går att mäta och justera löpande utifrån den faktiska användarresponsen.

o   releasar så snart det går att releasa själva kärnerbjudandet och lägger ut allt löpande därefter. Det blir små kontinuerliga förbättringar av användarens upplevelse och i bästa fall upplever de att vi svarar på deras önskningar.

• sätter tydliga mätbara mål

o   får en beställning i form av ett mål, t ex ökad timespent eller dubbelt så många återkommande besök per unik besökare. Beställaren önskar sig inga funktioner eller färdiga skisser och teamet löser på egen hand hur målet ska uppnås utifrån alla de detaljkunskaper som krävs för att det ska bli på bästa sätt. På så sätt engageras alla i teamet inte bara tidigare i processen, utan hela tiden, i varje liten detalj. Alla i teamet får också god förståelse varför vi gör det vi gör och kan komma med bästa möjliga idéer som har stor chans att realiseras.

o   gissar nästan aldrig, och när vi gissar följer vi upp och justerar utifrån den mätbara responsen. Tyckande är irrelevant, det är bara vad användartester och statistiken från tjänsten säger som talar om vad vi ska göra. Vi gör små justeringar, releasar och mäter eller testar effekten.

• levererar en kvalitativ produkt i slutändan

o   Vägen till god kvalitet är förstås i grunden att göra rätt saker, men också att se till att det fungerar bra, att det är buggfritt. Släpper vi kod dagligen låter vi inte bara användarna engageras och delta i produkten, utan vi isolerar buggar som uppstår och kan lätt rulla tillbaka dem utan att stänga ner en hel site. I arbetet med barnplay har ingen behövt jobba nätter och dagar i sträck. Själv åkte jag på semester samma helg som vi skulle lansera appen, sidan har legat ute lajv i flera månader. Den är testad och optimerad och det enda vi väntade på var att Apple skulle få ändan ur vagnen och godkänna den i app store.

Det fina med att jobba mot målbilder istället för färdiga skisser är att vi har lyckats med vår leverans när vi har uppfyllt målbilden, inte när alla features i skissen är på plats. Det tydligaste i arbetet med barnplay var kanske att fler funktioner inte hade levererat mot målet om vi inte hade prioriterat att korta laddnings- och svarstider i interaktionen. Funkar inte det som ska fungera kommer ingen att använda tjänsten.  Då har man valt att göra fel saker, eller rätt fast vid fel tillfälle. Nu kunde vi ägna all av teamets tid till att uppnå de mål som var satta.

Presentation av detta från Handelshögskolan samt Berghs, projektledning av digitala projekt.