Jobba tvärfunktionellt och fokuserat

Förstå problem, ta fram lösningar och testa sig fram till vad som funkar bäst. Inte bara gissa utan använda en liiite mer vetenskaplig approach när man tar fram tjänster. Och göra det tillsammans med användare och olika kompetenser i tvärfunktionella team. Det här är ju liksom vad en bra designer gör.

Att få till ett (lagom) högt tempo i allt det här är inte alltid lätt. Teammedlemmar kan vara uppbokade i olika möten eller, gud förbjude, jobba i flera team parallellt. Viktiga människor utanför teamet, som olika beslutsfattare eller folk från andra team, kan vara extra svåra att få loss tid att samarbeta med.

Jobba fokuserat i längre pass

I ett team jag jobbade i nyligen var det här extra klurigt pga flera parallella projekt. Lösningen blev att vi långt i förväg bokade in heldagar där vi samarbetade fokuserat. Dagen började alltid med att vi började stort och brett med en recap. Vad var målet med vår tjänst nu igen? Vad vet vi om målgrupperna? Vi reviderade också de modeller vi hade. En effektkarta som beskrev mål och målgrupper. En User Story Map som beskrev användarens aktiviteter i och utanför tjänsten. Sedan gick vi igenom de senaste resultaten från våra utvärderingar (användningstester) och formulerade på post-its vilka förbättringar vi ville göra av designen. Till sist skissade vi tillsammans på en förbättrad version, först individuellt på papper och sedan tillsammans på en whiteboard.

Det här upplägget blev jäkligt bra (fast det underlättade i och för sig att människorna i teamet var awesome). Att vi satt fokuserat en hel dag gjorde oss effektivare jämfört med att jobba tillsammans lite då och då. Det gjorde också att vi inte glömde bort vårt mål eller att uppdatera vår effektkarta och story map. Om man bara jobbar på med olika detaljer i lösningen och träffas någon timme i taget finns det en risk att man glömmer att tänka ordentligt på de där övergripande sakerna.

Tips från boken Sprint

Design sprints är en metod där man under en vecka fokuserat tar sig an ett problem, tar fram en lösning och testar med användare. Min kompis Eric har beskrivit vad det handlar om på ett bra sätt så jag struntar i det. Men jag läste boken Sprint nyligen och tänkte lista några bra idéer och tips därifrån som man kan använda i tvärfunktionellt designarbete, oavsett om det sker i en veckosprint eller inte:

  • Fokus och förberedelse. Bestäm dagar och tider. Ha som regel att inte använda telefoner och datorer för något annat är själva uppgiften ni ska lösa.
  • Ha alltid en person som har mandat att fatta beslut. Det betyder inte en diktator, alla i teamet ska få säga sitt men när ni är oense ska det finnas någon som kan peka ut en riktning.
  • Börja med att komma överens om ett långsiktigt mål och vilka frågor ni vill ha svar på.
  • Ta fram en visualisering av vilka aktiviteter användarna gör. Det underlättar kommunikationen något enormt. Jag gillar User Story Maps.
  • Formulera problem och möjligheter som ”How Might We…?”. Ett standardsätt att formulera sig på, helt enkelt. Vilket gör det enklare att jämföra och gruppera. Just den här formen är också positiv och progressiv. Formuleringen ”Hur kan vi få fler att förstå formuläret?” blir mer kreativ än ”Folk förstår inte formuläret”.
  • Kolla runt efter hur andra företag löser liknande problem och dokumentera intressanta delar genom att göra små enkla skisser.
  • När ni är överens om mål och har förstått problemet ur olika perspektiv, låt alla teammedlemmar skissa en lösning individuellt. Boken beskriver en steg-för-steg-skissning i fyra steg som jag inte går in på här, skulle gärna vilja testa den. När alla har skissat sin lösning sätts lösningarna upp på väggen anonymt och alla får diskutera för/nackdelar och markera vilka delar som är intressanta.
  • Det mesta kan snabbt göras till en enkel prototyp med god organisation och lite underfundighet. Ge alla i teamet en tydlig och avgränsad roll. Rollerna i boken heter Maker (bygga/designa), Stitcher (hålla ihop allting), Writer (copy), Asset collector (hitta lämpliga ikoner, bilder m.m.) och Interviewer (håller intervju med användare, förbereder underlag).

Jag rekommenderar alla att läsa boken! Skönt att läsa en så konkret beskrivning av hur en designprocess kan se ut.

Annonser

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.

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:

 

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.