Begynn med situasjonen, ikke funksjonslisten
Beskriv hvem appen er for, hva de prøver å få gjort, og hvordan de løser det i dag. «En app for trenere» er et utgangspunkt. «La treneren melde en endring i oppmøtested til hele laget og se hvem som har fått den med seg» er lettere å diskutere og teste.
Snakk med noen i målgruppen. Be dem vise dagens arbeidsmåte og fortelle om sist problemet oppstod. Konkrete hendelser sier mer enn et generelt spørsmål om de liker ideen. Noter også hvorfor de eventuelt ville beholdt løsningen de allerede har.
Velg én oppgave brukeren skal kunne fullføre
MVP betyr minimum viable product. Her bruker vi begrepet om en avgrenset første versjon som løser en faktisk oppgave og lar deg undersøke om løsningen har verdi. Den trenger en hel brukerreise: fra brukeren åpner appen til oppgaven er ferdig.
I lag-eksempelet kan første versjon handle om beskjeder og bekreftelser. Betaling, statistikk og en sosial feed kan vente. Legg ønsker i tre grupper, og skriv en kort begrunnelse for hver prioritering.
- Må være med for at hovedoppgaven skal fungere.
- Kan gjøre løsningen bedre senere.
- Trenger vi mer kunnskap om før vi bestemmer oss?
Test det mest usikre først
En klikkbar prototype kan være nok til å teste om folk forstår flyten. En liten teknisk prøve kan avklare om appen kan hente data fra et eksisterende system. Velg undersøkelsen etter spørsmålet du trenger svar på.
En prototype og en app klar for bruk har ulike formål. Skisser kan vise en tenkt løsning uten å ha innlogging, lagring eller feilhåndtering bak skjermene. Avtal tydelig hva som faktisk virker, slik at en pen demo ikke blir forvekslet med et ferdig produkt.
Gjør den lille versjonen ordentlig brukbar
Avgrens funksjonene, men planlegg for det som skjer rundt dem. Hva ser brukeren før det finnes innhold? Hva skjer når nettet forsvinner, en opplysning mangler eller en handling mislykkes? Tekster, tilgjengelighet og en tydelig vei videre hører med i oppgaven.
Avklar også hvilke data løsningen trenger, hvem som skal administrere innhold, og hvem brukeren kontakter ved problemer. Test på relevante enheter før utgivelse. For en iPhone-app kan TestFlight brukes til betatesting og tilbakemeldinger fra reelle brukere.
Bestem hva dere skal lære etter lansering
Skriv ned noen få spørsmål før første test: Klarer brukeren å fullføre oppgaven? Forstår de beskjeden? Bruker de løsningen igjen når behovet oppstår? Samtaler, observasjon og relevant tilbakemelding kan hjelpe deg å vurdere dette.
Bruk funnene til å velge neste steg. Det kan være å rette en vanskelig flyt, justere ideen eller legge til en ny funksjon. En god første versjon gir både en brukbar løsning og et tydeligere bilde av hva det er verdt å bygge videre på.
Ta ideen et steg videre.
Har du en appidé? Send en kort beskrivelse av målgruppen og problemet til hello@rasklabs.no, så kan vi snakke om en passende første versjon.
Fortell om appideen