Det er lett å se på prototyping som en omvei. Du vet hva du vil bygge, utviklerne er klare, og hver uke brukt på skisser føles som en uke uten framdrift. Likevel er prototypen den billigste anledningen du får til å oppdage at du tar feil.
En endring i en prototype tar minutter. Den samme endringen i ferdig kode, etter at databasen er satt opp og skjermbildene er bygget, tar dager. Forskjellen blir ikke mindre av at prosjektet haster.
Hva en prototype egentlig er
En prototype er en versjon av produktet som ser og oppfører seg som det ekte, men som ikke har noe bak seg. Knappene virker, skjermbildene henger sammen, og du kan klikke deg gjennom en hel oppgave fra start til slutt. Under overflaten finnes det ingen database, ingen innlogging og ingen logikk. Alt er kulisser.
Det er nettopp derfor den er nyttig. Fordi ingenting er bygget ordentlig, koster det ingenting å kaste det. Du kan prøve tre ulike måter å løse det samme problemet på i løpet av en formiddag, og la dem som skal bruke løsningen fortelle deg hvilken som gir mening.
De tre nivåene, og når hvert av dem lønner seg
Ikke alle prototyper trenger å være like ferdige. Valget handler om hva du vil finne ut.
Den enkleste formen er skisser, ofte kalt wireframes. Grå bokser, ingen farger, ingen bilder. Her svarer du på om informasjonen ligger i riktig rekkefølge og om brukeren skjønner hvor hen skal gå videre. Dette er raskt, og fordi det ser åpenbart uferdig ut, tør folk å si det de mener. En polert skjerm får folk til å kommentere fargevalg. En grå boks får dem til å kommentere strukturen, som er det du faktisk lurer på.
Neste nivå er den klikkbare prototypen med ekte design. Riktige farger, typografi, ikoner og bilder, koblet sammen så det kan navigeres. Nå tester du om produktet oppleves riktig, om det henger sammen visuelt, og om det ser ut som noe folk vil bruke. Det er også denne varianten du viser fram til investorer, styret eller potensielle kunder, fordi den er nær nok det ferdige produktet til å være troverdig.
Den mest omfattende varianten legger inn realistisk innhold og tilstander. Hva skjer når lista er tom? Når nettet faller ut? Når passordet er feil? Disse tilfellene er de som tar lengst tid i utviklingen og som oftest blir glemt i planleggingen. Å tenke gjennom dem i en prototype er langt rimeligere enn å oppdage dem underveis.
Hva testingen faktisk avdekker
Du trenger ikke mange testpersoner. Fem til åtte personer fra målgruppen avdekker de fleste alvorlige problemene, og de neste tjue vil stort sett bekrefte det de fem første fortalte deg.
Det viktigste rådet er å holde munn mens de prøver. Gi dem en oppgave, for eksempel å registrere seg og legge inn den første oppføringen, og la dem gjøre det uten hjelp. Idet du forklarer hvordan noe fungerer, har du ødelagt testen. Poenget er å se hvor de nøler, hva de trykker på som ikke er en knapp, og hvilket ord de leter etter som ikke står der.
Det er sjelden de store tingene som feiler. Konseptet er som regel greit. Det som feiler er at knappen heter noe annet enn det folk kaller handlingen, at et viktig valg er gjemt bak en meny, eller at rekkefølgen på to steg er motsatt av hvordan folk tenker. Slikt er umulig å resonnere seg fram til ved et møtebord, og åpenbart etter tjue minutter med en ekte bruker.
Når du kan hoppe over det
Prototyping er ikke gratis, og det er ikke alltid riktig valg.
Bygger du noe lite og godt avgrenset, der løsningen er åpenbar og du selv er brukeren, kan du gå rett på utvikling. Skal du lage en intern side som viser fem tall fra et regneark, er en prototype mest seremoni.
Det samme gjelder hvis du allerede har et produkt i drift og skal legge til en funksjon som følger mønstre brukerne kjenner fra før. Da ligger designet i praksis fast, og du vinner lite på å tegne det opp på nytt.
Men skal du bygge noe nytt for andre enn deg selv, og du ikke er helt sikker på hvordan de jobber i dag, er prototypen den rimeligste forsikringen du kan kjøpe.
Fra prototype til ferdig produkt
En god prototype er ikke bortkastet arbeid når utviklingen starter. Den fungerer som spesifikasjon. Utviklerne slipper å gjette hva som var ment, fordi de kan klikke seg gjennom det selv. Diskusjoner som ellers ville tatt en uke i kommentarfeltet, er allerede avgjort.
Hos oss går prototypen som regel rett inn i arbeidet med en MVP, altså en første versjon med akkurat nok funksjonalitet til å være nyttig. Prototypen forteller hva som skal bygges, MVP-en avgjør hva som skal bygges først.
Vil du vite mer om hvordan vi jobber med design og prototyper, eller lure på om ideen din er moden for det? Ta kontakt, så ser vi på den sammen.