Gode verktøy for å sikre en god designprosess
I min tretten år lange karriere innen utvikling av digitale produkter har jeg kommet over mange verktøy som hjelper til i prosessen fra problem til løsning. Personlig liker jeg meg best i «problemland» fordi det ofte er utgangspunktet for å gjøre noe som helst.
Dette er verktøy som både hjelper med å samle egne tanker, samt kommunisere hva du har tenkt, slik at andre kan forstå hva du baler med og hvorfor. Her er noen av mine favoritter:
Designprosessen
Hele prosessen fra problem til løsning gjøres best med designprosessen. Designprosessen er hellig og går hånd i hånd med smidig utvikling. Den er egnet der løsningen er enkel å endre på i ettertid, for eksempel i utvikling av et digitalt produkt. Men den er ikke så godt egnet hvis du skal bygge en bro.
Designprosessen består hovedsakelig av 6 steg som du gjentar og gjentar og gjentar:
- Forstå dagens situasjon: Intervjuer, brukerundersøkelser eller tjenestesafari.
- Definer problemet: En tydelig problemstilling basert på punkt 1). Et problem er en uønsket tilstand som du vil endre.
- Se for deg hva som er ønsket situasjon: Designsprint eller andre typer workshops.
- Lag prototyper og andre «billige» løsninger, og test: Prototyper på papir eller digitale (eks. Sketch). Brukertest løsningene.
- Hvis prototypen valideres, implementer: Billig og rask implementering. Men må i noen tilfeller være nokså robust.
- Mål og evaluer: KPI (Key Performance Indicators), Net Promoter Score (NPS), fornøydhetsundersøkelser, brukertesting.
- Gjenta stegene 1 til 7.
Jeg har veldig sans for denne videoen av Stanford om tjenestedesign.
Kunnskap, løsning, utfall, feedback
Denne modellen er designprosessen sagt og vist på en litt annen måte, som kanskje kommuniserer bedre for enkelte.
Problemfortelling/behovsfortelling
Jo mer tid du bruker på spørsmålene hvorfor, hva, hvordan og når før du setter i gang med å tenke på løsninger, jo større sjanse har du for å lage noe som verden trenger.
Jeg har fornorsket og modifisert noe av innholdet i denne artikkelen for å komme fram til denne problemfortellingen.
Hvis du klarer å fylle ut tomrommene før du begynner å tenke løsning, så mener jeg du er på god vei til å lage noe knallbra. Det krever selvsagt mye av steg 1 og 2 i designprosessen.
For [målgruppen] er det en stor utfordring å [generell beskrivelse av problemet]. Hver [tidspunkt/tidsperiode] må disse folkene [beskrivelse av aktiviteten de gjør] slik at [hovedmålet de søker å oppnå]. Dette er spesielt sant hvis du er [beskrivelse av nisjemålgruppen].
Hovedproblemet de møter er [beskrivelse av det vanskeligste ved å utføre aktiviteten i dag], noe som fører til [beskrivelse av dårlige utfall som skjer]. I dag er deres beste alternativ å [beskriv hva de gjør i dag], men [beskrivelse av hvorfor de misliker dagens måte å gjøre dette]. Ettersom [beskrivelse av hva som kan gjøre problemet verre i fremtiden] vil problemet bli verre over tid.
Om det bare var en bedre måte for dem å [gjenta beskrivelsen av aktiviteten de gjør], så kunne disse folkene [beskriv den kvantifiserbare virkningen på hovedmålet]. Dette ville ført til [beskrivelse av positive utfall og følelser]. Med [antall potensielle kunder], så er dette en god mulighet for å påvirke livene deres på en god måte.
La oss ta et hypotetisk eksempel med elbiler og lading på farten:
For elbileiere er det en stor utfordring å lade bilen. Hver gang de er på langtur må disse folkene lade bilene sine slik at de kommer seg fram til destinasjonen. Dette er spesielt sant hvis du er eier av elbil med liten rekkevidde.
Hovedproblemet de møter er at ulike ladetilbydere har sine egne ladeløsninger i form av apper og stasjoner, noe som fører til knot med brukerkontoer og innlogging på ladeplassen. I dag er deres beste alternativ å laste ned alle apper de tror at de vil trenge og lage brukerkontoer for disse, men de blir svært forvirret over når de skal bruke hvilken app. Ettersom det stadig kommer nye aktører vil problemet bli verre over tid.
Om det bare var en bedre måte for dem å lade bilene sine på farten, så kunne disse folkene hatt mindre stress med ladingen og dermed kommet seg fram til destinasjonen på en avslappende måte. Dette ville ført til flere fornøyde elbil-sjåfører. Med 400.000 elbileiere i Norge i dag, så er dette en god mulighet for å påvirke livene deres på en god måte.
Hypotesekortene
Hypotesekortene består av tre kort: problemkort, testkort og læringskort. Disse skal du bruke når du tester løsninger på et gitt problem, og de kommuniserer godt. Kortene tvinger deg til å si noe om hva du håper på å oppnå ved å sette i gang et stykke arbeid.
Dette kan sammenfalle med stegene 3, 4 og 5 i designprosessen.
Kortene er basert på Alexander Osterwalders ideer.
Her følger et enkelt eksempel med råkjøring i et borettslag:
Utfall av løsning fremfor selve løsningen
Ok. Denne var litt lei å oversette. På engelsk heter det “outcome over output”. Det betyr at du må være minst like opptatt av utfallet av løsningen som du er av selve løsningen (og prosessen ved å lage den).
For eksempel, hvis du lager en app der brukerne kan melde inn steder der folk har kastet betydelige mengder avfall, så bør du være minst like opptatt av at avfallet fjernes (dette kan måles) som du er av at appen er fin, flott og brukervennlig.
Her finnes det en modell som kommuniserer godt, spesielt hvis du står overfor store problemer.
Takk for at du leste! Jeg setter stor pris på tilbakemeldinger om innholdet i artikkelen. Og husk å gi noen klapp hvis du likte den ;)
