Nautilus Sjø AS · Bachelorprosjekt, Høyskolen Kristiania · Team på 5 · Januar–mai 2025
Skydd. Så unge båtførere kommer trygt hjem.
En sikkerhetsapp som gjør risikovurderingen før avreise til noe tenåringer faktisk har lyst til å fullføre. Jeg sto for designprosessen og ledet alle 15 brukertestene.
01Problemet
Det var 39 dødsfall på sjøen i Norge i 2024.
Og tallene går feil vei. Sjøfartsdirektoratet har en nullvisjon for dødsfall på sjøen. Oppdragsgiveren vår, Nautilus Sjø, ønsket å nå en gruppe dagens verktøy overser: unge båtførere som låner familiebåten. Apper som RS SafeTrx handler om redning etter at ulykken har skjedd. Ingenting hjelper en 16-åring med å unngå ulykken – eller gir foreldrene som leverer fra seg nøklene en grunn til å senke skuldrene.
Oppdraget: en mobilapp der unge båtførere gjennomfører en risikovurdering før avreise, med varsling til foreldre. Primærmålgruppen er 12 til 20 år, med foreldre som sekundærgruppe.
Hvem vi designet for
Henrik, 19
Ung båtfører
Har nettopp tatt båtførerprøven og fått båt av familien til bursdag. Kan grunnleggende sjøvett, men kan undervurdere risiko.
Trenger: En sjekk før avreise som er rask nok til faktisk å bli gjort, og betryggende nok til at foreldrene kan slappe av.
Anette, 47
Forelder
Henrik sin mor. Kjører ikke båt selv og har lite båtkunnskaper. Urolig hver gang båten forlater brygga.
Trenger: Å vite at sjekklisten er gjort, og hvor båten er hvis noe skjer.
Pernille, 12
Ung båtfører
Kjører båt med venninner, har en 9,9 hester som brukes til korte distanser.
Trenger: Hjelp til sjekkliste, risiko og hva hun skal gjøre hvis noe uforutsett skjer.
Per-Ivar, 43
Forelder
Far til Pernille. Stor interesse for båt og båtliv. Kjører Goldfish 28 Bullet.
Trenger: Å gi Pernille frihet på sjøen, med trygghet gjennom sikkerhetssjekk, varsler og oversikt.
02Min rolle
Design og testing, fra FigJam til siste testrunde
I et team på fem (tre interaksjonsdesignere, to utviklere) hadde jeg ansvaret for design og testing: konseptutvikling i FigJam, wireframes, designsystemet, high-fidelity-prototypen, og planlegging, gjennomføring og analyse av samtlige brukertester.
- Team
- 3interaksjonsdesignere2utviklere
- Verktøy
- FigmaFigJamScrumwise
03Prosessen
Inkludert det som gikk galt
Vi la oss tidlig på et design først-prinsipp: ingenting skulle bygges før det var testet på folk fra målgruppene.
- 01
Research
Statistikk, konkurrenter, målgruppe
- 02
Concept
FigJam, personas, flyter
- 03
Prototype
Wireframes → high-fidelity
- 04
Test ×2
8 + 7 deltakere
- 05
Build
React Native + Firebase
Runde én · ustrukturert
Runde én lærte oss om brukerne våre, og minst like mye om metoden vår.
Jeg gjennomførte wireframe-testen med 8 deltakere og holdt den bevisst ustrukturert. Den avdekket reelle problemer: brukerne ignorerte nødkontaktene inne i appen fordi de stolte mer på telefonens egen kontaktliste, flere flyter endte blindt uten tilbakeknapper, og halvparten misforsto e-læringsmodulen. Men det løse formatet ga også sprikende data fra økt til økt.
Runde to · strukturert
Så jeg endret metoden.
Til runde to skrev jeg en strukturert protokoll: ti faste oppgaver og ti faste spørsmål, i samme rekkefølge for alle. Resultatene kunne sammenlignes på tvers av alle sju øktene, og vi kunne rangere funn etter hyppighet og alvorlighetsgrad i stedet for å diskutere anekdoter. Alle problemene fra runde én ble bekreftet løst.
Runde én
Wireframe-test · 8 deltakere
Runde to
Prototypetest · 7 deltakere
Fra wireframe til ferdig skjerm
Færre felter og én tydelig primærknapp. Innloggingen var stedet flest stoppet opp i runde én.


04Designet
Lekent, men aldri på bekostning av tydelighet
Sikkerhetstilbakemeldingene bruker trafikklysfarger, med egen modus for fargeblinde og tekst på hver tilstand, slik at ingen informasjon bor i fargen alene. Rubik for lesbarhet på små skjermer. En mørk maritim blåfarge i bunn, rolig nok til å skape tillit. Gamification-grepene fulgte Octalysis-rammeverket: fremdriftsindikator og små animasjoner for hvert fullførte punkt. Duolingo-mekanikk, rettet mot redningsvester.
Det testerne sa
Appen føltes morsom, og sikkerhetssjekken føltes mindre som mas. Det var akkurat det vi var ute etter.
Valg jeg står for
Forebygging fremfor redning.
Vi plasserte Skydd i det ene hullet markedet hadde latt stå åpent: før avreise, ikke etter en krise.
Struktur fremfor spontanitet i testing.
Vi mistet noe åpenhet og fikk data vi kunne handle på. Men friheten i runde én fanget innsikten om kontaktlisten – noe et manus kanskje hadde oversett.
Å fjerne vår egen funksjon.
Nødkontakter i appen føltes åpenbart nyttig for oss. Brukerne var uenige, så funksjonen røk.
Personlighet i et sikkerhetsprodukt.
Vennlig språk og leken animasjon, pakket rundt strenge kontrastkrav. Brukervennlig og særpreget er ikke motsetninger.
05Resultatet
Levert, godkjent – og 7 av 7 ville brukt den
En fungerende kryssplattform-app (React Native og Firebase), levert og formelt godkjent av Nautilus Sjø mot kravene som ble satt ved prosjektstart. Alle sju testerne i siste runde sa de ville brukt appen om den ble lansert.
«Godt koordinerte, disiplinerte og profesjonelle»
Hva jeg ville gjort annerledes
01Teste tilgjengelighet på ekte brukere
Vi bygde en modus for fargeblinde, men testet den aldri på fargeblinde. Retningslinjer er ikke det samme som verifisering.
02Familiedeling fra dag én
Deling av båter og kontakter var den viktigste anbefalingen til versjon to. Den burde vært i versjon én.


