Universella språket för interaktivitet

April 3, 2009
I den här bloggposten tänkte jag berätta jag om varför de som lyckas med interaktiva projekt arbetar med pappersskisser och om varför kunder som inte får vara med i designprocessen väljer att säga nej till bra ideér.

En stor del av framgången i mitt arbete som Interaktionsdesigner avgörs av hur väl jag redan på idéstadiet lyckas förmedla hur en interaktiva lösning skulle kunna se ut och fungera när den är klar. Interaktivitet är för komplext att bara förklara i ord eller med en bild och kan lätt misstolkas.

Jag har länge försökt ta reda på den bästa metoden att beskriva interaktivitet på och har testat många olika metoder. Detta metodintresse har lett mig till att även studera andra designers om hur de gör. Jag har intervjuat flertalet designers, kravanalytiker och tekniker både i sverige och från andra delar av världen. De som lyckas bäst verkar, oberoende av varandra, använda sig av nästan samma metod även om leveranserna på ytan ser olika ut. Samtidigt ser jag att de som möter störst svårigheter ofta gör på helt andra och minre lyckosamma arbetssätt. Det verkar nämligen finnas ett universellt språk för interaktivitet. 

Förmedla interaktivitet till andra
För att kunna förstå interaktivitet som fortfarande är på ritbordet räcker det inte med att bara se en bild eller läsa sig till en kravmassa. Det visar sig att det krävs en kombination olika medier för att av text och bild för att man man ska kunna göra sig en uppfattning. En bild eller visualisering behvös för att se hur det var tänkt och en förklaring av bilden som förtydligare det som bilden inte kan visa i funktionalitet och aktivitet på sidan. Dock räcker inte detta. I större lösningar måste de förklarade bilderna sättas i sitt sammanhang för att få liv. Scenarier eller storyboards är en mycket användbara tekniker som används flitigt av de som lyckas med IT.

Vi förstår bara interaktivitet vi själva tagit fram
Det visar sig att det är svårt för en person att förstå interaktivitet man inte själv varit med om att skapa. Det innebär att den som kommer in sent i designprocessen kommer att ha svårt att förstå hur det fungerar och varför designbesluten har fattats på det sättet som det har. Det är enormt krävande att ta sig igenom omfattande dokumentation men om man kan ta del av den steg för steg medan den uppstår blir det mycket mer hanterbart. Det är därför av största vikt att se till att alla intressenter är så involverade som möjligt designarbetet redan från början. Det verkar vara mer framgångsrikt att bjuda in uppdragsgivare och tekniker i designprocessen och riskera att de lägger sig detaljer i processen snarare än att ställa dem inför fullbordat faktum och få riskera avslag på slutresultatet.

Helheten först
En tydligt kännetecken för de som lyckas är att de arbetar utifrån ett helhetsperspektiv och tittar först på de stora dragen för att först senare i processen fokusera på detaljer. De som för tidigt ger sig in i att lösa delar av problemen och avskärma sig från helheten hamnar förr eller senare i en återvändsgränd där arbete behöver rivas up under en ofta kostsam process som ofta är upprivande och konfliktfylld för projektgruppen. 

