Interaktiva produkter som inte tillgodoser användarnas behov är dåliga, eller till och med bortkastade investeringar.

Vår modell har ett tydligt användningsperspektiv. Det är nyttan i användningen som vägleder beställare, projektledare, designers och programmerare när de ska ta beslut. Det är ryggraden i projektet.

Vår utgångspunkt är att nyttan för såväl enskilda användare som nyttan för en hel verksamhet uppstår i användningen! Interaktiva produkter som användarna upplever som meningsfulla, enkla och roliga att använda har helt enkelt förmågan att generera de förväntade värdena för den som investerat pengar i att utveckla dem.

Vår utvecklingsmodell är hypotesdriven¹ Konkret betyder det att processen är skapad så att man definierar en hypotes som skall valideras eller falsifieras. Hypotesen gäller de värden, den nytta, som den interaktiva produkten förväntas skapa för sina användare och för beställaren.

I praktiken betyder det också att processen behöver vara iterativ, eftersom det helt enkelt är omöjligt att förstå hela värdekedjan direkt. Lösningen är att designa och testa de viktiga delarna tidigt och arbeta med detaljerna efter det att man är trygg med att man är på rätt väg.

Eftersom vi utgår från att nyttan uppstår i användningen kommer prövningen av hypotesen att ske i verklig användning. Det är i verklig användning som vi får all kvalitativ information om hur väl produkten fungerar och huruvida den skapar de förväntade värdena.

Modellen säkerställer också att verksamhetsansvariga och användare involveras på ett strukturerat sätt så att man undviker att bygga lösningar baserade på rena tyckanden.

Det finns en övertro till att kvaliteten med automatik förbättras om man låter beställare och användare berätta vad de vill ha. Vår modell bygger istället på att analysera observerbara beteenden och använda det som grund för designarbetet, istället för att designen blir ett resultat av jämkningar av olika aktörers gissningar om vad som användarna ”egentligen” behöver.

Modellen består i sin grundversion av tre faser:

• Idéfasen – att beskriva idén på ett sådant sätt att det blir tydligt dels vilken den tänkta nyttan är och dels hur den framtida tjänsten, produkten eller systemet skall kunna skapa den tänkta nyttan.
• Byggfasen – att säkra upp att lösningens utformning skapar den förväntade nyttan i användning. Det innebär att funktion, form och innehåll samverkar så att nyttan uppstår i användningen.
• Förbättringfasen – att säkerställa att tjänsten, produkten eller systemet fortsätter att generera den tänka nyttan. Det innebär att kontinuerligt övervaka hur produkten faktiskt används, identifiera nya eller ändrade beteenden och behov, samt besluta och genomföra förbättringar.

Fasindelningen är konstruerad så att beslutsfattare och verksamhetsansvariga ska få ett fullständigt underlag för att starta utvecklingsprojekt och för att släppa ny funktionalitet till användning.

Därför ligger beslutspunkter (så kallade vägskäl) mellan faserna:

• Vägskäl 1: Här måste beslutsfattarna ha allt underlag som gör att de känner sig trygga med att den beskrivna lösningen har förutsättningar att skapa den tänkta nyttan.
• Vägskäl 2: Här måste verksamheten vara övertygad om att det byggda skapar förväntade värden och har tillräcklig (teknisk och användnings-) kvalitet för att släppas till förvaltning.

Vår modell syftar till att göra det enkelt att prioritera och välja vad det är man skall bygga. Detta passar mycket bra för alla projekt (oavsett utvecklingsmodell) där man vill ha kontinuerliga leveranser och styra så att det viktigaste byggs först. Här innefattas Agila metoder, men samma projektstrategi går att etablera i andra utvecklingsmodeller.

Det sätt att arbeta som vi beskriver här förutsätter att man gör andra normalt förekommande aktiviteter i projektet på det sätt man brukar eller föredrar.

Här beskriver vi vad som behövs för att säkerställa nyttan av investeringen och nyttan för användarna. Här beskrivs inte:

• Hur man ska leda och styra projektet - här behövs en projektledningsmetod. Använd PROPS, PEJL, Scrum, eller den metod du tycker är bäst.
• Hur man skall arbeta med att bygga systemet rätt (ref) - här behövs en utvecklingsmetod. Använd RUP, Lean Programming,eller den metod du anser är bäst.
• Hur man ska skapa underlag till investeringsbeslutet i vägskäl 1 så brukar man ofta göra en kostnads/intäktsanalys. Använd den teknik du brukar använda, exempelvis PENG, EVA eller annan.

Det traditionella sättet att hantera krav är att beskriva funktionskrav. Målet är att skapa en entydig beskrivning av vad som projektet skall leverera och vad produkten skall prestera. Det är därför vanligt att man vill använda kravlistan för testning och syftet är att man skall kunna pricka av vad som är klart och godkänt och vad som inte stämmer.

