Å lage den riktige tingen er vanskelig

Google Design Sprint er litt som designverdenens Duracell-kanin. Sprintmetodikken tar deg og teamet gjennom en hel designprosess på bare én uke.

Du trenger:

• 1 utfordring du ønsker å få løst

• 1 uke

• 1 tverrfaglig team

• 500 postit-lapper

• ∞ ideer (ta det med ro, de kommer!)

Ved slutten av uka har du plutselig:

• en testbar prototype, som du putter foran fem brukere i målgruppen

• en (forhåpentligvis) mer forent organisasjon – vi vet mer om hvem vi er, hva vi skal løse, hvor vi vil, og vi har endelig fått snakka sammen, på tvers av hverdagens og organisasjonskartets linjer. Dette er en gevinst i seg selv!

• Fått testet hypotesene du satt med, slik at du bedre kan forstå om retningen dere så for dere er et steg i riktig retning – eller kanskje en blindvei.

Min rolle

• Sprint-fasilitator: En hel uke som workshop-leder, hvor jeg sammen med en kollega guidet teamet gjennom sprintmetodikken og sørget for å opprettholde fokus og motivasjon i teamet.

• Planlegge, koordinere og gjennomføre designsprinten. Dette innebærer alt fra å selge inn sprintkonseptet i organisasjonen og tenke på hvordan sprinten skal vinkles, til å sørge for rekruttering av deltagere og testdeltagere, samt ordne med praktikaliteter som lokaler og mat.

• Jeg deltok også inn i teamet som “bonusdesigner” og hjalp til med utforming av prototypen.

Utfordringen

Utfordringen startet med Truls.

Det vil si, det begynte med en student, men vi har kalt ham Truls. Truls er basert på flere kilder, blant annet funnene i masteroppgaven min.

Truls studerer ved Universitetet i Oslo, som er et mangfoldig sted, også når det kommer til hvilke systemer som brukes og hvordan undervisere og administrasjonen kommuniserer med studentene. Den akademiske friheten står sterkt, og foreleserne står i stor grad fritt til å velge hvordan de vil legge opp sin undervisning og hvordan de deler informasjon med studentene. Fleksibilitet for foreleseren betyr fort utfordringer for Truls, som tar flere kurs og må forholde seg til emne- og semestersider, innleveringssystemet Devilry, kommunikasjonsplattformen Piazza, ymse bloggløsninger, Canvas eller andre læringsplattformer. Noen forelesere sender informasjon til studentens e-postadresse, andre deler av UiO kan benytte Truls sin private e-postadresse eller SMS. Noen ganger kommer informasjonen i form av en lapp på en fysisk tavle. Truls er ikke imponert.

Oppgaven vår ble å finne ut hva den mystiske sorte boksen inneholder; hva må til for å snu Truls sin opplevelse fra nedtur til opptur? Hva kreves egentlig for at studentene skal få en god oversikt over studiehverdagen sin?

Fragmentert studenthverdag møter fragmentert ansatthverdag

Det er imidlertid vanskelig å løse et problem om fragmenterte informasjonskanaler når man selv sitter spredt, geografisk og i tid, og bare ser sin lille bit av verdenen der ute.

Noen forsøk hadde allerede vært gjort, eller blitt startet, og siden stoppet. En del tanker var tenkt gjennom årene, men historikk og delte meninger kom i veien. I mellomtiden fortsatte antall kanaler og tjenester å vokse. Innspill til mulige løsninger møtte fort miner om at «dette har vi prøvd å få til før».

Så hva gjør du når ideene du og UX-kollegaen din legger fram oppfattes som gammelt nytt? Du griper muligheten og selger inn Google sitt rammeverk for idéutvikling og rask innovasjon. Glem avleggs ideer, la oss lage nye, sammen! Glem «prøvd dette før» – dette har ingen av oss gjort tidligere!

Vi trengte kontinuitet i arbeidet, fokus, fremdrift og forente visjoner. Vi trengte et tverrfaglig team.

Enter Google Design Sprint

Kort og tørt om metoden: Google Design Sprint er en femdagers prosess der målet er å finne svar på en større problemstilling ved hjelp av problemkartlegging, idégenerering, prototyping og brukertesting. For å få til dette samler man et tverrfaglig team som jobber fokusert sammen i én uke, fra mandag til fredag. Prosessen er tidsstyrt med lite rom for lange diskusjoner, og man beveger seg raskt fra problem til å teste om konseptet man har utviklet har livets rett. Etter fem dager har teamet en realistisk prototype som er testet med fem brukere i målgruppen.

