Effektkarta och User story map – två modeller för prioritering

Jag älskar modeller. En bra och tydlig modell kan göra kommunikationen i ett projekt så mycket lättare.

Effektkartan är en modell jag jobbat mycket med. Den har hjälpt mig (och andra) att kommunicera och nå delad förståelse. Den har också hjälpt mig i prioritering av lösningar. En annan modell som jag lärt mig på allvar på senare tid (genom att läsa den briljanta boken User Story Mapping av Jeff Patton) är User story map. En Story map kan också underlätta delad förståelse och prioritering. Men på lite andra sätt.

Delad förståelse

Hur håller vi reda på vad som ska utvecklas och ser samtidigt till att alla i teamet vet vad som ska göras? Att mommunicera via många och långa dokument fungerar inte, det vet vi. Teammedlemmarna måste prata med varandra. Men om tjänsten är komplex, vilket den ofta är, behövs det någon form av dokument att kommunicera kring. User stories är ett vanligt sätt, men en User story i en vanlig backlog har ett problem. Den saknar kontext. Hur passar den här storyn in i helheten? Alltså, vilka andra stories hänger den ihop med, och vilka användarbehov löser den? Effektkartor och Story maps är modeller som ger en bättre helhetsbild av vad som ska göras.

Det är viktigt att tänka på att varken Effektkartor eller Story maps (eller andra modeller för den delen) är kompletta kravdokument. De är stöd för konversationer mellan människor. Det innebär att de aldrig kommer innehålla alla detaljer. Du kommer aldrig kunna maila modellen till någon utomstående och förvänta dig att den ska fatta. Du, eller någon annan som varit med om att bygga modellen, måste förklara med hjälp av modellen. Jeff Patton liknar det vid ett semesterfoto. Om du ger någon en av dina foton från en resa kommer den aldrig förstå var bilden är tagen, vad som hände före och efter. Men det blir lättare för dig att förklara om du har ett foto att visa.

Prioritering

Att jobba mot en stor ”big bang”-release av sin tjänst är inget vidare. Tidiga releaser mot riktiga användare är bra på flera sätt. Dels kan vi lära oss om hur tjänsten den möter användarnas behov innan den är klar (vilket boken Lean UX av Jeff Gothelf handlar om). Dels tar pengarna ändå alltid slut innan man hunnit utveckla allt man vill, så det är lika bra att från början öva på att leverera något begränsat.

Men för att kunna släppa något innan hela tjänsten är helt klar måste man prioritera vad som ska släppas. Då krävs koll på helheten. Vilka användarbehov är viktigast? Hur hänger olika stories ihop? Vi vill ju släppa något som är tillräckligt komplett för att användarna ska kunna (och vilja) använda tjänsten.

Effektkartan

Grundidén med effektkartan är att åskådliggöra kopplingen mellan en lösning och verksamhetsnytta. Modellen har tre nivåer:
  • Effekt – vilken nytta ska tjänsten göra för verksamheten? Halvdåligt exempel från kattmatsbranschen: ”Fler som köper kattmat hemifrån”.
  • Användning (beteenden och användningsmål) – hur beter sig människor som påverkas av tjänsten, och vilka mål har de? Beteenden och användningsmål ska förstås bygga på vad man vet om användarna – inte bara vad man tror. Prioritering sker också på denna nivå. Vi kan till exempel göra lite user research och komma fram till att vi har en beteendegrupp ”Finsmakaren” som vill uppleva exklusivitet och gärna får detaljer som kattmatens smak och näringsinnehåll. En annan grupp ”Budgetkatten” vill bara betala så lite som möjligt. Vi väljer att prioritera ”Finsmakaren” eftersom vi tror den gruppen tilltalas mer av vår ganska dyra och fina kattmat.
  • Lösning – vad ska utvecklas för att stödja användningen? Lösningar formuleras på en från början hög nivå (till exempel ”tydligt hur näringsinnehåll skiljer sig mellan produkter” eller ”design som upplevs som exklusiv”) och kopplas till de användningsmål de tillgodoser. En fin princip är att lösningarna ska formuleras som egenskaper som går att mäta. Upplevs designen som exklusiv? Det kan vi ju ta reda på genom att fråga användarna. Om den gör det så kommer vi antagligen lyckas locka ”Finsmakaren” att köpa kattmat och – tada! – nytta för kattmatsbutiken som tjänar deg!

