En app prototype er en enkel visualisering eller simulering som lar deg teste den viktigste brukerreisen før full utvikling. Start med problemet, velg en konkret oppgave og observer hvordan relevante brukere prøver å løse den. Prototypen kan avdekke svakheter i flyt og forståelse, men beviser ikke alene marked eller betalingsvilje.
Mange appprosjekter blir unødvendig store fordi funksjonslisten kommer før problemet. En app prototype gjør ideen konkret nok til at du kan teste den viktigste brukerreisen før du bestiller full utvikling.
Målet er ikke å få noe som ser ferdig ut. Målet er å se om målgruppen forstår løsningen, hvor flyten stopper opp og hva som bør prioriteres før dere bygger.
Hva er en app-prototype?
En app-prototype er en visualisering eller simulering av hvordan brukeren beveger seg gjennom en app. Den kan være en papirskisse, en skjermflyt eller en klikkbar mobilapp-simulering med knapper og overganger.
DOGA beskriver prototyping som å konkretisere ideer raskt, slik at de kan testes. En prototype mobilapp trenger derfor ikke innlogging, database, betaling eller ekte data, så lenge den lar dere undersøke det dere trenger å lære.
Prototypen er et beslutningsverktøy, ikke nødvendigvis en app som kan publiseres eller brukes av ekte kunder. En enkel prototype kan være tilstrekkelig når dere vil finne ut om en sentral oppgave og brukerflyt er forståelig, slik DOGA forklarer i veiledningen om brukertesting og kundeintervjuer.
Velg riktig nivå før dere bygger
Skisse, app wireframe, klikkbar prototype, teknisk proof of concept og MVP svarer på ulike spørsmål. Velg det enkleste nivået som gir dere beslutningsgrunnlaget dere mangler nå.
Sammenligning av nivåene
En skisse eller wireframe er ofte nok når dere utforsker problem og struktur. Bygg ikke en fungerende app bare for å finne ut om rekkefølgen på skjermer eller teksten på en knapp er forståelig.
| Nivå og hva det er | Formål | Hva dere kan teste | Hva som normalt ikke følger med | Når det passer |
|---|---|---|---|---|
| Rask tegning av ide og skjermer | Utforske mulige løsninger | Tidlige ideer og innhold | Interaksjon, teknikk og ekte data | Når dere utforsker problem og mulige løsninger |
| Struktur, innhold og brukerflyt uten ferdig visuelt uttrykk | Bli enige om hva hver skjerm skal inneholde | Informasjonshierarki og rekkefølge | Ferdig design og reell funksjon | Når kjerneflyten skal avgrenses |
| Simulerte skjermer med trykk og overganger | Observere en sentral oppgave | Navigasjon, forståelse og forventninger | Produksjonsklar sikkerhet, drift og ekte data | Når dere skal brukerteste en realistisk flyt |
| Avgrenset teknisk utprøving | Avklare en teknisk usikkerhet | Om for eksempel integrasjon, kamera eller sanntidsdata kan fungere | God brukeropplevelse og full app | Når teknikken er den største risikoen |
| Fungerende førsteversjon av appen | Bruke løsningen i en avgrenset reell situasjon | Reell bruk og prioriterte funksjoner | Alle ønskede funksjoner og full bredde | Når dere er klare for pilot eller tidlig lansering |
En MVP er altså noe annet enn en klikkbar prototype. Den må fungere for reelle brukere og trenger en forsvarlig løsning for blant annet tilgang, data og drift innenfor omfanget dere har valgt.
Start med problemet og en testbar hypotese
Start med hypotesen, ikke med skjermbildene
Før dere tegner, må dere definere hvem dere vil hjelpe og hvilken situasjon dere vil forbedre. Beskriv hva målgruppen gjør i dag, hva som skaper friksjon, og hvilket alternativ de bruker når appen ikke finnes.
Bruk denne malen: «Vi tror at [målgruppe] vil [handling] fordi [problem]. Vi vil se tegn på dette når [observerbart resultat].» Et observerbart resultat kan være at brukeren finner fram til en handling uten hjelp eller fullfører en oppgave i prototypen.
Velg deretter en prioritert brukerreise fra start til mål. For en bookingløsning kan det være fra behovet oppstår, via valg av tidspunkt, til bekreftelse. Ikke tegn administrasjon, varsler, profil og alle spesialtilfeller før dere vet at kjerneoppgaven er forstått.
Avgrens testen ved å bestemme hva brukeren skal klare når oppgaven er ferdig. Er svaret uklart, er prototypen sannsynligvis for bred.
Slik lager du en app prototype uten å bygge alt
Slik lager du prototype app i seks trinn
- Velg en målgruppe og en konkret arbeidssituasjon. «Alle kunder» og «når som helst» blir for bredt.
- Beskriv nåsituasjonen: Hva gjør brukeren i dag, hvor oppstår venting, feil eller ekstraarbeid, og hvilket resultat savner personen?
- Tegn brukerflyten før enkeltskjermene: startpunkt, valg, nødvendig informasjon, handling og resultat.
- Lag en app wireframe med bare skjermene som trengs for kjerneoppgaven. Bruk tydelige navn på knapper og felt.
- Gjør flyten klikkbar dersom dere vil teste navigasjon og forståelse. Simuler overganger, tilbakemeldinger og feilvalg.
- Merk hva som er simulert, manuelt eller ikke løst, som innlogging, betaling, integrasjoner og varsler.
En pen prototype kan lett bli misforstått som en ferdig kravspesifikasjon. En tydelig oversikt over antakelser, simuleringer og åpne spørsmål gjør den mer nyttig for både testpersoner og dem som senere skal bygge løsningen.
Prototyping handler om å gjøre en ide testbar, ikke om å ferdigstille hvert skjermbilde. DOGA nevner blant annet skisser, simulerte situasjoner og enkle digitale løsninger som relevante prototypeformer i sin veiledning om designdrevet innovasjon.
Test appideen gjennom handlinger, ikke høflige meninger
Slik tester du appideen med relevante brukere
Rekrutter personer som faktisk ligner målgruppen og kjenner situasjonen dere undersøker. Venner og familie kan gi innspill, men representerer ikke automatisk brukerne dere skal nå.
Gi deltakeren en realistisk oppgave, for eksempel: «Du trenger å bestille en tid neste uke. Vis hvordan du ville gjort det.» Ikke forklar løsningen eller pek ut riktig knapp. DOGA anbefaler å la brukeren forsøke en konkret oppgave uten forklaring først og observere hvor personen stopper opp eller misforstår.
Se etter handlinger, ikke bare kommentarer. Hvor begynner personen å lete? Hvilke ord bruker personen? Hva forventer personen etter å ha trykket? Når ber personen om hjelp?
Still åpne oppfølgingsspørsmål etter oppgaven: «Hva forventet du skulle skje?», «Hvordan løser du dette i dag?» og «Hva var uklart?» Spørsmål om konkrete erfaringer gir vanligvis et bedre grunnlag enn «Ville du brukt denne appen?».
Dokumenter hvert funn på samme måte: observasjon, mulig årsak, konsekvens og anbefalt endring. Da blir det lettere å prioritere forbedringer framfor å samle løse meninger.
Noen få relevante deltakere kan avdekke tydelige mønstre i en tidlig test, men kan ikke si hvor utbredt behovet eller atferden er i hele markedet. Det understreker DOGA i veiledningen om brukertesting og kundeintervjuer.
Hva en prototype kan og ikke kan avklare
En prototype kan gi innsikt i om brukeren forstår innholdet, finner fram, klarer en oppgave og opplever arbeidsflyten som relevant. Den kan vise hvilke deler som skaper tvil eller krever forklaring.
Den beviser ikke alene markedsstørrelse, betalingsvilje, lønnsomhet, teknisk skalerbarhet eller at alle krav er oppfylt. Positive kommentarer er svake markedssignaler sammenlignet med observerbare handlinger som innebærer en forpliktelse.
Undersøk markedet separat med for eksempel en pilotkunde, en forhåndsbestilling, en intensjonsavtale eller test av salgsbudskapet. DOGA peker på at en forhåndsbestilling sier mer om kjøpsvilje enn et positivt utsagn, selv om heller ikke det alene forteller alt om markedet.
Innovasjon Norge omtaler testing av markedsbehov og arbeid mot markedsaksept med blant annet pilotkunder og partnere som en tidlig fase for nye forretningsideer. Før dere starter en pilot, bør dere avklare hvem som skal bruke løsningen, hva dere vil måle, hvem som gir support og hvilke data dere trenger.
Test brukbarhet og marked hver for seg
- Brukertest: Forstår målgruppen oppgaven, flyten og innholdet?
- Markedstest: Er noen villige til å prioritere, prøve eller kjøpe løsningen?
- Teknisk avklaring: Kan nødvendige integrasjoner, data eller enhetsfunksjoner fungere?
- Forretningsavklaring: Er det mulig å levere, drifte og tjene penger på løsningen?
Gjør tidlige avklaringer om krav og risiko
Ta høyde for tilgjengelighet, personvern og sikkerhet tidlig
Tenk universell utforming allerede i wireframen: god kontrast, tydelige etiketter, logisk rekkefølge, store nok trykkflater, forståelige feilbeskjeder og innhold som kan leses av skjermleser. Det er enklere å justere dette før flyt og komponenter er fastlåst.
Apper som trenger internettilkobling minst en gang etter nedlasting for å fungere etter sitt formål, omfattes av kravene til universell utforming av ikt, ifølge Tilsynet for universell utforming av ikt. Hvilke krav som er relevante, avhenger av appens funksjonalitet og kompleksitet.
Tilsynet anbefaler å ta hensyn til universell utforming fra starten, teste underveis og teste på både iOS og Android, blant annet med skjermleser. Plattformvalg handler derfor ikke bare om hvor brukerne befinner seg, men også om hvordan funksjonene skal fungere og kvalitetssikres.
Bruk fiktive eller testdata i en klikkbar prototype der det er mulig. Dersom testen innebærer personopplysninger, kartlegg hva dere samler inn, hvorfor dere trenger det, hvem som får tilgang og hvor lenge opplysningene lagres.
Avklar ekstra tidlig om appen kan håndtere helseopplysninger, lokasjon, betaling, barn eller identitet. Datatilsynets DPIA-sjekkliste peker blant annet på formål, nødvendighet, risiko for de registrerte og planlagte tiltak for å redusere risiko.
Sikkerhet bør inngå i avklaringen før dere bygger. Datatilsynet anbefaler blant annet å dokumentere metodikk for innebygd personvern og informasjonssikkerhet, og å analysere programvarens angrepsflate i sjekklisten om innebygd personvern.
Ikke behandle en klikkbar prototype som en produksjonsklar løsning. Den er laget for å lære raskt, ikke for å ha alle kontrollene en ekte app trenger.
Når er dere klare for MVP eller full apputvikling?
Dere er ofte klare for neste steg når problemet er tydelig, relevante brukere forstår kjerneflyten og dere har prioritert hva første versjon faktisk skal løse. Dere bør også vite hva dere vil oppnå med en pilot eller lansering.
Dette bør være klart før du ber om tilbud
- Målgruppe og situasjonen dere skal løse
- Dagens arbeidsmåte og et tydelig problem
- Prioritert brukerreise og kjernefunksjon
- Skjermflyt eller prototype
- Funn fra brukertest og planlagte endringer
- Behov for data, innlogging, integrasjoner eller betaling
- Valg, eller en foreløpig hypotese, om iOS og Android
- Mål for pilot eller lansering
Antall skjermer sier lite alene om omfanget. Innlogging, betaling, administrasjon, databehandling, integrasjoner og støtte for begge plattformer kan påvirke arbeidet betydelig. Se også hva det kan koste å lage en app i Norge når dere skal vurdere budsjett og omfang.
Webtoget kan hjelpe bedrifter med å bygge app fra en avgrenset MVP til større løsning. MVP for en plattform starter fra 49 000 kr eks. mva, Standard for iOS og Android fra 99 000 kr eks. mva, og skreddersydde apper fra 199 000 kr eks. mva. Oppgitt leveringstid er 4–8 uker for MVP og 2–4 måneder for komplett app.
Prisene gjelder apputvikling, ikke en separat pris på ren designprototype. Når mål, funksjoner og tekniske behov er avklart, kan du få et konkret fastpristilbud. Alle prosjekter hos Webtoget har fast pris.
Se apputvikling hos Webtoget for hva neste steg kan innebære, eller kundecaser fra Webtoget for eksempler på leveranser.
Beskriv den ene oppgaven appen må løse først. Det gir et mer presist grunnlag enn en lang liste med mulige funksjoner.
Se hvordan Webtoget avklarer og bygger apper, fra en avgrenset MVP til en større løsning. Apputvikling.
Ofte stilte spørsmål
Hva er en app-prototype?
En app-prototype er en forenklet visualisering eller simulering av en app. Den brukes for å undersøke om brukere forstår en oppgave, finner fram og opplever flyten som relevant før dere bygger en fungerende løsning.
Hva er forskjellen på en app wireframe, prototype og MVP?
En wireframe viser struktur, innhold og rekkefølge. En klikkbar prototype lar brukeren prøve en simulert flyt. En MVP er en fungerende førsteversjon som kan brukes av reelle brukere i en avgrenset situasjon.
Kan jeg lage en prototype til appen selv?
Ja. Papirskisser eller en enkel skjermflyt kan være nok for å avklare problem, innhold og rekkefølge. En klikkbar prototype er mest nyttig når du skal observere om brukere forstår navigasjon og sentrale handlinger.
Hvor mange personer bør jeg teste appideen med?
Noen få personer som faktisk ligner målgruppen kan avdekke tydelige mønstre tidlig. En slik test sier likevel ikke hvor stort behovet er i markedet eller hvor mange som vil betale.
Kan jeg bruke ekte kundeopplysninger i en app-prototype?
Bruk helst fiktive eller testdata. Dersom dere behandler personopplysninger i testfasen, må dere vurdere formål, informasjon til deltakerne, tilgang, lagring og risiko.
Les også
Krav til universell utforming, personvern og sikkerhet avhenger av appens funksjoner og hvordan virksomheten behandler data. Artikkelen er generell veiledning og erstatter ikke en konkret faglig eller juridisk vurdering.