Du trenger ikke en designer for å lage en første prototype. For å teste om ideen din henger sammen, kommer du overraskende langt på egen hånd, og det er ofte den beste bruken av de første ukene.
Denne artikkelen handler om hvordan du gjør det selv. Vil du heller vite hvordan et fullverdig prototypeløp ser ut, har vi beskrevet det steg for steg i slik lager du en prototype for mobilappen din.
Begynn med papir
Det høres gammeldags ut, men det er fortsatt den raskeste måten å tenke på.
Tegn ett skjermbilde per ark. Ingen detaljer, bare hvor ting er og hva som skjer når du trykker. Legg arkene etter hverandre i den rekkefølgen brukeren går gjennom dem, og se om historien henger sammen.
Fordelen er at det tar minutter og at du ikke blir knyttet til noe. Et ark du har brukt tre minutter på, kaster du uten å nøle. Et skjermbilde du har brukt to timer på, forsvarer du.
Du kan faktisk teste med papir også. Legg arkene foran noen, be dem peke på hva de ville trykket på, og bytt ark. Det avdekker mer enn folk tror.
Verktøyene som finnes
Når skissene henger sammen, er neste steg et digitalt verktøy der skjermbildene kan kobles sammen og klikkes gjennom.
Figma er bransjestandarden og har en gratisversjon som holder lenge for én person. Det har en læringskurve, men du trenger bare en liten del av det for å lage en klikkbar prototype: tegne rektangler og tekst, og koble en knapp til et annet skjermbilde.
Penpot er et åpent alternativ som fungerer på samme måte. Canva har enklere prototypefunksjonalitet som kan holde for helt grunnleggende behov.
Det finnes også verktøy som genererer grensesnitt fra en beskrivelse. De kan være nyttige for å komme raskt i gang med noe å reagere på, men resultatet blir ofte generisk og speiler sjelden hvordan akkurat dine brukere jobber. Bruk dem gjerne til å produsere et utgangspunkt, ikke til å avgjøre hvordan appen skal fungere.
Hva du bør få til selv
Målet ditt er ikke et pent design. Målet er å finne ut om folk forstår hva de skal gjøre.
Lag skjermbildene for den ene viktigste oppgaven, koble dem sammen, og fyll inn realistisk innhold. Bruk navn som ligner ekte navn og tekster som er så lange som de faktisk blir. Korte, perfekte eksempeltekster skjuler problemer som dukker opp umiddelbart i virkeligheten.
Vis den så til fem personer fra målgruppen, gi dem en oppgave, og si ingenting mens de prøver. Det er selve poenget med hele øvelsen.
Hvor grensen går
Det er noen ting du sannsynligvis ikke bør gjøre selv.
Skal prototypen brukes til å overbevise investorer eller store kunder, teller inntrykket. Der er forskjellen mellom noe hjemmelaget og noe gjennomarbeidet synlig, og den kan koste deg mer enn designet ville gjort.
Skal den fungere som spesifikasjon for utviklerne, trengs det mer presisjon enn en skisse gir. Avstander, størrelser, hva som skjer ved feil, og hvordan det ser ut på ulike skjermstørrelser må være avklart, ellers gjettes det under utviklingen.
Og skal løsningen ha mange brukerroller og kompliserte arbeidsflyter, blir det fort uoversiktlig å holde styr på selv.
En vanlig og fornuftig arbeidsdeling er at du lager den grove versjonen og tester den, og at en designer tar over når retningen er bestemt. Da betaler du for det som krever fagkunnskap, og ikke for å finne ut hva appen skal gjøre.
Den vanligste feilen
Å lage prototypen for pen for tidlig.
Når noe ser ferdig ut, kommenterer folk overflaten. Når det ser uferdig ut, kommenterer de innholdet. I starten er innholdet det du trenger tilbakemelding på, og da er grå bokser et fortrinn framfor en mangel.
Den nest vanligste er å teste på feil folk. Kolleger som kjenner prosjektet, klarer ikke å se det med friske øyne, og venner vil være hyggelige. Du trenger folk som faktisk har problemet.
Når du har testet
Har du en prototype som folk forstår, har du gjort det viktigste forarbeidet. Neste steg er å bestemme hva som skal bygges først, og der er MVP-tankegangen nyttig.
Vil du ha noen til å se på det du har laget, eller ta det videre? Se hvordan vi jobber med design og prototyper, eller ta kontakt.