Studentlitteraturs logga inUse logga
 
 

Skillnader

Här visas skillnader mellan den valda versionen och den nuvarande versionen av sidan.

bok:anvandbarhet_i_projekt [2010-09-05 17:22]
berndtsson
bok:anvandbarhet_i_projekt [2012-04-10 16:22] (aktuell)
nihongo
Rad 1: Rad 1:
====== Användbarhet i projekt ====== ====== Användbarhet i projekt ======
- +{{ :bok:wikinytta.png|}} 
-**Interaktiva produkter som inte tillgodoser användarnas behov dåliga, eller till och med bortkastade investeringar.**+**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 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 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 ===== ===== Hypotesdriven utveckling =====
Rad 18: Rad 19:
Det finns en övertro till att kvaliteten med automatik förbättras [[bok:om_anvaendarna_bara_aer_med_sa_blir_det_bra|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. Det finns en övertro till att kvaliteten med automatik förbättras [[bok:om_anvaendarna_bara_aer_med_sa_blir_det_bra|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 ===== ===== Idé-, bygg- & förbättringsgsfas =====
Rad 24: Rad 24:
  * 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.   * 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.   * 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. +  * 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.
{{:bok:img:hela_processen.jpg|Bild: En process med tre faser - Idé-, Bygg-, och Förvaltningsfasen. De tre faserna beskrivs i detalj i sina respektive kapitel.}} {{:bok:img:hela_processen.jpg|Bild: En process med tre faser - Idé-, Bygg-, och Förvaltningsfasen. De tre faserna beskrivs i detalj i sina respektive kapitel.}}
Rad 30: Rad 30:
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. 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)((XXX fotnot som beskriver att detta är tollgates)) mellan faserna:+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 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ä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.
Rad 46: Rad 46:
-====== Krav och kravhantering ======+====== Traditionell kravhantering ======
-Det traditionella sättet att hantera krav är att beskriva funktionskrav. Tankemodellen är att man vill skapa en entydig beskrivning av vad som projektet skall leverera och vad produkten skall prestera. Det ä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. +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. Tanken är god, men bygger på missuppfattningen att en funktion är entydigt bestämd.
Rad 56: Rad 56:
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.**     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.**    
-Eftersom utgångspunkten med detta arbetssätt är //användningen// 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)+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: Det funktionella angreppssättet har många brister och orsakar många problem:
  - 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.   - 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.
  - 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.   - 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.
-  - 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. +  - 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. 
-  -  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.+  -  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.
  - 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.   - 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.
  - 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.   - 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.
-  - 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.+  - 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.
  - 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.   - 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.
  - 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.   - 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 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.
-===== Hur gör man ===== +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 funktionslista ger mycket små möjligheter att värdera användningskvaliteten hos lösningsförslag, varför vi föredrar 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.  +
- +
-Däremot är det såklart fortfarande bra att ha en funktionell kravspecifikation 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.  +
- +
-Att inte ha en lista med krav som skall betas av kan kännas skrämmande för de som vant sig vid det. 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+
- +
-Det bästa arbetssättet är att modifiera de traditionella funktionskraven till scenarios.  +
- +
-Om du arbetar i ett projekt där man valt att arbeta med traditionella funktionslistor +
- +
-Kravspecifikationen utformas av systemarkitekten och användbarhetsarkitekten tillsammans. Kraven ska godkännas av beställare och leverantör. +
- +
-{{ :bok:img:figur_4_1.png?400|Figur 4.1 Aktiviteter för att formulera krav}}  +
- +
-Det är sällan som alla krav kan beskrivas innan själva utvecklingsarbetet startar. Dels beror detta på att detaljnivån ökar, men också på att beställarens, utvecklingsteamets och målgruppernas kunskaper om vad som är möjligt och önskvärt ökar. Krav tillkommer alltså under processens gång. +
- +
-Under det att projektet pågår så växer också projektteamets verksamhetskunskap. Kartläggning av idé är en teknik för att fånga beställarens syn på verksamheten. Målgruppsanalysen är ett viktigt verktyg för att tidigt samla på sig kunskap om begrepp, attityder, vedertagna arbetssätt, d.v.s. sådant som är kännetecknande för hur verksamheten fungerar och hur framtida användare betraktar arbetet och produkten. Med dessa två tekniker kan man tidigt samla de viktigaste och mest avgörande användningskraven. +
- +
-Kravinsamling brukar man kalla de aktiviteter som just syftar till att tidigt samla in krav, även om krav faktiskt tillkommer under utvecklingsprocessens gång. Ett effektivt sätt att genomföra kravinsamling på är att göra några intervjuer med beställare och idébärare, sedan genomföra målgruppsanalys och att sedan avsluta kartläggningen med en workshop där flera idébärare och beslutsfattare deltar. +
-Resultatet av kravinsamlingen brukar paketeras i ett dokument, en kravspecifikation. Kravspecifikationen beskriver produktens omfattning och innehåll, baserat på det som kommit fram i aktiviteterna kartläggning av idé och målgruppsanalys. +
- +
-Begreppet kravhantering likställs ofta med kravinsamling, men handlar egentligen om något helt annat. Begreppet syftar på det som händer i utvecklingsprocessen när krav förändras eller då de detaljeras och kopplas till lösningsförslag. Vissa förbättringsförslag påverkar projektets omfattning och produktens innehåll. Dessa bör hanteras i en formell process där konsekvenser beskrivs både ur tekniskt- och användningsperspektiv. +
-===== Tre olika typer av krav ===== +
- +
-I dag indelas ofta krav i kategorierna icke-funktionella krav och funktionella krav. Riskerna med detta är att: +
-  - Krav på effekter av produkten i användning inte beskrivs. Därmed blir det omöjligt att validera att man byggt en högkvalitativ produkt. +
-  - Användningsegenskaper som exempelvis krav på läsbarhet, återkoppling och beteende inte kommer med. I denna kategorisering bör dessa egenskaper redovisas under icke-funktionella krav, men tyvärr glöms de ofta bort. Icke-funktionella krav som prestanda, åtkomst, spårbarhet etc. beskrivs ofta, medan krav som påverkar produktens användningskvalitet uppfattas som mjuka, oformliga och svåra att beskriva. Användningskrav är inte svårare att beskriva än andra krav, däremot krävs annan kompetens än teknisk eller affärsmässig för att fånga och beskriva dessa krav. +
- +
-I stället för indelningen funktionella krav och icke-funktionella krav föreslår vi en indelning av kraven i kategorierna; +
-  * Effekter +
-  * Egenskaper +
-  * Funktioner +
- +
-**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** +
- +
-{{ :bok:img:figur_4_2.png?380|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.+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.
-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.+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.
 
 

Författare

Bild på författareb Johan BerndtssonBild på författareb Ingrid Domingues

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.