Folk aner ikke hva de vil ha — derfor må du prototype

Med optimisme og litt harehjerte — jeg føler meg kanskje litt som denne karen hver gang interaksjonsdesigneren og jeg snekrer sammen en prototype som vi vet vil legge grunnlaget for viktige veivalg videre i prosjektet.

Når du skal skape noe helt nytt må du innovere. For å innovere må du prøve og feile. For å prøve og feile må du ha flere alternativer å utforske. Derfor må du prototype og teste. Igjen og igjen og igjen. Det er kanskje dyrt, men konsekvensen av å ikke gjøre det er dyrere.

I innovasjons- og digitaliseringsprosjekter — hvor det er vanskelig å definere et tydelig målbilde — er usikkerhetene rundt relevant funksjonalitet stor. Brukere har problemer med å sette ord på hva de ønsker seg før de faktisk har det i hånden. Det er grunnen til at team bør prototype og teste flere alternative forslag til løsning før de tar en beslutning.

Illustrasjonen viser hvordan mange team kun tester og utforsker én funksjonell retning, som så viser seg å være feil veivalg — etter launch.

Hvis team og produkteier allerede har bestemt seg for funksjon X forhånd —hva er da poenget med å prototype?

Folk aner ikke hva de vil ha

Visste du for eksempel at du ville ha ansiktsfiltre i Snapchat før det faktisk var på plass i telefonen din? Eller mulighet til å hoppe over hver episode-intro når du binger en hel sesong av Godless på Netflix?

Dette er ikke funksjonalitet Snapchat og Netflix har kastet inn i tjenestene sine som en ettertanke, men et resultat av flere prototyper, testing og deretter beslutninger. Poenget mitt er: Brukere vet ikke alltid hva de vil ha før de sitter med det i hendene.

Se for deg at du demonstrerer funksjon X til en fokusgruppe. Du og teamet mottar positive tilbakemeldinger fra fokusgruppen og beslutter derfor å ta funksjonaliteten videre til design og programmering.

Siden fokusgruppen aldri fikk se alternativene Y og Z, hvordan kan du vite at det ikke var disse som markedet egentlig ønsket seg?

Etter å ha gått på både smeller og seire har jeg erfart hva som kjennetegner en god prototype:

• En prototype skal hjelpe teamet med å velge den beste funksjonaliteten blant flere mulige alternativer — gjennom fokusgrupper, brukertester eller uformelle tester internt i teamet.
• En prototype skal muliggjøre kvalitative brukertester slik at vi tidlig kan fange opp logiske brister, dårlig brukeropplevelse eller funksjonalitet som brukeren rett og slett ikke vil ha.
• En prototype må være realistisk for brukeren, men kan gjerne være sydd sammen med “hyssing og gaffateip” under panseret.
• En (god og klikkbar) prototype kan si mer enn tusen ord i Confluence.
• En prototype kan minimere misforståelser og bygge bro mellom varierende begrepsbruk mellom fagfeltene i teamet.
• En prototype skal gi ikke-tekniske besluttningstakere en bedre forståelse av konsekvenser rundt konkrete veivalg og avgjørelser, spesielt målt opp mot forretningsmålene som produktet bygger på.

Eksempler på hva en prototype ikke er

• En prototype er ikke «versjon 0.1 av appen vår» som en prosjektleder sa til meg en gang. (Han er en veldig flink prosjektleder, altså! 🤗)
• Det er ikke en MVP (Minimum Viable Product — et prinsipp for tidlig lansering av en app eller tjeneste i markedet for deretter å måle og videreutvikle)
• Det er ikke håndtegnede skisser i lange papirremser som er spredt utover bordet.
• Det er absolutt ikke design eller kode som kan gjenbrukes i produksjon. (Se punktet om “hyssing og duct tape” lenger opp.)
• Det er ikke bevismateriale som lages i etterkant av at beslutningen om funksjonalitet er tatt. Eller en slags reverse engineering om du vil.
• Det er ikke et verktøy som er ment å gi teamet en falsk følelse av fremskritt og gjennom dagesvis med klipp og lim. Selv om det er moro! 💸

“Falsk Følelse av Fremskritt” — Dagens allitterasjon

Prototyper må være raske

I en normal Design Sprint har du kun én dag på deg, men en mer detaljert prototype tar selvsagt lengre tid. Uansett — forsøk å ikke gnikke og gnu for lenge på detaljene.