For den energiske, amerikanske varianten, se denne videoen fra Jake Knapp, mannen bak designsprint-metodikken:

Å bygge team som kan bygge ting

Før vi kunne bygge ting måtte vi bygge team. Invitasjoner ble sendt ut bredt, kontorer ble oppsøkt, informasjon spredt fra ledere og nedover og bortover. Vi ville nå ut til folka som kunne hjelpe oss å forstå ulike sider av problemet, fra de som utformer studentinformasjon på nett til de på IT-support og studentinfosentrene, som møter studentenes spørsmål hver eneste dag. Vi kunne ikke holde en sprint om studenthverdagen uten å involvere en student, og var så heldige å få rekruttere en fra studentparlamentet som brant for problemstillingen.   

Systemmangfoldet på UiO er stort, så vi passet på å få med noen med teknisk innsikt og systemforståelse. UX-kompetanse måtte også med (det er mye man rekker i løpet av en torsdag, men teamet har nok press på seg om de ikke skal lære seg prototyping fra skrætsj i tillegg).  

Beslutningstageren viste seg å være den vanskeligste brikken. Én person i teamet får makten til å ta de endelige avgjørelsene; hvilken målgruppe skal vi fokusere på, hvilken del av problemet skal vi sirkle oss inn mot, hvilken idé skal løftes videre fra skisse til prototype til test med brukere?

Ikke bare har Beslutningstageren makt i sprinten; vi er avhengige av at personen er i posisjon til å følge opp funnene fra sprinten og ta arbeidet videre i organisasjonen. I en stor og heterogen institusjon som et universitet er det få som har den makten. Mange har derimot mulighet til å kaste stein i vannet og skape uro rundt det videre arbeidet dersom de skulle føle seg forbigått. Vi ville gjøre vårt beste for å unngå en slik situasjon.

Valget falt til slutt på lederen for Prosjekt digitalt læringsmiljø, som allerede hadde fått tillit fra organisasjonen til å jobbe med nærliggende problemstillinger. Vi ønsket også at IT-organisasjonen skulle føle eierskap til sprinten og resultatene, og fikk direktøren for Brukernære tjenester med i arbeidet.

Lynversjon av sprinten

Dag 1

Mandag handler om å finne mål og mening. Vi kartlegger problemet, holder “ekspertrunden” hvor teamdeltagere og andre utenfra deler sin kunnskap om problemet, identifiserer risikomomenter og bestemmer fokus for resten av uka.

Min favorittøvelse fra denne dagen er “How might we”-teknikken: Vi forestiller oss at vi er 2 år fram i tid og at prosjektet har feilet. Hva gikk galt? Etter å ha laget verdens mest nedtrykkende liste bruker vi HMW-teknikken for å snu risiko til mulighet. Eksempelvis snur vi frykten “studentene vet ikke at løsningen vår finnes” til spørsmålet “hvordan kan vi sørge for at studentene får vite om løsningen vår?”. En liste av negativitet er lammende; en liste av spørsmål å undersøke skaper nysgjerrighet!

Dag 2

Jeg liker å kalle tirsdag for legodagen: vi starter dagen med å samle og presentere biter av inspirasjon, før alle plukker med seg bitene de liker best og jobber hver for seg med å sette dem sammen til nye ideer. Strukturerte aktiviteter hjelper deltagerne å gå fra stikkord til skisser til konseptforslag. Ved slutten av dagen leverer hver deltager sitt konsept for løsning.

Ikke alle er like komfortable med å skisse. For å varme opp teamet vårt valgte vi å legge inn et fem-minutters minikurs hvor vi viste teamet vårt hvordan de kan bygge opp grensesnitt av enkle bokser og former, i tillegg til nyttige ikoner og interaksjonstyper. Ved siden av inspirasjonsgalleriet vårt ga dette deltagerne et godt utgangspunkt for dagen.

Dag 3

Valgets kval: hvilket løsningsforslag tar vi videre?

Vi starter dagen med gallerirunden, hvor alle får vandre rundt i stillhet og gjøre seg opp en mening om løsningsforslagene. Deltagerne får utdelt små klistremerker de setter på de mest interessante delene av løsningsforslagene, slik at klistremerkene sammen danner “varmekart” som viser hva teamet synes virket mest spennende. Vi er gjennom flere stemmeprosesser denne dagen, før Beslutningstageren gjør sitt valg. Vinnerskissen jobbes ut videre i plenum til et storyboard som viser flyten i prototypen.

