Før dere bestiller en app, bør dere kunne forklare hvem som skal bruke den, hvilken oppgave den løser og hva som blir enklere enn i dag. Det gir et bedre grunnlag for utvikling enn en lang ønskeliste med innlogging, dashboard og AI. Funksjonene må få en konkret jobb.
En app kan være en tjeneste kunden bruker, et internt arbeidsverktøy eller et selvstendig produkt. Disse har ulike krav til innhold, tilganger, drift og oppfølging. Start med bruken, og vurder deretter om en nettside, en webapp, en mobilapp eller eksisterende verktøy passer best.
Beskriv én situasjon fra brukerens hverdag
Velg en konkret personrolle og følg oppgaven fra behov til resultat. Hva vet personen når arbeidet begynner? Hvilke valg må tas? Hva skal lagres? Hvem trenger informasjonen etterpå? Hvis dere ikke kan forklare dette uten å tegne en skjerm, er oppgaven sannsynligvis ikke avklart godt nok ennå.
Et fiktivt eksempel er en bedrift som ønsker en kundeportal. «Kunden skal logge inn» beskriver en funksjon. «Kunden skal finne siste godkjente tilbud, se avtalt levering og sende en endring til riktig ansvarlig» beskriver bruken. Den andre formuleringen gir dere noe konkret å teste.
Avgrens første versjon rundt et helt behov
En liten første versjon må fortsatt la brukeren gjennomføre en nyttig oppgave. Å bygge litt av alle funksjoner kan gi mange skjermer uten et fungerende løp. Velg heller én sammenhengende oppgave med start, bekreftelse, feiltilfeller og et forståelig resultat.
- Avklar behovet. Beskriv brukeren, oppgaven og hva dere må lære før dere bygger.
- Prøv arbeidsflyten. Test en skisse eller prototype med representative oppgaver.
- Bygg for faktisk bruk. Ta med data, tilganger, feil, innhold og videre drift i leveransen.
Lag en egen liste over det som kan vente. Det kan være flere språk, avansert rapportering eller flere brukerroller, dersom disse ikke er nødvendige for første bruk. Avgrensningen må være bevisst: Krav til tilgang og håndtering av opplysninger kan ikke bare skyves til senere fordi de er mindre synlige.
Skill prototypen fra produktet som skal driftes
En prototype hjelper dere å undersøke en idé. Den kan vise flyt, innhold og valg uten at alle deler er koblet til ekte data. I vårt arbeid kan blant annet Lovable brukes til prototyper og testing. Det betyr ikke at prototypens tekniske oppsett automatisk er riktig for et større produkt.
Før vanlig bruk må dere vurdere kode, datamodell, innlogging, tilganger, integrasjoner og drift. Arkitekturen velges ut fra behovet og hvem som skal vedlikeholde løsningen. Det er ingen fast kombinasjon av rammeverk og database som passer alle prosjekter.
Tre prosjekter viser forskjellige utviklingsbehov
Ima Helse: tjenesten før og etter oppstart
Ima Helse kobler nettside og app til Mathilde M. Skoglunds tjeneste. Arbeidet omfatter blant annet daglig oversikt, registreringer, innhold og oppfølging. Færder Marketing har bidratt fra strategi og idé til digitale flater og markedsføring. Her må det kunden møter før oppstart, henge sammen med tjenesten etterpå.
Arvemappa: innhold som hører sammen
Arvemappa er vår egen satsing gjennom K28 Invest AS. Bilder, historier og familiekunnskap knyttes sammen med blant annet album og slektstre. Det gjør relasjoner mellom innhold og valg om deling til viktige utviklingsoppgaver. En fin visning er bare en del av produktet; brukeren må også forstå hvor informasjonen havner og hvem den deles med.
Familiealbumet viser hvordan vi har samlet bilder, historier og personer i én brukerflyt. Brukeren kan finne minner via en person, skrive en historie og invitere familien videre inn. Bak disse inngangene ligger arbeidet med innholdsstruktur, relasjoner og deling. Når dere planlegger en app, bør dere på samme måte avklare hvordan innholdet hører sammen før dere bestemmer hvordan hver skjerm skal se ut.
Basic Matte: en modell brukeren kan styre
Basic Matte er også en egen satsing gjennom K28, med originalen fra Sverre H. Bautz. Utviklingen omfatter blant annet interaktive modeller, forklaringer og øving. Her må handlingen på skjermen hjelpe brukeren å forstå matematikkoppgaven. Flere effekter er ikke et mål i seg selv.
I tellemodellen kan eleven endre antallet med en skyveknapp eller pluss og minus. Brikkene og tallet viser den samme verdien. Vi har videreutviklet læringsrommet med slike modeller og veier mellom forklaring og øving. Utviklingsoppgaven er å holde brukerens valg, modellens tilstand og det som vises, i samsvar. Det samme prinsippet er relevant i en app der kunden velger mengde, størrelse eller andre verdier og trenger en forståelig respons.
Prosjektene har forskjellige brukeroppgaver: følge opp en tjeneste, ta vare på familieinnhold og utforske matematikk. Derfor trenger de også forskjellige datamodeller, innholdsstrukturer og måter å gi tilbakemelding på. Bruk dem som eksempler på spørsmål som må avklares, fremfor som en ferdig funksjonsliste for deres app.
Test mer enn den enkleste veien gjennom
Gi testpersonen en oppgave uten først å forklare alle knappene. Se hvor vedkommende stopper, hva som misforstås og om resultatet er forståelig. Prøv også tomme lister, feil opplysninger, avbrutt innsending og manglende tilgang. En løsning skal forklare hva brukeren kan gjøre når noe ikke går som planlagt.
Kontroller mobil, større skjerm og tastaturbruk. Test med realistiske mengder innhold, ikke bare ett kort navn og tre pene eksempelbilder. Hvis arbeidet fortsetter i et annet system eller hos en medarbeider, inngår den overleveringen også i testen.
Bestem hvem som eier og følger opp løsningen
Avklar eierskap til kode, domene, data og kontoer før leveransen. Beskriv hvem som retter feil, følger opp sikkerhet, tar backup og vedlikeholder innhold. Be om en forståelig plan for å eksportere data og overlevere arbeidet. Et produkt som skal brukes over tid, trenger mer enn en vellykket demonstrasjon.
Skill utvikling av første versjon fra løpende drift og nye funksjoner. Prioriter forbedringer ut fra faktisk bruk etter lansering. Hvis behovet først og fremst er å koble eksisterende verktøy, kan en avgrenset automatisering være et bedre første steg.
Ta gjerne med en beskrivelse av én brukeroppgave når dere vurderer skreddersydd utvikling og kundeapper. Da kan vi diskutere et konkret behov og hva som bør prøves før dere bestemmer omfanget.