Grundläggande faser
Att beskriva interaktivitiet verkar ske stegvis och följa utvecklingen av processen. Man söker sig fram och måste arbeta i enkla och snabba tekniker först för att sendare fokusera på detaljerna. Det jag har sett är att de framgångsrika tar fram systemet i olika detaljgrad i ungefär fyra steg. Vad man gör benämns olika från företag till företag och många företag är ofta själva omedvetna om att de följer ett mönster. Det jag kan se är att de som misslyckas eller upplever problem i sina processer är de som på grund av okunskap eller i försök att effektivisera processen hoppar över  fler än ett av dessa steg internaktiviteten blir då svår att förmedla.

  1. Behovsanalys — De allra flesta gör en analys av de underliggande kraven den nya interaktiva produkten har. Förutom analysen krävs en tydlig visualisering av kraven i en form som alla i gruppen förstår för att kunna gå hela vägen. Klassiska ändlösa listor med krav som listor eller tabeller brukar dock inte räcka utan någon form av grafisk presentation behövs. Den absolut bästa metoden för att göra behovsanalys är effektstyrning, en metod utvecklad av inUse AB som genom en sk. effektkarta grafiskt visar kraven utifrån ett användningsperspektiv med alla funktioner grafiskt kopplade till de affärsmål som lägger grunden för projektet.
  2. Konceptuell design — Efter att kraven är satta behöver kraven omsättas i ett förslag på lösning. Oavsett vem i som gör detta måste kraven omsättas i dels en tekniklösning möjlig att bygga och ett användargränssnitt möjligt att använda. Här har vi sett att alla utan undantag någon gång under processen använder sig av skisser på papper eller whiteboard i en eller annan form för att kunna driva en diskussion inom teamet framåt på ett effektivt sätt. Här har jag kunnat se största skillnaden mellan de som lyckas och de som misslyckas. De som lyckas bäst är de som bjuder in hela teamet och till och med uppdragsgivaren i skissprocessen. En framgångsrikt genomfört konceptuell projektfas leder till att man lyckas identifiera de underliggande principerna i lösningen vilka sedan ska användas genomgående genom hela systemet både tekniskt och interaktionsmässigt. Största risken med att inte genomföra denna fas på ett tillfredställande sätt är att det då kan finnas diametralt olika uppfattningar om uppgiften inom projektgruppen. 
  3. Protoyp och design — Det visar sig att de flesta arbetar med prototyper. De flesta jobbar i ett format som är relaivt snabbt och lätt att bygga och ändra innehåller och som innehåller klickbara länkar eller animationer som ger en känsla av vad användaren kommer att uppleva under interaktionen. Det visar sig att om man inleder prototyparbetet för tidigt blir stora omvälvande och kostsamma förändringar senare i processen blir nädvändiga. Att hoppa över prototypsteget helt och satsa på utveckling direkt ställer enormt stora krav på flexivbilitet hos utvecklarna för att klara av att hantera processen. Den grafiska designens roll i utvecklingen skiljer mycket åt beroende på vilken typ av organisation som driver utvecklingen frammåt. En klassisk reklambyrå lägger stor vikt på det visuella i processen medan andra funktionsinriktad låter prototyp ligga till grund för och styra den grafiska utformningen. 
  4. Teknikutvecklingen — Det slutgiltiga utvecklingen faller alla delar på plats och den slutgiltiga versionen ser dagens ljus. Generellt kan man säga att om det som kommer tillbaka från utvecklingsavdelningen är en överraskning har du inte lyckats beskriva interaktiviteten på ett bra sätt. Det verkar som om stegvis små överlämning ger bättre resultat än stora vid enstaka tillfällen.

Själfallet finns det ett antal svårigehter med detta om svaret nu ligger i att kombinera text och bild med scenareier tidigt i processen och sedan utveckla detta i prototyper krävs ju ett rätt väl fungerande samarbete mellan olika kompetenser. Någon som är bra på att göra bra skisser kanske inte är bra på förstå de tekniska lösningarna och tvärt om. Jag har sett att en designer och kreatör generellt bär ett motstånd mot att relatera till sin design i text. En designer kan med passion framför en whiteboard förklara varenda del av sitt alster muntligt men samma person blir mycket fåordig när samma förklaring ska ske i text. 

Mycket är dock vunnet genom att alla i projektgruppen lär sig att arbeta med handskisser. Det gör att det går att beskriva en interaktiv ide till exempel på en servett under lunchen och på det sättet driva samtalet framåt exakt när det behövs utan behov av påslagna datorer eller andra hjälpmedel. Jag har märkt att den som själv kan rita en skiss har lättare att förstå andras skisser. Det är alltså ingen slump att jag så fort som möjligt lär ut skissteknik till mina elever på Berghs School of Communication

Ett annat stort steg är att kräva att alla leveranser från en IT-kunsult sker i form av text, bild och sammanhang. På så sätt ökar sannolikheten att man förstår vad de menar och att ingen vilktig kunskap går förlorad i processen.

All denna kunskap har självklart satt en massa tankar i rörelse i mitt huvud. I mitt fall har resan gått så långt att jag grundat Moodcase, ett projektverktyg för interaktiva lösningar med stöd för alla de vikta delarna i processen jag kunnat identifiera.  Den idén bygger på att anväda en  wiki som bas och utfån det enkelt kunna arbeta fram och dokumentera alla steg i designprocessen, både i text och bild. genom att länka samman mina skisser kan ett sammanhang enkelt skapas. Integration med ett av adobes designprogram öppnar möjligheter att senare i processen publicera klickbara protoyper i en direkt i wikin med en exakthet på pixelnivå. Med en detaljerad förklaring av prototypen blir slutresultatet en fullständig teknisk specifikation som är mycket uppskattat underlag för den tekniska utvecklingen. För att stöjda utvecklingsfasen Innehåller Moodcase dessutom ett ärendebaserat system för bughantering och andra typer av förändringar som kommer fram. Allt i ett och samma system.

/ Mårten