En prototype er en versjon av appen som ser og oppfører seg som den ekte, men som ikke har noe bak seg. Knappene virker, skjermbildene henger sammen, og du kan klikke deg gjennom en hel oppgave. Under overflaten finnes det ingen database og ingen logikk.
Her er hvordan du kommer dit, i praksis. Lurer du på om du trenger en i det hele tatt, er prototyping av mobilapplikasjoner et bedre sted å starte.
Begynn med oppgaven, ikke skjermbildene
Det første steget skjer uten verktøy. Skriv ned, i vanlige setninger, hva brukeren skal få gjort fra start til slutt.
For eksempel: montøren åpner appen, ser dagens oppdrag, velger ett, registrerer timer og materiell, legger ved et bilde, og markerer oppdraget som fullført. Det er syv steg, og de bestemmer hvilke skjermbilder du trenger. Begynner du i motsatt ende, med å tegne skjermbilder, ender du med skjermbilder som ikke henger sammen.
Hold deg til én oppgave i første omgang. Den viktigste. Alt annet kan legges til senere.
Tegn grovt før du tegner pent
Neste steg er enkle skisser. Grå bokser, ingen farger, ingen bilder, bare plassering og rekkefølge. Dette kan gjøres på papir eller i et verktøy, og det bør gå fort.
Poenget med at det ser uferdig ut, er at folk da kommenterer det du faktisk lurer på. Viser du en polert skjerm, får du tilbakemeldinger om fargevalg. Viser du en grå boks, får du tilbakemeldinger om at et viktig valg mangler, eller at rekkefølgen er rar. Det er det du trenger nå.
Lag skisser for hvert steg i oppgaven du beskrev, og se om de henger sammen når du legger dem etter hverandre.
Bygg den klikkbare versjonen
Nå legger du på ekte design: farger, typografi, ikoner og realistisk innhold. Deretter kobler du skjermbildene sammen slik at knappene faktisk fører et sted.
Det viktigste rådet her er å bruke realistisk innhold. Navn som ligner ekte navn, tekster som er så lange som de faktisk blir, tall som ser ut som ekte tall. Prototyper med "Lorem ipsum" og perfekte korte titler skjuler problemer som dukker opp med én gang i virkeligheten.
Ta også med de kjedelige tilstandene. Hva ser brukeren når lista er tom? Når noe feiler? Når de mangler rettigheter? Disse utgjør en stor del av faktisk bruk og blir nesten alltid glemt.
De fleste verktøy lar deg åpne prototypen på en ekte telefon. Gjør det. En skjerm som ser romslig ut på laptopen kan være trang i hånda.
Test med fem personer
Dette er steget som gir mest, og det som oftest hoppes over.
Finn fem til åtte personer fra målgruppen. Ikke kolleger som kjenner prosjektet, og ikke venner som vil være hyggelige. Folk som faktisk har problemet appen skal løse.
Gi hver av dem en konkret oppgave, formulert som et mål framfor en instruks. Si "registrer timene dine for i dag", ikke "trykk på pluss-knappen og velg dato". Så tier du stille. Dette er vanskeligere enn det høres ut, men idet du forklarer, har du ødelagt testen.
Se etter hvor de nøler, hva de trykker på som ikke er en knapp, og hvilket ord de leter etter som ikke står der. Noter hva de sier underveis, særlig når de sier noe overrasket.
Fem personer avdekker de fleste alvorlige problemene. De neste tjue bekrefter stort sett det samme.
Rett opp og test igjen
Gå gjennom det du fant og skill mellom to typer funn. Det som er en preferanse hos én person, og det som flere snublet i. Bare det siste er verdt å endre på nå.
Rett opp, og kjør gjerne en kort runde til med to eller tre nye personer. Endringene du gjorde kan ha skapt nye problemer, og det er billig å oppdage nå.
Hvor lang tid det tar
For én avgrenset oppgave er dette et arbeid på halvannen til tre uker, inkludert testing. Skal prototypen dekke flere brukerroller og flere arbeidsflyter, tar det lenger.
Det føles som tid brukt før prosjektet starter. I praksis er det tid spart, fordi diskusjoner som ellers ville dukket opp under utviklingen allerede er avgjort.
Hva du gjør med den etterpå
Prototypen er ikke bortkastet når utviklingen begynner. Den fungerer som spesifikasjon: utviklerne slipper å gjette hva som var ment, fordi de kan klikke seg gjennom det selv.
Den er også det du viser internt for å få folk med, eller til investorer og potensielle kunder. I tidlig fase er en god prototype ofte mer overbevisende enn en halvferdig app, og den koster en brøkdel.
Når prototypen er testet og godkjent, er neste steg å bestemme hva som skal bygges først. Det er der MVP-tankegangen kommer inn.
Vil du ha hjelp?
Vi lager prototyper både som eget oppdrag og som første fase i et større prosjekt. Se hvordan vi jobber med design og prototyper, eller ta kontakt for en prat om ideen din.