Strict Standards: Declaration of action_plugin_indexmenu::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/indexmenu/action.php on line 13 Strict Standards: Declaration of action_plugin_badbehaviour::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/badbehaviour/action.php on line 72 Strict Standards: Declaration of action_plugin_clearhistory::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/clearhistory/action.php on line 81 Strict Standards: Declaration of action_plugin_metaheaders::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/metaheaders/action.php on line 140 Strict Standards: Declaration of action_plugin_blockquote::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/blockquote/action.php on line 61 Strict Standards: Declaration of action_plugin_editsections_es::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/editsections/action/es.php on line 74 Strict Standards: Declaration of action_plugin_swiftmail::register() should be compatible with DokuWiki_Action_Plugin::register($controller) in /storage/content/37/152837/anvandbarhet.se/public_html/lib/plugins/swiftmail/action.php on line 126
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 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.
Modellen består i sin grundversion av tre faser:
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å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:
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:
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
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.
Kommentera