top of page
Kristian Aslaksen

Hvordan designe en brukervennlig app?

Hvilket behov skal løses, og for hvem? Start alltid der. Funksjonalitet og design bør være et produkt av dette, ikke motsatt.


«For oss handler brukervennlighet om å løse brukernes behov på en enklest mulig måte.»

Start med behovet, ikke funksjonaliteten

For oss handler brukervennlighet om å løse brukernes behov på en enklest mulig måte. Kjernen i dette er å aller først definere hvilket behov som skal løses, og for hvem. For deretter å forstå dette behovet inn og ut.


La oss ta en av våre apps som eksempel, Båtførerappen - en app som er alt man trenger for å bestå båtførerprøven. Når vi startet prosjektet startet vi ikke med funksjonaliteten, vi startet ikke en gang med at det skulle være en app. Det vi viste var at: Vi skulle gjøre det så enkelt som mulig å få båtførerbeviset i Norge. Dette var behovet vi skulle dekke.


Videre satt vi oss inn i hva som må til for å få båtførerbeviset

  1. Alle over 14 år kan avlegge båtførerprøven i Norge, og det kreves ingen obligatorisk opplæring.

  2. Båtførerprøven avlegges på et autorisert testsenter, som du finner over hele landet.

  3. Veldig mange er ikke klar over hvordan dette fungerer, mange tror at prøven krever obligatorisk opplæring. Svært få vet hvor man finner testsenter.


Behovet som skulle dekkes var derfor:

Behov 1 Lære en person som ikke kan noe om båt pensumet til båtførerprøven, enklest mulig.

Behov 2 Gjøre det enkelt å finne testsenter og melde seg til eksamen.



Løs behovet på en enklest mulig måte

Når du vet hvilke behov du skal løse, og kjenner disse inn og ut, kan du begynne å løse disse. Hva er funksjonene som best mulig dekker behovet til forbrukeren? Det er kun disse funksjonene som bør prioriteres. Om en funksjon ikke bidrar til å dekke behovene bør dem fjernes. Slik kan man analysere funksjonaliteten man vurderer å ha i en app. Spør deg; er denne funksjonen med å dekke behovet jeg prøver å dekke?


La oss forstette med Båtførerappen som eksempel:

Behov 1 Lære en person som ikke kan noe om båt pensumet til båtførerprøven, enklest mulig. Se i videoen hvordan vi løste dette:


Behov 2 Gjøre det enkelt å finne testsenter og melde seg til eksamen.

Båtførerappen


Skill mellom «må-ha-funksjoner» og «kjekt-å-ha-funksjoner»

«Må-ha-funksjoner» er funksjonalitet man minimum må ha i en app for at den skal dekke behovet til brukerne, altså en så kalt minimimsløsning (MVP). Vi definerer alltid dette og utvikler disse først, slik at man kan lansere løsningen raskest mulig. Det er mange fordeler med dette.


Det er viktig at ekte brukere raskest mulig kan ta i bruk en app. Dette gjør at man kan se hvordan markedet mottar konseptet. Husk; før du lanserer en app vet du ikke om funksjonene du har i appen er det markedet egentlig ønsker. Den eneste måten å finne ut dette på er å teste på ekte brukere, få feedback, for så å itterere seg fram til en best mulig løsning. Om man utvikler noe innovativt er det sjeldent man treffer spikeren på hodet på første forsøk, og derfor må man raskest mulig komme seg ut i markedet for å teste og lære.


«Kjekt-å-ha-funksjoner» er funksjoner man egentlig ikke må ha for å dekke et behov, men som kan være kjekke å ha. Dette er funksjonalitet som gjerne kan være i en app, men vi anbefaler ikke å lansere disse på et tidlig tidspunkt.


For mange funksjoner som kun er kjekke å ha kan gjøre en app rotete, som går utover brukervennligheten. Men viktigst, du vet ikke hva brukere egentlig vil ha før du tester i markedet. Å lansere for mange funksjoner vil gjøre at man bommer mer, som gir en unødvendig økning i utviklingskostnader.


«En bruker bør forstå hvordan en app fungerer første gang han/hun åpner den.»

Bruk et design-språk brukerne er vant til

En bruker bør forstå hvordan en app fungerer første gang han/hun åpner den. Herunder er det naturligvis viktig å ikke ha for mange funksjoner. Det er også viktig å bruke et design-språk brukerne er vant til.


Vi anbefaler å følge Apple og Google sine guidelines for design. Dette betyr at en iPhone-app vil se ut som en iPhone app, og en Android-app se ut som en Android-app. Apps bør ikke se helt identiske ut på iOS og Android. Å følge retningslinjene til Apple og Google øker også sjansene for at de anbefaler (featurer) en app.


En app skal først og fremst dekke et behov, ikke se kul ut. Når det er sagt, så er det så klart bra om du klarer begge deler.


Kommentare


bottom of page