Grunnen til dette er at jo mer tid du bruker på en idé, desto mer knyttet blir du til denne ideen og desto vanskeligere blir det dermed å forkaste den til fordel for noe bedre. Lag et par raske prototype-alternativer, test de på brukere eller internt i teamet for å skaffe deg innsikt og gå deretter videre videre!

…men samtidig troverdig.

Håndtegnede skisser (lo-fi prototyping) er naturlige første steg i en prototypeprosess, men brukertesting i form av papirskisser og teipbiter har liten verdi.

Confession time: Jeg har selv jobbet med kreative og artige prototypeløsninger som innebærer lange papirremser stukket inn i en pappeske for å simulere en skjerm. Til overmål tusjet vi på en en hjemknapp i bunnen i et forsøk på å øke «følelsen av telefon». Det var en gøyal klipp-og-lim-øvelse som ga både team og oppdragsgiver en følelse av at produktet begynte å ta form, men utover dét viste verdien seg å være begrenset.

Årsaken til dette er at vi mennesker i stor grad lar oss påvirke av det kontekstuelle. I psykologi kalles det context affect, og antyder at måten vi oppfatter innhold eller budskap påvirkes av omgivelsene rundt budskapet.

Prototyping bør vises direkte på den flaten som produktet til slutt skal leve, f.eks. som her i Napkin. Kilde: InvisionApp.com

Dette er grunnen til at er vanskelig å forholde seg detaljert til designskisser for en mobilapp hvis de presenteres på en stor 70 tommer skjerm som henger 4 meter unna deg i et møterom. Eller en pappeske-telefon utstyrt med lang papirstrimmel-skjerm, sveiv på siden og tusjet hjem-knapp. 🙈

Derfor: Vis og test prototypen på den skjermflaten og enheten den er ment for, enten det er telefon, nettbrett eller en større skjerm.

Prototyper skal brukes og kastes

Prototyper er et verktøy i beslutningsprosesser og ikke et mål i seg selv. Når beslutningen er tatt kastes selve prototypen mer eller mindre ut av vinduet, men teamet sitter igjen med innsikt og kunnskap som gjør det lettere å ta velfunderte beslutninger og veivalg.

“Skal vi bruke 200 timer på å prototype og teste nå, eller 600 timer på å endre funksjonalitet etter lansering fordi brukerene viste seg å ikke forstå produktet?”

Involvering av hele teamet

Jeg nevnte tidligere at brobygging innad i team kan være en positiv bieffekt av prototyper. Fagområder i et team har både forskjellig begrepsapparat og jobber med forskjellige deler av produktet i det daglige, og prototyper (spesielt de klikkbare) gjør det lettere for alle teammedlem å ta et steg tilbake og se helheten. I tillegg bygger den begrepsmessig bro i diskusjoner hvor fagfelt har en tendens til å snakke forbi hverandre inntil de har fungerende kode som kan demonstreres.

Sett i en helhet

I denne artikkelen har jeg skrevet om prototyping som en frittstående og uavhengig øvelse, men i realiteten er prototyper ett av mange verktøy i design- og tjenesteprosesser hvor definerte øvelser og metoder hjelper teamet med å navigere og problemløse seg frem til gode funksjoner og tjenester. Eksempel på slike prosesser og strategier er rapid prototyping, design sprint og design thinking. Noen nevnt, noen glemt.

Mange mener at det viktigste er å få funksjonalitet ut til markedet så raskt som mulig og deretter lære av tilbakemeldinger i etterkant. Det er en klok strategi som flere team burde sikte etter, men ikke uten at de store retningsvalgene er tatt på forhånd gjennom god prototyping og innsiktsbygging!

Derfor:

Uansett hvilken prosess og metodikk som teamet ditt velger, bruk tid på å prototype riktig slik at dere kan skape dere en god forståelse av den foreløpig beste løsningen. Det øker sjansen for at dere lager ting som folk vil ha — selv om dere selvsagt må lære og justere også etter launch.

Likte du artikkelen, eller er du lynende uenig? Gi meg et par klapp eller skriv en kommentar — det er diskusjoner og ulike meninger som gjør Medium så lærerikt! 😀

Har du lyst på nye utfordringer? Se våre ledige stillinger her