Principer för hur jag vill jobba

En grej som är häftig med att jobba med UX/tjänstedesign är att ens arbetssätt hela tiden förbättras. Böcker och artiklar i alla ära, man kan lära sig en hel del av att läsa om häftiga och moderna buzzwords som Agile, Lean och Design thinking. Men inget går upp mot att göra jobbet, gå på nitar och göra det lite bättre nästa gång.

Så här kommer mina ”principer” för hur jag vill jobba. Lite pretto kanske men det får man leva med. Och situation spelar faktiskt ingen roll. De här principerna tror jag på oavsett om jag ska göra en superstrategisk förstudie för en stor myndighet eller en snabb expertutvärdering för en liten startup.

Vara transparent

Visa vad jag gör och uppmuntra andra att visa vad de gör. När saker (t.ex. design) blir synligt så uppstår informell kommunikation mellan människor, typ ”Aha! Ni jobbar också med den grejen, då borde vi ses och samarbeta”.

En annan sak som händer är att man blir granskad och ifrågasatt från nya håll. Man behöver ha stenkoll på designbeslut som tas för att kunna förklara för andra, och behöver kommunicera så alla (även folk utanför teamet) förstår. Man tvingas skärpa sig och bli lite proffsigare, helt enkelt.

Exempel

  • Lägga upp saker man gjort på slack, confluence, intranät och andra platser där folk kan se
  • Sätta upp visualiseringar på väggarna
  • Bjuda in till öppna regelbundna demos
  • Visa vad man planerar att jobba med, t.ex. lägga upp designaktiviteter i teamets backlog eller berätta på dagliga standups

Visualisera

Kommunikation är viktigt och visuella saker är lättare att ta till sig än text. UX- och UI-designers jobbar fortfarande mycket med wireframes. Sådana kan absolut vara bra men jag försöker ofta tänka ”hur kan jag kommunicera det här utan wireframes?”. Helt enkelt eftersom diskussionen jag vill ha sällan handlar om ”sidor”, ”vyer” eller ”komponenter”. Om jag använder olika sätt att visualisera blir det lättare för folk att förstå och det blir bättre diskussioner.

Exempel – några visualiseringssätt jag gillar

  • Effektkarta – visualisera vad organisationen vill, vad användaren vill och hur lösningen ska vara
  • User story map – visualisera hur en användare använder en tjänst steg-för-steg och vilka features som kan levereras steg-för-steg
  • Service blueprint/kundresa – visualisera vad användaren gör och hur användaren interagerar med olika tjänster, kanaloberoende
  • Spontanrita boxar och pilar på en whiteboard

Göra och förbättra, förbättra, förbättra

Det mest effektiva är oftast att sätta igång, ta fram något under hyfsat kort tid och förbättra det om och om igen. Det är annars lätt att hamna i analysis paralysis, speciellt för analytiska personer som jag själv.

Det gäller till exempel design. Tänka kommer alltid före göra. Vi behöver lägga tid på att förstå problemet och användarna innan vi kan göra design. Men vi får inte vara rädda för att släppa sargen, sluta analysera och börja trolla. Det blir lite skevt och lite fel till en början men det blir mer effektivt jämfört med om vi har en lång analysfas innan vi börjar ta fram något konkret. Det beror på flera saker. Vi tvingas involvera alla kompetenser, till exempel utvecklare, tidigt. Vi har något att visa upp för andra tidigt, vilket öppnar för tidig feedback från olika håll. Vi kan testa designen på användare tidigt via prototyper. Och vi kan till och med släppa en tidig version av tjänsten och få riktig feedback och data från riktig användning med riktiga användare. Det är oslagbart! Men det är förstås inte värt något om vi inte är öppna för att faktiskt göra (omfattande) förändringar när vi lär oss nya saker.

Exempel på saker att förbättra kontinuerligt

  • Tjänster och produkter – via prototyper eller tidiga releaser kombinerat med användningstester, dataanalys, enkäter
  • Kunskap om användare och kunders behov – via djupintervjuer, observationer
  • Hur teamet jobbar – via team-retrospektiv
  • Hur jag själv jobbar – via reflektion, skriva blogginlägg, bli coachad/coacha

Ha tydliga mål

Det är mycket svårt att göra rätt om man inte vet målet med det man gör. Det gäller det mesta, från möten till team eller produkter. Mötesdeltagare behöver veta målet med ett möte för att kunna bidra till det. Utvecklingsteam behöver tydliga effektmål för att kunna prioritera och bygga rätt saker, vilket jag skrivit om här.

Exempel

  • Ta fram effektmål för projekt/tjänster/team tillsammans med beslutsfattare
  • Ha mål med möten/workshops

Jobba tillsammans, tvärfunktionellt

Den typen av design jag oftast jobbar med är komplex och kräver olika människors input för att bli bra. Om olika kompetenser som designers, utvecklare, jurister, affärsutvecklare och andra jobbar tillsammans får alla en gemensam bild av problemen som ska lösas. Det är mer effektivt än att alla ska sitta vid sina respektive skrivbord och jobba med sina delar. Dessutom är det utvecklade. Utvecklare lär sig om designperspektivet, designers om juridik och så vidare. Alla ska inte vara generalister, men alla ska vara riktigt duktiga på något och kunna tillräckligt för att förstå alla andra perspektiv. Det brukar kallas T-formade team.

aaeaaqaaaaaaaak4aaaajdlhnjrlmtblltuzzjmtngqwyy05nti0ltnizguwzdi2zjywzg

Exempel

  • Skissworkshops med olika kompetenser representerade
  • Låta olika personer var med och lyssna på användarintervjuer eller observera användningstester
  • Analysera användarintervjuer genom att gå igenom anteckningar och göra affinity mapping tillsammans

Bidra till att skapa trygghet

I olika studier, till exempel hos Google, har man kommit fram till att trygghet är det viktigaste för att ett team ska bli effektivt. Människor som känner varandra, vågar säga vad de vill, göra vad de vill och vågar misslyckas jobbar bättre tillsammans.

Det tar tid att bygga upp trygghet i ett team. Därför bör man satsa på att inte splittra eller byta ut teamet för ofta. När jag spelar Dungeons and Dragons pratar vi ofta om att ”Never split the party”. Det slutar alltid med TPK.

Exempel på saker som bidrar till trygghet, mys och lära-känna

  • Vara transparent med vad man jobbar med och hur man jobbar
  • Berätta om sina misslyckanden
  • Erkänna när man inte vet något
  • Ge och ta emot feedback på ett snyggt sätt
  • Ge beröm och peppa
  • Lunchdejta folk

Tips

Det var nyttigt att skriva den här bloggposten! Jag tror alla skulle dra nytta av att formulera för sig själva hur de vill jobba.

Annonser

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