Effektkartan kan hjälpa oss att konversera om nytta och prioritera de lösningar som leder till maximal nytta för verksamhet och användare. Att lösningarna är på en hög nivå gör att modellen går snabbt att förklara utan att gå in alltför mycket på detaljer. En bra modell att använda för att beskriva tjänsten för någon oinsatt eller intressenter utanför teamet (till exempel ledningsgruppen).

User story map

Story maps gör det lättare att jobba med User stories i projekt genom att strukturera upp dem istället för att bara lägga dem i en rad (klassisk ”platt” backlog, alltså).

Kartan beskriver vad användaren gör steg-för-steg. Om vi tar en e-handel för kattmat skulle stegen kunna vara ”Hitta kattmat”, ”Köpa”, ”Betala”, ”Få leverans”, ”Mata katt”. Under varje steg finns sedan saker som ska utvecklas (User stories) av olika prioritet.

För att tjänsten ska fungera för användaren måste varje steg fungera, det duger inte att släppa tjänsten utan att ha med steget ”Få leverans” – det skulle användarna aldrig acceptera. Men av de User stories som hör till varje steg är inte alla kritiska. Till exempel behövs SMS-avisering av leveranser inte i en första version av tjänsten. User storyn ”Få SMS-avisering inför leverans” kommer vara lägre prioriterad än t.ex. ”Få kvitto på leverans”. Det här hjälper oss att välja vad som behöver utvecklas för en tidig release av tjänsten som ändå upplevs som komplett.

En Story map ger en helhetsbild av hur tjänsten fungerar utifrån vad användaren gör steg-för-steg. Det gör det lättare att kommunicera då de User stories vi jobbar med i teamet får struktur och kontext på ett sätt som alla kan förstå. Det blir också mer fokus på användningen jämfört med en vanlig ”platt” backlog.

Effektkartor och User story maps i en härlig harmoni

Man kan förstås kombinera de här två modellerna eftersom de är bra på olika saker. Effektkartor är bra för konversationer om nytta och användning, inom teamet eller med intressenter utanför. Story maps är bra för konversationer om detaljer och i vilken ordning saker behöver levereras, inom teamet.

Nina Boljang höll ett bra blixttal om det här på senaste UX Open (2016). Nina pratade bland annat om att prioritering utifrån användares mål är det viktiga med effektkartan, men en Story map underlättar planering av releaser. Väger man in båda perspektiven får man en riktigt vettig total prioritering.

Lästips

Boken User Story Mapping borde vara obligatorisk läsning för alla som jobbar med digitala tjänster.

Handfast guide med exempel på User story map av Steve Rogalsky

Exempel på effektkarta från Huddinge kommun

Bra färsk artikelserie om Effektkartläggning av skaparen Ingrid Domingues:

 

Annonser

Förstå varandra – bli effektivare

Nu i sommartider blir det lite peace love and understanding här, av typen som man kan lära sig om i managementböcker som heter saker som ”How to Become Successful in 4 Simple Steps”.

Vi börjar med ett citat av världens kanske mest citerade människa, Martin Luther King, Jr:

Peo­ple fail to get along because they fear each other, they fear each other because they don’t know each other; they don’t know each other because they have not com­mu­ni­cat­ed with each other.
Det är lätt att hamna i känslan av att någon i ens närhet är ignorant, dum eller ond. Känslan är ibland den reflexmässiga när någon tycker annorlunda, men förstås nästan alltid fel. Därför borde vi jobba mer på att förstå varandra och mindre på att bråka (peace!).

Visa känslor på en oljerigg

Jag lyssnade på en fin historia i podcasten Invisibilia (som är jättebra och handlar om hur människor fungerar). Den handlade om män som jobbade på en oljerigg. Det var en rätt farlig miljö och kulturen var klart macho. Man frågade inte frågor och visade inte känslor, jobbade på. När en arbetare dog i en olycka sörjde kollegorna i 15 minuter, jobbet fick inte stanna upp.