Tanken är god, men bygger på missuppfattningen att en funktion är entydigt bestämd.

I själva verket är det så att en funktion kan i praktiken utformas på många olika sätt, varav bara ett fåtal ger den tänkta nyttan.

Utgångspunkten för vårt arbetssätt är användningen, och då sätts de traditionella funktionella kravspecifikationerna delvis ur spel. Funktioner är alltså - som vi ser det - ingen bra beskrivning av vad som är ”rätt lösning”, men kan fungera bra om man vill ”bygga lösningen rätt” (ref)

Det funktionella angreppssättet har många brister och orsakar många problem:

1. Det blir ett stort fokus på de uttalade kraven. Problemet är att många krav är så ”självklara”, eller så integrerade att beställaren och de framtida användarna helt enkelt inte tänker på dem och därför inte kravställer just dessa viktiga funktioner.
2. Det är inte ovanligt att kraven formuleras av personer som inte har kunskap om hur den faktiska användningen går till. Om kraven inte kontrolleras med vad användarna behöver finns en risk att men bygger en produkt som inte motsvarar de verkliga kraven.
3. Vissa krav kan beställare och framtida användare sällan själva formulera, de som skapar ”wow”-effekten. Det är betydligt enklare att beskriva vad man förväntar sig som grundfunktioner, men mycket svårare att beskriva vad som skulle göra mig positivt överraskad.
4. Att ha en lista med funktionskrav bygger på tanken att det går att avgöra om en funktion är ”klar”. Om kraven skall vara enkla att validera, så måste de vara små och välavgränsade. Arbetet med att formulera sådana krav är tidsödande och svårt. Om man då istället bestämmer sig för en grövre nivå på funktionskraven kan det vara svårt att avgöra om funktionen är klar.
5. Funktionskraven blir ofta många, vilket betyder att det blir svårt för beställaren att avgöra om den motsvarar det hon vill ha.
6. Man luras lätt att tro att den omfattande listan beskriver hela kravbilden, utan att man sätter sig in i den. När man väl sätter sig in i den är det svårt att upptäcka vad som fattas och vilka krav som är felaktiga.
7. I listan finns ofta krav som saknar relevans. Om man försöker bryta ned kraven till sådana som kan prickas av, så blir de lätt detaljfokuserade. Det kan då finnas krav som i detalj beskriver texter, navigering eller annat som med fördel kan lösas på ett betydligt behagligare eller snyggare sätt.
8. I listan finns ofta krav som saknar relevans. Det är inte ovanligt att idéer från ett tidigt skede som saknar relevans för användarna ”hänger med” och blir krav för byggandet.
9. Kraven har otydlig viktning. Ibland arbetar man med att ge kraven vikt, men ofta blir viktningen grovhuggen och de flesta kraven måste tillgodoses. Detta skapar problem för designers som inte vet vad som behöver stå ut och vad som kan ligga längre bak. Det skapar också problem för projektledaren som får mycket lite vägledning.

Hur gör man då om man skall arbeta med användbarhet i ett projekt där man också vill arbeta med med traditionella funktionskrav? En funktionslista ger mycket små möjligheter att värdera användningskvaliteten hos lösningsförslag, varför vi förordar att textuella beskrivningar av användargränssnitt hålls till ett minimum och så fort som möjligt kompletteras med skisser, designförslag och prototyper.

Att inte ha en lista med krav som skall betas av kan kännas skrämmande för de som vant sig vid ett sådant arbetssätt. När man väl inser att användningskvalitet inte går att beskriva som enkla funktioner, eftersom det handlar om beteenden, flöden, att hjälpa det mänskliga systemet, och att skapa något attraktivt så blir det å andra sidan en befrielse att slippa den omständliga kravhanteringen.

En funktionell kravspecifikation är fortfarande utmärkt att använda för sådana krav som verkligen går att testa och bocka av, som exempelvis att verksamhetsregler följs, att åtkomst ges till rätt person etc.

Lösningen är att

• se till att beskriva de viktigaste egenskaperna i gränssnittet i en principdesign. Hur sker navigering, återkoppling och flöden? Hur är mönstret för olika funktioner uppbyggda? Vilka är reglerna för språk och tonalitet, vilka är reglerna för bilder och ikoner?
• komplettera funktionella beskrivningar av flöden (exempelvis användningsfall i RUP och user stories i Scrum) med skisser av gränssnittet i flödet.
• beskriva effektmålen som produkten skall hjälpa till med, såväl på verksamhetsnivå som för respektive målgrupp.
• hålla listan av funktionella krav till sådana krav som går att entydigt testa.
• införa interaktionstester i varje iteration.
• införa användningstester som ett systematiskt sätt att validera lösningen.
• införa användningskvalitet som ett produktmål.
• återkoppla projektets progress vad gäller användningskvalitet till styrgruppen på varje styrgruppsmöte.