Frågeställningar

När?

Det är tyvärr inte alltid så att man som interaktionsdesigner likställs med produktägaren eller projektledaren. Man har inte lika mycket att säga till om. Ofta saknas också resurser i fråga om tid och pengar för att kunna delta fullt ut i hela utvecklingsprocessen. Då gäller det att definera för sig själv och den övriga organisationen var man gör mest nytta.

I boken Contextual Design (Beyer/Holtzblatt ISBN 1-55860-411-1),sidan 314, definierar författarna utvecklingsprocessen fram till inplementationen som en tårtbit, som börjar med "Vision" längst ut. Den följs av i tur och ordning av "Storyboard", "User Environment", "Use case" och "Object model". Som jag ser det bör interaktionsdesignern i huvudsak ägna sig åt att fylla tomrummet som ofta finns mellan "Vision" och "Use cases", i "Storyboard" och "User Environment". "Storyboard" är ju ett ganska känt begrepp, men "User Environment"? Som jag förstår det är "User Environment (Design)" ett sätt att på ett teknikneutralt sätt beskriva användarens olika "arbetsplatser" i ett system. Varje arbetsplats bör innehålla allt som krävs för att utföra arbetsuppgifter relaterade till den arbetsplatsen. Jämför t ex med ett kök, där måste finnas spis, ugn, kastruller, kyl och frys, hushållsmaskiner, tallrikar, bestick etc. Det vore ju vansinnigt opraktiskt att ha kastrullerna i sovrummet!

Ovan beskrivna förhållningssätt är också ett sätt att definiera interaktionsdesign gentemot den förhärskande utvecklingsmetoden i stora projekt - RUP (Rational Unified Process).
Cooper (www.cooper.com), lanserar i ett nyhetsbrev "Form och beteendespecifikationer" och coopers metod "GOAL-DIRECTED© design" som ett komplement till RUP. Form och beteendespecifikationen skulle vara klar och fungera som underlag till RUP.

Även i mindre utvecklingsprojekt, där RUP är för tungrott, har förstås interaktionsdesign en plats. Tidsmässigt och kanske innehållsligt inte så annorlunda egentligen, en form och beteendespecifikation, storyboards eller en "User Environment Design" kan lika väl fungera som kitt mellan vision och implementation och som underlag för fortsatt systemutveckling.
Ett problem kan dock vara att utvecklingsmetodiker som t ex "Extreme Programming", XP, verkar vara ganska rabiata motståndare till att specificera användargränssnitt tidigt i utvecklingsprocessen. Ur en programmerares synvinkel kan det säkert vara rationellt, men jag är ganska säker på att slutprodukten blir sämre för slutanvändaren.

Arbetar med och mot

• Användare
• Systemägare
• Beställare
• Projektledare
• Kravställare
• Systemdesigners
• UI-utvecklare (oftast lika med GUI-programmerare)
• Grafiska designers
• Programmerare
• Systemarkitekter
• Testare

Vad gör man?

1. Fältstudier och observation - utifrån visionen eller uppdraget försöker man skaffa sig en kunskap om sammanhanget den nya it-artefakten ska användas i. Ta gärna med någon av rollerna kravställare, projektledare eller UI-utvecklare.
2. Skriva scenarior/storyboards och ta fram olika konceptuella förslag. Även här är det bra att utföra arbetet tillsammans med t ex kravställarna och projektledaren.
3. Ta fram en "User Environment Design". Skriv om och förfina scenarier och storyboards. Bygg och testa nödvändiga prototyper på användare.
4. Gör en form och beteendespecifikation. Den kan vara ett komplement till eller en del av övrig kravdokumentation. Om form och beteendespecifikationen ska vara detaljerad är det nödvändigt att göra den tillsammans med grafiska designers och/eller UI-utvecklare. Kravställarna bör i alla händelser vara med.
5. När implementationen sätter igång på allvar fungerar man som bollplank och intern konsult i för programmerarna i projektet.
6. När systemet levereras till test kan interaktionsdesignern ta på sig användbarhetsexpertens roll om det inte redan finns en dedicerad sådan. Genom att delta i testningen blir det både möjligt att även systematiskt testa systemets användbarhet, men också att få en direkt återkoppling som kan användas till redesign i nya versioner av systemet.

En kontinuerlig arbetsuppgift som en interaktionsdesigner ofta har är att producera "guide lines" av olika slag - oftast för utformning av användargränssnittent. Den uppgiften löser interaktionsdesignern med data från arbetet som beskrivs ovan. Ett "guide line" dokument skulle kunna beskrivas som en form och beteendespecifikation på metanivå. Tvärt emot vad man kanske tror är ett sådant dokument "levande" och förändras kontinuerligt, dock inte drastiskt. Dels för att det övriga designarbetet påkallar redesign även av de "guide lines" som finns, men också för att t ex det underliggande operativsystemets "guide lines" ändras.

Vad gör man inte?

Ett par riktlinjer tycker jag dock man kan ha:

• Man bör akta sig för att bli fascinerad av tekniken för dess egen skull. Det gäller att "ha fötterna på jorden", både genom att sträva efter så enkla lösningar som möjligt, men framför allt genom att komma ihåg att det är användarnas problem vi ska lösa med det nya systemet, inte ge dem nya eller andra problem.
• I normala fall tycker jag också man ska lämna till kravställarna och beställarna att göra listor med funktionella krav. Däremot kan man gärna skaffa sig makt att avgöra vilka krav som ska med respektive tas bort (man skär alltid i funktionella krav), så att helheten blir bra.
• Lågnivådesign i användargränssnittet kan man också lämna över till andra, oftast UI-utvecklarna. De är ofta mycket duktiga på sådant. På samma sätt som med de funktionella kraven bör dock interaktionsdesignern säkerställa att helheten blir bra genom tester och en tät dialog med utvecklarna.

Epilog

Förhoppningsvis har den här artikeln bringat lite mer klarhet kring vad interaktionsdesign är och framför allt - varför den är nödvändig om man vill utvecklar bra it-artefakter.

Mejla gärna era reaktioner och funderingar till bjorn@sonartdesign.se.