I ett försök att få upp effektiviteten anlitade man en ledarskapskonsult som använde rätt ovanliga metoder, med Shells mått mätt. Hennes mål var att få arbetarna att hantera sina rädslor och börja visa känslor. De fick berätta om sina liv för varandra och göra olika övningar i att visa sig sårbara och erkänna sina misstag och brister. Till exempel fick de i par svara på frågan ”Om du fick förändra en sak med mig – vad skulle det vara?”.

Det här blev en rätt omvälvande upplevelse för oljeriggsarbetarna. Det skapade en helt annat sätt att bete sig och samarbeta på arbetsplatsen. Ökad trygghet, mer kommunikation och känslor. Det gav också resultat. Mängden olyckor gick ner med 84 procent och produktiviteten ökade till rekordnivåer.

Vi är alla en färg (eller flera)

På mitt jobb gjorde vi en DISC-analys för ett tag sedan. Man svarar på en massa frågor och får en färg (röd, gul, grön eller blå) som visar ens jobbpersonlighet. Man fick också träna sig i att identifiera vilka färger andra är och lära sig lite om hur de tänker.

Även om jag kanske inte använder färgtänket så mycket har jag har blivit bättre på att tänka att folk kan ha andra perspektiv och andra mål. Det här är en skill som jag tror vi UX:are är rätt bra på generellt, eftersom vi jobbar med att förstå andra människor. Vi borde bara lära oss att använda den mer på kollegor och andra runt omkring oss.

Förstå hur korkade beslut tas

En grupp som väcker speciellt mycket irritation är de som tar ”korkade” beslut. På konferensen From Business to Buttons i våras pratade Simon Bennett om hur beslutsfattare tänker:

Hur kan vi vara mer som Buddha?

Jag kan rätt lite om buddhism men tänker att en Buddha aldrig blir irriterad på en medmänniska. För att bli mer som Buddha behöver vi förstå varandra genom att kommunicera på ett ärligt och öppet sätt. Berätta vad du är bra på, men erkänn också dina fel och brister. Då blir det blir lättare för andra att förstå ditt perspektiv när ni tycker olika.

Så här kommer det – How to Become Sucessful in 4 Simple Steps:

  1. Inför parterapi i dina agila team
  2. Maila alla kollegor på företaget och berätta varje gång du begår ett misstag
  3. Bjud en kollega på tårta och berätta om din livshistoria varje dag
  4. Gör en DISC-analys och klä dig helt i rött, gult, grönt eller blått

Om stegen känns svåra så kan du börja med att öva dig på att förstå andras perspektiv. Inför ett möte – vilka mål har deltagarna? Och när någon tycker annorlunda – varför tycker hen så?

Trygga grupper presterar bättre

När människor i en grupp vågar visa våra svagheter och brister, känner varandra och kommunicerar så blir vi mer trygga. Och det har visat sig att trygghet är en viktig faktor för att team ska prestera.

Google studerade 180 arbetsgrupper för att förstå vad som fick vissa team att prestera bättre än andra. Deras hypotes var att det handlade om kompetens och att få till den ultimata kombinationen av olika kompetenser. Men man hittade inget sådant samband. Förmågan att prestera hängde snarare ihop med mjuka faktorer, alltså hur teamet samarbetade. Och den allra viktigaste faktorn för att teamet skulle prestera var känslan av trygghet. Alltså om medlemmarna i teamet kunde riskera att ha fel utan att känna sig bortgjorda.

Jag tycker det här visar att vi borde satsa mer på gruppdynamik när vi skapar och jobbar i team. Speciellt om teamet ska jobba under en längre tid och läget är pressat, teamet ”måste” prestera. Det är förresten i de tillfällena vi ofta struntar i saker som kick-offer, fikor och after work. Det finns inte tid.

Bli bättre på presentationer

Jag tycker det är läskigt att hålla presentationer, det är jag inte ensam om. Men det finns också få saker i jobbet som kan få en att känna sig kompetent och viktig som när man gör en bra presentation. Och så älskar jag hantverket, att bygga presentationer som får folk att förstå. Tyvärr har alldeles för många bara blivit liggande eftersom jag inte kommit över tröskeln att presentera.

I onsdags var jag på Mike Monteiros workshop Presenting Design Like Your Life Depends On It (Because It Will), i samband med From Business to Buttons. Vi fick öva på att presentera för varandra och lärde oss massor. Här kommer de viktigaste sakerna jag lärde mig:

Var ordentligt förberedd

Du som presenterar måste ha riktigt bra koll på materialet. Det kommer alltid hända oväntade saker under en presentation. Oväntade frågor kommer komma, oväntade personer dyker upp, någon vill att du hoppar över delar av materialet eller förklarar något på djupet. Ha inget manus, för då tvingas du kunna materialet riktigt bra och du får lättare att hantera det oväntade. Utan manus blir det också lättare att presentera på ett engagerande sätt.

Var öppen för att oväntade frågor och diskussioner kommer upp. Men försök se till att rätt frågor dyker upp genom att inleda presentationen med att berätta varför alla är här, vilken roll folk har och vilken typ av frågor du vill få.

Känn till folks drivkrafter

Alla som deltar har ett mål, ibland kan målet vara att bara komma därifrån. Ett sätt att både göra bättre presentationer och hantera oväntade situationer (som att någon håller en 20-minuters monolog om något du tycker är irrelevant) är att förstå de olika agendor folk har. Som presentatör eller workshopledare är det lätt att skaffa sig en drömbild av vilka diskussioner som kommer komma upp. Den drömbilden bygger på din agenda, ditt perspektiv, designperspektivet. Men om du presenterar för icke-designers kommer åhörarna naturligtvis ha andra perspektiv och andra agendor.

Använd användarcentrerade designmetoder. Analysera målgruppen, deras drivkrafter och designa presentationen för dem, inte för dig själv. Ibland krävs det att du intervjuar deltagarna inför en presentation.

Workshopen i onsdags fokuserade på att presentera design för beslutsfattare/kunder. I den situationen vill de som lyssnar känna sig trygga i att du har gjort ett bra jobb, att allt är genomtänkt och att din design kommer göra företaget framgångsrikt. Det handlar inte om att gå igenom varje liten designdetalj del för del. Det handlar om att sälja – både designen och dig själv som experten som har gjort ett fantastiskt jobb.

Ta kontroll över rummet

Kroppsspråk och röstläge spelar roll. Stå alltid upp när du presenterar. Visa att du är i fokus genom att gestikulera och tala tydligt. Men du behöver inte försöka vara någon annan. Var dig själv, men dig själv när du är som mest engagerad. Om du visar att du brinner för det du pratar om så smittar det av sig.

Det är svårt att bryta sådana här mönster. Jag tror det handlar mycket om att öva, och få feedback.

Be om feedback

Den viktigaste saken i en process är att den förbättras kontinuerligt. Det gäller också ditt sätt att presentera. Tyvärr är det sällan man får någon annan typ av feedback än en klapp på axeln. Riktig feedback kommer inte av sig självt, den måste du be om.

Sammanfattning

För att sammanfatta ska jag bli bättre på att:

  • Vara förberedd och skippa manus
  • Tänka på åhörarna och deras drivkrafter inför en presentation
  • Vara medveten om hur jag presenterar och öva oftare
  • Be om feedback

Tips

Mike Monteiros 13 Ways Designers Screw Up Client Presentations som artikel på medium, som video från From Business to Buttons

Mikes podcast Let’s Make Mistakes

 

Effektmål för att styra teamet åt rätt håll

En viktig del av en bra designprocess är tydliga effektmål. Det finns ju alltid anledningar till att man väljer att sätta ihop ett team för att designa och utveckla något. Men det är tyvärr vanligt att beställare och beslutsfattare inte lyckas rama in varför på ett tydligt sätt. Varför vill vi plöja ner en massa pengar i att byta ut det där Intranätet – egentligen? Vad vill vi uppnå?

Med tydliga effektmål från början blir teamets jobb lättare:

  • Effektivare diskussioner. Vilka användarbeteenden är viktigast? Vilken designlösning är bäst? Utan mål blir det lätt att hamna i tyckanden. Med tydliga mål kan man ställa sig frågan ”vilket alternativ uppfyller målet bäst?”, vilket är ett effektivare sätt att lösa problem på än att tycka.
  • Beslutsfattare behöver inte detaljstyra. Chefer, styrgrupp och andra som ska ta ”större” affärsmässiga beslut behöver sätt att styra resultatet. Om de får besluta om effektmål och man kan visa kopplingen mellan designbesluten och effektmålen så får de den möjligheten, de får kontroll. Om de inte har möjlighet att styra på en högre nivå så finns risken att de börjar tycka till om detaljer.
