Hva bør være klart før apputvikling?
Kort svar
Du trenger ikke en komplett kravspesifikasjon før du kontakter en utvikler. Men før apputvikling bør dere ha klart hvilket problem appen skal løse, hvem den er for, ønsket brukerflyt, prioriterte funksjoner, budsjettområde og hvilke systemer appen må kobles mot. Det gir bedre apputvikling krav, tydeligere apputvikling scope og et mer realistisk grunnlag for pris.
Avklar problem, MVP, integrasjoner og første scope
/// APP_SCOPE_READINESS
Avklaringer før bygging
Pris og plan blir mer presis når problem, brukere, MVP, systemer og ansvar er koblet sammen.
Hva er problemet appen skal løse?
En app bør ikke starte som en samling skjermer. Den bør starte med et problem som er konkret nok til at man kan prioritere bort funksjoner. Hvis problemet er uklart, blir pris, tid og scope fort uklart også.
- Hvilket problem opplever brukeren i dag?
- Hva gjør brukeren i stedet: regneark, telefon, e-post, skjema eller et annet system?
- Hva blir bedre når appen fungerer: mindre manuelt arbeid, raskere bestilling, bedre datakvalitet eller ny inntekt?
- Hvordan ser dere at problemet er løst i første versjon?
Hvem skal bruke appen?
Brukerrollen styrer design, innlogging, datamodell, rettigheter og supportbehov. En app for ansatte med høy opplæring tåler andre valg enn en app for kunder som skal forstå alt på første forsøk.
- Hvem er første brukergruppe?
- Er brukeren kunde, ansatt, partner, administrator eller flere av disse?
- Hvor ofte skal appen brukes?
- Hvilken situasjon er brukeren i når appen åpnes?
- Hva må brukeren klare uten forklaring fra support?
Hva er MVP-en?
App MVP planlegging handler om å finne minste testbare versjon, ikke minste mulige design. Første versjon må være smal, men den må fortsatt gi ekte læring om brukerflyt, verdi og teknisk risiko. Les mer om MVP app-utvikling hvis dere trenger en dypere avgrensning.
- En tydelig målgruppe
- En hovedhandling brukeren skal fullføre
- Nok design til at flyten er forståelig
- Nok backend og data til at testen er ekte
- Måling av om brukeren faktisk fullfører handlingen
- En plan for hva som avgjør neste versjon
Hvilke funksjoner må være med fra start?
En må-ha-funksjon er noe første brukerreise ikke fungerer uten. Alt annet bør vurderes kritisk. Dette er ofte den viktigste jobben før man spør hva appen vil koste.
- Funksjoner som er nødvendige for hovedflyten
- Innlogging bare hvis data, roller eller personvern krever det
- Adminfunksjoner som trengs for drift av første versjon
- Integrasjoner som må være på plass for at testen skal være reell
- Feilhåndtering for de vanligste avbruddene i brukerreisen
Hvilke funksjoner bør vente?
Funksjoner som kan vente er ikke nødvendigvis dårlige ideer. De er bare ikke nødvendige for å bevise første verdi. Å utsette dem gjør prisgrunnlaget mer ryddig og reduserer risiko for feil scope.
- Ekstra roller som ikke trengs i første test
- Avanserte dashboards før datagrunnlaget finnes
- Automatisering av sjeldne unntak
- Native mobilapp hvis webapp kan teste behovet godt nok først
- Betaling, BankID, Vipps eller booking før kjerneflyten krever det
- Rapporter, eksport og interne visninger som ikke påvirker første brukerhandling
Skal det være mobilapp, webapp eller begge?
Webapp
Passer ofte når løsningen skal deles med lenke, testes raskt og fungere på tvers av enheter.
Mobilapp
Passer bedre når push, kamera, lokasjon, offline eller hyppig bruk på telefonen er avgjørende.
Begge
Bør vanligvis vurderes etter at kjerneflyt, budsjett og brukerfrekvens er tydelig nok.
Se også guiden om mobilapp eller webapp før dere låser teknologi for tidlig.
Trenger appen innlogging, betaling, BankID, Vipps, booking, dashboard eller API?
Slike valg påvirker både arkitektur, sikkerhet, testing og tidsbruk. Det betyr ikke at alt må bygges i første versjon, men det bør være synlig i avklaringen. Ellers kan et prisestimat bli for lavt eller bygge på feil antagelser.
- Innlogging og roller
- Betaling, abonnement eller Vipps
- BankID eller annen identitetskontroll
- Booking, kalender eller kapasitet
- Dashboard og adminpanel
- API mot CRM, regnskap, lager, fagsystemer eller interne databaser
- Varsler på e-post, SMS eller push
Hvem skal administrere innhold og data?
Mange app-prosjekter undervurderer admin. Noen må kunne endre innhold, rette data, se ordre, håndtere brukere eller følge opp henvendelser. Hvis dette skal gjøres uten utvikler, må adminpanel, roller og datakvalitet inn i scope.
Avklar også hvem som eier dataene, hvilke data som er personopplysninger, og hvordan support skal håndteres etter lansering.
Hva må være klart for å få realistisk pris?
Når noen spør hva må avklares før pris på app, er svaret vanligvis mindre formelt enn en full kravspesifikasjon, men mer konkret enn en idebeskrivelse. Leverandøren trenger nok til å forstå scope, risiko og avhengigheter.
- Problem, målgruppe og forventet effekt
- Skisse av brukerflyt eller skjermliste
- Prioritert funksjonsliste: må ha, bør ha og senere
- Valg eller antagelse om mobilapp, webapp eller begge
- Integrasjoner, datakilder og systemeiere
- Budsjettområde og ønsket faseinndeling
- Hvem som kan ta beslutninger underveis
- Hvem som skal drifte innhold, data og support etter lansering
For mer om prisdrivere kan du lese hva koster app-utvikling. Hvis første versjon kan være nettleserbasert, er også hva koster webapp relevant.
Når bør du vente med apputvikling?
Det kan være riktig å vente hvis appen fortsatt er for uklar. Ofte er neste steg da en workshop, prototype, manuell pilot eller smal webflyt, ikke full apputvikling.
- Ingen kan beskrive første brukerhandling
- Målgruppen er for bred til å teste med ekte brukere
- Problemet kan valideres billigere med skjema, prototype, manuell pilot eller eksisterende SaaS
- Budsjettet er låst før apputvikling scope og integrasjoner er avklart
- Ingen eier innhold, data, support eller videre prioritering
- Appen er bare en ønskeliste uten tydelig problem og beslutningspunkt
Hvordan Tigon ville avklart prosjektet
- 01Vi starter med problemet og hvem som faktisk skal bruke appen.
- 02Vi tegner kjerneflyten før vi diskuterer full funksjonsliste.
- 03Vi skiller MVP fra senere versjoner, slik at første scope blir testbart.
- 04Vi kartlegger innlogging, roller, data, admin og nødvendige integrasjoner.
- 05Vi vurderer mobilapp, webapp eller begge ut fra brukssituasjon og distribusjon.
- 06Vi lager et prisgrunnlag med antagelser, risiko og faseforslag.
Når avklaringen er gjort, kan dere gå videre til en mer presis vurdering av app-utvikling, tidsbruk og første fase. For lokal kontekst finnes også app-utvikling i Oslo, men denne guiden er ment som nasjonal støtte før scope og pris settes.
Få appideen vurdert før du bygger
Vi kan hjelpe dere å rydde i problem, brukerflyt, MVP, integrasjoner og hva som bør vente før apputvikling starter.
Få appideen vurdert før du bygger