Dag 4

Magiens dag, hvor skissene kommer til live som en virkelighetsnær prototype. Teamet deles opp i forskjellige roller med ulike oppgaver for kunne jobbe så effektivt som mulig.

Google anbefaler at du skaper en så virkelighetsnær prototype som mulig for å skape en illusjon av at det er et ekte produkt. Vi satte sammen prototypen vår i Sketch, som gir en realistisk utforming og semi-realistisk oppførsel. I dag ville jeg nok heller brukt Figma, som har bedre støtte for animasjoner og overganger.

Dag 5

Fredag handler om å teste og lære. Gjennom fem brukertester med brukere i målgruppen får man tilbakemelding på ideen og et inntrykk av hvor godt løsningsforslaget treffer.

En deltager stiller som testleder, og har på forhånd laget et manus med testoppgaver og spørsmål han vil stille testdeltageren (en bruker i målgruppen). Testdeltageren blir bedt om å tenke høyt mens hun klikker seg rundt i prototypen, og får beskjed om å ikke være redd for å si ifra hvis hun ser noe hun synes er uklart eller mindre bra. 

Mens brukerne testet prototypen, tar resten av teamet notater. Vi rigget til et observatørrom i underetasjen, hvor teamet fikk live-overføring av skjermen til testdeltageren, samt videooverføring fra testrommet. Teamet ble bedt om å skrive ned sitater og observasjoner på gule lapper, og markere med pluss- og minussymbol om utsagnet var positivt eller negativt. Når hele teamet tar notater blir alle mer aktive lyttere, og det er lettere å få med seg flere detaljer. Observasjonene ble på slutten av dagen ført inn i en resultattabell hvor man enkelt kunne se hvordan deltagerne responderte på de ulike delene av prototypen.

Hva lærte jeg

• Det er lov å tenke stort. Tror du at du ikke vil få lov til å gjennomføre en sprint, at det er for langt unna hvordan dere jobber? Prøv likevel! Fortell de som stritter imot at den lille uka dere legger inn her erstatter arbeid som fort ville vært spredt utover flere måneder; dere jobber raskere, mer fokusert og tverrfaglig; dere får i fellesskap pløyd gjennom ideer dere ikke hadde tenkt på og validert den dere har mest tro på, alt i løpet av noen dager. Google Design Sprint er også en super mulighet til å spre designtenking til andre deler av organisasjonen! Fordi det på mange virker “radikalt” å renske timeplanen for en uke, vil sprinten automatisk få oppmerksomhet. Når sprinten er ferdig kan du dra på turné i organisasjonen og spre det glade designbudskap videre.

• Forankring er alt. Og i en stor og allsidig organisasjon som Universitetet i Oslo er det utfordrende å få det til. Selv om du informerer flere måneder i forveien og møter opp personlig for å overbevise nøkkelpersoner om å delta, er det ikke sikkert vedkommende har mulighet. En kalenderuke er et krevende dyr, og det er forståelig at de som trekker i trådene ikke har mulighet til å delta. Problemet oppstår når de i ettertid ikke føler eierskap til resultatet av sprinten og resultatene havner i en skuff. Er du sikker på at du har kommunisert klart og tydelig hvor betydningsfullt nøkkelpersonens bidrag er for det videre arbeidet? Har du formidlet at personen de velger å sende i stedet må få samme beslutningsmyndighet som nøkkelpersonen? Er du trygg på at de faktisk er inneforstått med disse premissene? Sjekk en gang til, for sprintens skyld, og din egen.

• Vær forsiktig med å la folk delta kun deler av uka. Dette kan være demotiverende for resten av teamet, og det kan bli vanskelig for personen å henge med på hva som er blitt gjort. Dette blir spesielt utfordrende hvis personen er sentral for forankring av resultatet.

• En videreutvikling av metodikken, gjort etter at Sprint-boka ble utgitt (2016), har komprimert prosessen ned til fire dager, hovedsakelig ved å slå sammen mandag og tirsdag. Å selge inn fire dager er enklere enn å selge inn fem, og om fremgangsmåten oppleves mer “kompakt” eller sammenhengende i tillegg, er det bare en bonus. Verdt å sjekke ut!