HIPPO – Highest Paid Person’s Opinion
  • Fokus på nyttan. Det är vanligt att man startar ett projekt av tekniska skäl. Infrastrukturen är föråldrad, CMS:et supportas inte längre, Intranätet är byggt i ett obskyrt programspråk som utvecklarna inte förstår. Föråldrad teknik kan vara ett jätteproblem, men ett tekniklyftet är alltid ett medel för att uppnå något, inte ett mål i sig. Vi uppgraderar inte Intranätet bara för att det är kul med ny teknik utan för att till exempel få gladare, effektivare medarbetare och lägre förvaltningskostnader. Det är lätt att hamna i att teknikbeslut får styra, speciellt om många av projektmedlemmarna kommer från tekniksidan. Om teknikbesluten (och designbesluten) kan kopplas till effekter blir det lättare att ta rätt beslut – det vill säga de beslut som leder till mest nytta.

Det är inte helt lätt att definiera ”bra” effektmål. Alltså mål som kan styra teamet i rätt riktning, som teamet kan använda för att ta rätt beslut och lösa problem. Så hur ska man tänka? Så här tror jag:

  • Målen ska representera vad organisationen vill (till exempel ökad effektivitet hos medarbetarna) men man vill också att det ska ha en stark koppling till satsningen. Visst, ett Intranät kan bidra till att folk blir mer effektiva men medarbetarnas effektivitet beror ju också på så mycket annat. Till exempel arbetsledning och utformning av processer och rutiner. Bättre då att bli lite mer konkret och definiera hur Intranätet kan bidra till ökad effektivitet. Kanske genom ökad kommunikation mellan kollegor eller ökad kännedom om rutiner och processer.
  • Målen ska inte peka ut specifika lösningar, till exempel lättare att söka. Varför vill vi att det ska vara lättare att söka på Intranätet? Kanske för att det ska bli lättare att hitta, vilket kan bidra till ökad kännedomen om rutiner och processer. Sök är en lösning och det kan absolut finnas andra lösningar. Till exempel e-postnotifieringar när en rutin ändras.
  • Målen ska förstås också vara något som kan kopplas till nytta för organisationen, vilket oftast innebär en koppling till ökade intäkter eller minskade kostnader. Om det är få som idag använder Intranätet kan man frestas att sätta målet ökad användning. Men ökad användning i sig är inte något som kan kopplas till nyttan. Det kan ju till exempel bero på att det har blivit ännu svårare att hitta, man måste spendera mer tid på Intranätet för att komma åt de där rutinerna och processerna.
  • Det är också en klar fördel om målen är mätbara, så man vet när man har lyckats. När man måste sätta en siffra på målet blir det också mer konkret, till exempel 8 av 10 medarbetare har under en månad tagit del av någon rutin på Intranätet. När metoder för att mäta saknas får man förstås skapa sådana, till exempel genom förbättrad statistik eller enkätundersökningar.

Tips

Aligning UX Strategy with Business Goals på UXPA
Boken Impact Mapping
inUse:s kurs i effektstyrning

Skillnaden mellan tjänstedesign och UX design

På UX Open i höstas lyssnade jag på en föreläsning om vad som skiljer sig mellan en tjänstedesigner och en UX Designer. Jag blev förvirrad. Så jag ska försöka mig på en egen förklaring.

I ett projekt jag gjorde som konsult var jag ensam UX designer (eller ja, titeln hette Interaktionsdesigner). Det var ett nyutvecklingsprojekt och eftersom jag är van vid sådant körde jag direkt igång med att definiera effektmål och målgrupper, göra kundintervjuer, ta fram scenarios, koncept och designprinciper. Efter ett tag insåg jag, utan att någon sa något, att man inte hade förväntat sig att jag skulle ta den rollen. Man förväntade sig att jag snarare skulle jobba med gränssnittsdetaljer som huruvida OK-knappen ska ligga till vänster eller höger.

