Rask prototyping

En prototype er ikke et lite ferdig produkt — det er et spørsmål gjort synlig. Målet er å lære noe konkret så raskt og billig som mulig. Jo styggere og enklere prototypen er, jo mindre er du forelsket i den, og jo lettere er det å høre ærlig kritikk.

Lavoppløste prototyper

Start så enkelt du kan. Lavoppløste prototyper er raske, billige og lette å kaste:

• Skisser på papir: Tegn skjermbildene for hånd. Du kan teste en hel brukerflyt med en bunke ark.
• Papirprototype: Klipp ut «knapper» og legg nye ark oppå når brukeren «trykker». Du spiller datamaskin.
• Klikkbar mockup: Enkle digitale skjermbilder koblet sammen med lenker, uten at noe faktisk virker bak.

Poenget er å teste idéen, ikke håndverket. Bruker du uker på en pen prototype, har du bygd for mye før du har lært noe.

Fake door- og landingsside-tester

Noen ganger er det viktigste spørsmålet rett og slett: vil folk ha dette? Da kan du teste etterspørselen før du bygger.

En landingsside-test er en enkel side som beskriver tilbudet med en tydelig knapp — «Meld deg på» eller «Forhåndsbestill». Du måler hvor mange som klikker og legger igjen e-post. En fake door-test går et steg videre: du legger en knapp for en funksjon som ennå ikke finnes. Når noen klikker, får de en høflig «kommer snart»-melding — og du har målt reell interesse uten å ha bygd funksjonen. Bruk fake door-tester varsomt og ærlig, slik at folk ikke føler seg lurt; en kort forklaring og mulighet til å melde interesse holder tonen ryddig.

Concierge- og Wizard-of-Oz-metoden

Disse to lar deg levere ekte verdi før du bygger teknologi.

Med concierge-metoden gjør du jobben helt manuelt og åpent, som en personlig tjener. Ingrid, som vurderer en abonnementstjeneste for gjenbruksemballasje, kan pakke og sende de første kassene selv, hente dem tilbake for hånd og notere hva som funker. Hun lærer alt om logistikken før hun automatiserer noe.

Med Wizard-of-Oz-metoden ser tjenesten automatisk ut for kunden, men bak kulissene er det et menneske som gjør arbeidet. Kunden opplever «systemet», mens du lærer om oppførselen deres uten å ha kodet noe.

Bygg akkurat nok til å lære

Før du lager noe som helst, still ett spørsmål: hva er det ene jeg vil lære av dette? Bygg deretter det minste som svarer på det spørsmålet — ikke mer. Hver ekstra funksjon du legger til «mens du først er i gang», gjør prototypen dyrere å endre og vanskeligere å tolke.

En god prototype er ferdig når den kan gi deg et klart ja eller nei på antakelsen din. Alt utover det er pynt du ikke har råd til ennå.

Klatre oppover i oppløsning

En vanlig feil er å hoppe rett til en pen, digital prototype. Bedre å klatre oppover en stige: start med en grov skisse, gå videre til papir, så til en klikkbar mockup, og bygg først noe «ekte» når de billigere stegene har svart på det de kan.

Hvert trinn koster mer og er tyngre å endre. Så lenge en skisse på en serviett kan lære deg det samme som en ferdig app-skjerm, velger du servietten. Regelen er: bruk den laveste oppløsningen som fortsatt gir deg et ærlig svar på spørsmålet ditt. Før Maria bygde noen bestillingsflyt, tegnet hun de fem skjermbildene på papir og lot en hundeeier «trykke» seg gjennom. På to minutter oppdaget hun at folk lette etter «pris» før «book» — en endring som ville kostet timer i kode, men sekunder på papir.

Gjør dette nå

Ta den farligste antakelsen fra forrige leksjon. Velg den enkleste prototypen som kan teste den: en papirskisse, en klikkbar mockup, en landingsside eller en manuell concierge-leveranse. Sett av maks én dag til å lage den. Skriv ned, før du starter, nøyaktig hva du håper å lære — så du vet hva du ser etter når du tester den i neste leksjon.