Studentlitteraturs logga inUse logga
  • Dela på Facebook
  • Dela på Twitter
  • Dela på Linkedin
  • Dela på Delicious
  • Dela på Linkedin
 
 

Detta är en gammal version av dokumentet!


Användbarhet i projekt

Interaktiva produkter som inte tillgodoser användarnas behov 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.

Hypotesdriven utveckling

Vår utvecklingsmodell är hypotesdriven1 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.

Idé-, bygg- & förbättringsgsfas

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 kontinuerigt monitorera hur produkten faktiskt används, identifiera nya eller ändrade beteenden och behov, samt besluta och genomföra förbättringar.

Bild: En process med tre faser - Idé-, Bygg-, och Förvaltningsfasen. De tre faserna beskrivs i detalj i sina respektive kapitel.

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)2 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.

Andra metoder behövs också

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.

Traditionell kravhantering

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 grunfunktioner, 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 ett 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, nevigering 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 istället?

Hur gör man då om man skall arbeta med användbarhet i ett projekt där man också vill arbeta med med tradionella 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ådan 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 lö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.

XX här måste man skriva mer

Effekter

Krav på effekter när produkten är i användning. Det finns alltid krav på effekter. Dessutom kan dessa nästan alltid formuleras så att effekterna går att mäta. Om detta inte görs, vilket tyvärr är mycket vanligt, blir det omöjligt att i efterhand och under utvecklingen av produkten avgöra om produkten når upp till målen. Några exempel på effektmål kan vara:

  • Det ska gå snabbare att fylla i blanketten via sajten än på papper.
  • Nyanställda ska efter 2 månaders användning ha en felfrekvens på högst 5%.

Andra effektmål kan vara ”ökad omsättning”, eller ”ökad andel återköp”. För denna sistnämnda typen av mål är dock själva produkten sällan den enda faktorn.

Att formulera och styra efter effektmål är dock inte utan problem:

  • Ofta krävs även andra insatser än att ”bara” skapa en interaktiv produkt. Om effektkravet är exempelvis ”ökad andel återköp” räcker det sannolikt inte att utforma en effektiv e-handelsplats. Effektiv reklamationshantering kan vara en viktig del i lösningen, att bemöta missnöjda kunder på ett vänligt sätt kan vara en annan. Produkten är alltså i detta fall endast en del av de åtgärder som krävs för att åstadkomma effekt. Ofta saknas en roll som kan ansvara för andra åtgärder som krävs, för att förväntad nytta skall uppstå. (Exempelvis utbildning, förändrad löneberäkningsgrund och marknadsföring.)
  • Det kan vara svårt att mäta effekterna, och därmed att validera att produkten motsvarar kraven i projektet. Kravet ”nyanställda ska efter 2 månaders användning ha en felfrekvens på högst 5%” kan helt enkelt inte utvärderas under det att produkten utvecklas.

Egenskaper

Egenskaper kan sägas vara av två typer, dels inneboende materialegenskaper och dels egenskaper som visar sig då produkten används, användningsegenskaper. Krav på generella materialegenskaper hos produkten (prestanda, spårbarhet, programspråk etc.) beskrivs ofta i kravspecifikationen. Däremot beskrivs användningsegenskaperna sällan som krav. Exempel på en materialegenskap kan vara ”XML ska användas”. Exempel på användningsegenskaper kan vara ”mycket hög läsbarhet”, ”användaren ska vägledas vid bokning av gruppresor” eller ”10000 samtidiga användare”.

Funktioner

Figur 4.2 Med fokus på användningskvalitet uppmärksammas krav på effekter och användningsegenskaper. Vikten av att prioritera effektkrav, målgrupper och funktioner betonas också

Funktioner kan dels vara systemfunktioner som utförs utan mänsklig inblandning och dels funktioner där användaren interagerar med produkten. Funktioner beskrivs ofta som användningsfall (se kapitel 4.4.2). I samband med att funktionella krav beskrivs är det mycket viktigt att de prioriteras. Kritiska uppgifter och uppgifter som hanteras ofta, eller av den viktigaste målgruppen, måste vara särskilt enkla och behagliga att genomföra. Prioritering av funktionella krav är ett steg som ofta förbises.

Ibland är valet av material (plattform, produkter, programspråk) styrt av beställarens befintliga miljö. Ibland är funktionskraven styrda av tidigare versioner av produkten och liknande eller samverkande produkter. Lika ofta eller oftare finns det dock en möjlighet att välja material efter de effekter, egenskaper och funktioner som produkten kräver. Problemet är att teknikdrivna projekt ofta definierar materialegenskaper innan bilden av effekter, egenskaper och funktioner är tillräckligt kartlagd.

Förutom att beskriva krav på effekter och användningsegenskaper så bör kraven också prioriteras ur ett nytto- och användningsperspektiv. Prioriteringen av krav gör det enklare att skapa bra interaktionsdesign och gör det också enklare att prioritera om projektet får resursbrist.

 

Noter

2 XXX fotnot som beskriver att detta är tollgates
 
 

Kommentera

Författare

Bild på författareb Johan BerndtssonBild på författareb Ingrid DominguesBild på medförfattaren peter erhardBild på medförfattaren EmmaBild på medförfattaren Björn AnderssonBild på medförfattaren Peter KråikBild på medförfattaren Julia LagerstedtBild på medförfattaren Aurora KarlssonBild på medförfattaren Marcus RehnBild på medförfattaren HelenaBild på medförfattaren Angelica SvanerBild på medförfattaren Maria KareliussonBild på medförfattaren Karin HanssonBild på medförfattaren suzana susecBild på medförfattaren Magnus WigrupBild på medförfattaren Maria SjödinBild på medförfattaren Nina LBild på medförfattaren Emilia OlssonBild på medförfattaren Malin FabbriBild på medförfattaren Charlotte BjörkBild på medförfattaren Jonas EngkvistBild på medförfattaren Anders BjörkBild på medförfattaren Joakim AxelssonBild på medförfattaren Anne RostedBild på medförfattaren gustavjonssonBild på medförfattaren Lotta UlfströmBild på medförfattaren HenrikBild på medförfattaren Gabriel SvennerbergBild på medförfattaren Monika AnderssonBild på medförfattaren Jorge BerdejaBild på medförfattaren Emelie

Senaste ändringar

Facebook

Twitter (@anvandbarhet)

 
Creative Commons-licens

Användbarhet i praktiken - wiki by Ingrid Dominques/Johan Berndtsson is licensed under a Creative Commons Erkännande-IckeKommersiell 3.0 Unported License. Based on a work at anvandbarhet.se.