Jag tror projektet verkligen uppskattade att jag tog en större roll. Projektets kunskap om användarna var nämligen alldeles för liten. Och att jag kunde definiera ett övergripande koncept istället för att grotta ner mig i knapp-positioner gjorde att vi kunde se tjänsten som en helhet från början vilket underlättade planering och förankring.

UX design kan ske på olika nivåer, allt från en nitty-gritty pixelnivå till en strategisk nivå där man tar hänsyn till affärsmål, användarbeteenden och drivkrafter. För mig är den strategiska nivån i UX design fundamental. Det är snudd på omöjligt att göra ett bra jobb utan att på djupet förstå affären och användarnas beteenden, drivkrafter, problem och kontext (oberoende av lösning och ”kanaler”).

De som kallar sig tjänstedesigners betonar det här strategiska jobbet och får det ibland att låta som något unikt för tjänstedesign. Men utgångspunkten för en UX designer som jobbar strategiskt och en tjänstedesigner är, så vitt jag förstår, den samma. Förstå affären och användaren, oavsett lösning (digital eller inte). Ta fram koncept och utvärdera med användare.

En intressant skillnad är ”paketeringen” av tjänstedesign:

  • Tjänstedesigners pratar om kunder, inte användare. Kund är ett mer bekant begrepp för de flesta, speciellt höga beslutsfattare som är intresserade av affärsnytta. Det är ju kunderna man tjänar pengar på. Kund inkluderar också inaktiva kunder, som inte ”använder”. Men begreppet kund är också begränsande eftersom det inte inkluderar interna användare som ju också kan bidra till affärsnytta genom användning.
  • Tjänstedesigners jobbar alltid strategisk. UX design är som sagt ett väldigt brett begrepp som inte alltid betyder att man jobbar strategiskt (även om jag tycker att det borde göra det). Så när UX designern ofta är generalist och ska kunna ”allt” från affär till pixlar är tjänstedesignern specialiserad på de strategiska delarna.
  • Tjänstedesign är över huvud taget mer specifikt. Man vet vad man får. Man vet till och med vilken typ av leverabler man kan förvänta sig från en tjänstedesigner (upplevelsekartor).

När det kommer till designkoncept finns en viktig skillnad. Tjänstedesigners kan designa för alla typer av interaktioner, både digitala tjänster och icke-digitala möten som en reception eller ett kölappssystem. UX designern jobbar oftast bara med digitala koncept.

Gränsen mellan det fysiska och digitala suddas ut allt mer. Fysiska produkter blir allt mer digitala och det behövs människor som förstår båda världarna. Betyder det att ”strategiska” UX designers borde bli tjänstedesigners? Jag vet inte. Men jag vet att det är viktigt att vi både förstår vad andra gör och vår egen jobbtitel uppfattas. Annars hamnar vi i kommunikationsproblem. Därför har jag beställt den här boken om tjänstedesign. Hoppas den är bra. Och hoppas att diskussionen dyker upp igen på nästa UX Open den 24 oktober.

Lästips

Breaking up with the User in User Experience Strategy på UXMatters – Om en snarlik begreppsdiskussion på engelska, customer experience och user experience.

Adaptive Paths gratis e-bok Guide to Experience Mapping

Tjänstedesignbloggen – Transformator Designs blogg

Att skissa för hand

I förra veckan besöktes HiQ-kontoret av interaktionsdesignern Mårten Angner som pratade skissteknik (tack Mårten!), vi fick bland annat lära oss rita raka linjer och cirklar. Men kursen handlade också om fördelarna med att skissa för att bli mer effektiv i sin kommunikation.

Delad förståelse

En grupp personer sitter i ett möte och diskuterar ett komplicerat problem. Trots att alla är superkompetenta så lyckas man inte komma överens. Men plötsligt händer något. En av personerna går fram till whiteboarden och börjar rita. Plötsligt inser man att man egentligen inte var oense, det handlade bara om att man hade olika bild av problemet. Många känner nog igen situationen.

En bild gör i många lägen ett bättre jobb än ord eller text för att få en grupp människor att nå samförstånd. En bild säger ibland mer än tusen ord. Om vi som jobbar med att kommunicera komplexa idéer har närmare till skissblocket och pennan blir vi helt enkelt mer effektiva på att kommunicera. Men de riktigt bra effekterna uppstår om vi även kan få andra runt omkring att börja kommunicera visuellt. Det handlar om att skapa en miljö där alla känner att de kan och vill skissa för hand.

