Resor till verkligheten

Vad är designmognad?

Jag brukar tänka att designmognad består av två delar; förståelse för vad design är och förmågan att omsätta designprocesser i sitt dagliga arbete.

Ett företag med hög designmognad karakteriseras framför allt av ett arbetssätt där användarcentrerade designmetoder blivit en naturlig del av vardagen för så väl designers som andra yrkeskategorier. I ett företag med låg designmognad är det inte alls säkert att det finns en designfunktion, men om företaget har designers jobbar de ofta med att producera skisser utifrån "toppbeställda" kravspecifikationer.

Varför ser det ut så i företag med låg designmognad?

För en person som inte funderat så himla mycket på design är det intutivt att sätta ett likhetstecken mellan design och skisser. Från det perspektivet blir det logiskt att tänka att snygga skisser är samma sak som bra design. Det är fel!

De skisser som en designer producerar kan snarare beskrivas som kommunikationsverktyg som användas för att öppna upp olika typer av dialoger, exempelvis: "Har jag tolkat dina behov rätt?", "Så här har jag tänkt, vad tycker du om det?", "Kan ni bygga det här eller behöver jag tänka om?".

Vad är bra design?

På ett företag med hög designmognad ser det annorlunda ut. Här har man en annan bild av vad design är. En typisk definition kan se ut som nedan.

Bra design är en lösning som:

• Löser människors faktiska behov,
• Är enkel för människor att förstå och använda,
• Introducerar minimalt med nya friktioner i människors liv,
• Genererar så pass mycket värde att människor kan tänka sig att betala priset för lösningen.

Det är en pragmatisk definition som sätter människor i centrum, men som också erkänner affären. Den viktigaste aspekten är hur man utvärderar design utifrån en sådan definition. Här finns inget direkt värde i att uttala sig om skissers estetiska karaktär. I stället behövs användarcentrerade metoder och affärsmått och således blir dessa naturliga delar av arbetssättet.

Rikta om strålkastaren

Läser man föregående kapitel är det kanske lätt att dra slutsatsen att allt man behöver göra för att öka designmognaden är att predika om vad design faktiskt är. Men min erfarenhet är att teori är fel väg att gå. Det flödar redan så många teorier, hypoteser och modeller mellan kontorsväggarna att det blir information overload!

Ett bättre sätt är i stället att rent praktiskt rikta strålkastaren bort från skisserna och mot de faktiska användarna. Det gör du bäst genom att så ofta som möjligt bjuda med dina kollegor på resor till verkligheten.

Här är några exempel på hur det kan se ut.

När du presenterar skisser

Skisser är inte dåliga leverabler. Faktum är att de är otroligt greppbara och användbara när de används på rätt sätt. När du visar skisser är det bra om detaljnivån är så låg som möjligt, men ändå tillräckligt hög för att rätt dialog ska uppstå. Wireframes är din vän!

Men den kanske viktigaste aspekten är hur du pratar kring dina skisser. Om du vill kommunicera designbeslut med hjälp av skisser, så berätta utifrån användarnas behov och perspektiv. I stället för "På den här sidan har jag tänkt att vi lägger X, och så kan man göra Y" så kan du berätta att "När vi pratade med våra kunder berättade de att det var krångligt att göra Y utan att ha koll på X. Därför tänker vi en sida där vi samlar X och Y på samma ställe".

Användningstester

Ännu bättre än att du förklarar användarnas behov och perspektiv är att dina kollegor får informationen direkt från källan. Det är mer effektivt när det kommer till att bygga empati, och du slipper bli "den jobbiga designern som dyker upp och berättar vad som är fel".

Se därför till att alltid bjuda med en kollega när du gör användningstester. Kollegan kan ta anteckningar så har den en naturlig roll att fokusera på. Var också tydlig mot kollegan att ett användningstest inte är rätt tillfälle att försvara och förklara och att det är bättre för processen att du hanterar dialogen med användaren så mycket som möjligt.

Hackathon

Många organisationer arbetar med agila ramverk. Då brukar det finnas inbyggd "tid för innovation", och det är inte helt ovanligt att utvecklare genomför hackathons under den tiden. Jag skulle dock hävda att det som är ovanligt är att dessa hackathons är användarcentrerade. Lösningsperspektivet är i stället ofta ny teknik. Det är helt okej. Som utvecklare behöver man ibland få leka med nya tekniker för att utvecklas och känna sig inspirerad.

Men ofta kan det finnas flera spår under ett hackathon och här kan du ta ansvar för ett av dessa spår. I ditt spår bjuder du in användare som får stå i centrum. Typiskt bra uppgifter som de kan hjälpa till med är att:

• Definiera ett problem som de skulle vilja ha löst,
• Ge kontext till lösningsrymden genom att beskriva sin användning,
• Ge feedback på de lösningar som hackas fram.

Bonus – Kollaborativ design

I stället för att "göra all design själv" kan du facilitera kollaborativa metoder som designsprintar eller designstudios där du tar hjälp av dina kollegor för att lösa ett problem.

Många av dina kollegor kommer att säga saker i stil med ”bara så du vet så kan min treåriga dotter rita bättre än mig”, vilket du nu vet att du ska tolka som ”eftersom jag inte är duktig på att rita så kommer mina skisser se fula ut och det är ju dålig design”. Vips så har du fått en möjlighet att rikta strålkastarna bort från skisserna genom att säga att det absolut inte spelar någon roll!

Avslutningsvis

Om du bara ska ta med dig ett råd på din designmognadsresa så är det följande: Om ditt mål är att hjälpa till att öka designmognaden där du arbetar, så är ett praktiskt angreppssätt bättre än teori. Det gäller egentligen all förändring. Ingen blir gitarrvirtuos av att höra någon mala på om musikteori. Skippa därför Design Thinking-utbildningarna till förmån för att så ofta som möjligt bjuda med dina kollegor att träffa livs levande användare!