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-22 08:48]
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|}} {{ :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 23: 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 60: Rad 61:
  - 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 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. +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.+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. +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 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? +  * 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 +  * 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.  +  * 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.