Så hur får man folk att börja skissa? Det finns nog flera sätt. Man kan, som Mårten, utbilda och inspirera folk i hur man skissar snyggt och begripligt. Man kan också försöka skapa en miljö där det inte är så viktigt att det ser snyggt ut, det handlar inte om hur utan om att man över huvud taget kommunicerar visuellt.

Fånga visionen

Ett IT-projekt börjar ofta med en idé eller vision om hur nytta kan skapas. Ofta är det någon eller några i ledningen som sitter på visionen, kanske en VD, marknadschef eller teknisk chef. Visionen ligger ofta på en hög nivå som ”vi måste ha ett nytt intranät” eller ”vi behöver en mobilanpassad webb” men det finns alltid också förväntningar och föreställningar om hur slutresultatet kommer bli, även om de inte är artikulerade.

Som interaktionsdesigner vill jag förstås vara den som gör jobbet och konkretiserar visionen till något som ger organisationen affärsnytta. Men det är också viktigt att det jag jobbar fram inte skiljer sig för mycket från beställarens förväntningar. Då kommer det bli svårt att förankra och jag kanske missar att tänka på någon viktig aspekt som gör slutprodukten nyttig. Mitt jobb blir alltså lättare om jag från början förstår förväntningarna.

Jag tror skissworkshops kan vara ett bra sätt att fånga visionen och förväntningarna. Samla ihop de från organisationen som känner starkast för projektet och som fattar besluten, desto bättre ju fler olika perspektiv som finns representerade. Låt alla rita hur de tror att resultatet kommer se ut, visa upp för resten av gruppen och diskutera hur olika skisser skiljer sig från varandra och varför.

Rita wireframes för hand eller digitalt

Som interaktionsdesigner tar man fram wireframes för att kommunicera hur ett gränssnitt ska fungera, se ut och kännas. Efter skisskursen har vi i HiQ:s UX-grupp pratat en del om att rita wireframes för hand kontra i ett digitalt verktyg som Balsamiq, Omnigraffle eller Axure.

Handritade wireframes kan vara lättare att få feedback på eftersom de inte ser lika slipade ut, även om man också kan få digitala wireframes att se handritade ut. Papper och penna är flexibelt, man begränsar sig inte till ett komponentbibliotek, och de uppmuntrar till samarbete, man behöver ju inte ha något visst program installerat på datorn för att kunna bidra till skissen.

Men digitalt producerade wireframes och prototyper har också fördelar. De är lättare att uppdatera, det går ofta t.ex. att ändra på hur sidfoten ser ut på alla sidor. De är lättare att sprida till folk som inte sitter på samma plats. Det är lättare att få en känsla för hur t.ex. en webbplats hänger ihop och fungerar när man kan klicka sig igenom en interaktiv prototyp. Användningstester blir också lättare att utföra och mer realistiska när den som testar faktiskt kan klicka på knapparna, inte bara säga var man skulle klicka.

Vad är bäst då? Självklart beror det på. Det absolut viktigaste att tänka på är syftet med de leverabler man tar fram. Hur ska de användas, för att kommunicera, samarbeta eller testa på användare? Vem är mottagaren? Hur ser arbetsprocessen ut? Kommunikationsvägarna? Vilka andra dokument kommer tas fram? Framför allt: Vad är det minsta möjliga jag kan producera för att nå syftet just nu? Vad blir mest effektivt?

Om man inte funderar på syftet med leverablerna eller hur man mest effektivt når dit, utan bara slentrianmässigt kör på i sitt favoritverktyg, blir det lätt att man lägger för mycket tid på att producera onödiga dokument som ingen kommer läsa. Det gäller så klart oavsett om man ritar skisser för hand eller tar fram avancerade digitala prototyper.

Vidare läsning

The messy art of UX sketching på Smashing mag

Introduction to Design Studio på UX Magazine

Design Studios: The good, the bad and the science på UX Booth

Design Studio and agile UX på UX Magazine

The big think: Breaking the deliverables habit på Samshing mag