Skydd. Så unge båtførere kommer trygt hjem.
- Oppdragsgiver
- Nautilus Sjø AS (del av Kystrederiene)
- Kontekst
- Bachelorprosjekt, Høyskolen Kristiania, januar til mai 2025
- Team
- 5 personer (tre interaksjonsdesignere, to utviklere)
- Min rolle
- Interaksjonsdesigner og testleder
- Verktøy
- Figma, FigJam, Scrumwise. Bygget i React Native og Firebase.
Kort fortalt
- Vi designet og leverte en fungerende app som gjør sikkerhetssjekken før avreise til noe tenåringer faktisk har lyst til å fullføre. Gamification-elementene har faktisk en jobb å gjøre. De er ikke bare til pynt.
- Jeg sto for designprosessen og ledet alle 15 brukertestene fordelt over to runder. Halvveis endret jeg testmetodikken vår, fordi den første tilnærmingen ga oss svake data.
- Oppdragsgiveren godkjente den ferdige appen formelt og beskrev teamet vårt som «godt koordinerte, disiplinerte og profesjonelle». I siste testrunde sa 7 av 7 brukere at de ville brukt den.
15
Brukertester
7 av 7
Ville brukt appen
2
Testrunder
Problemet
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 spesifikk gruppe som 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. Det er ingenting på markedet som hjelper en 16-åring med å unngå ulykken i utgangspunktet, 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 alderen 12 til 20 år, med foreldre som sekundærgruppe.
Hvem vi designet for
Henrik, 19
Ung båtførerHar nettopp tatt båtførerprøven og fått båt av familien til bursdag. Bruker den til fritid og tar ofte med seg kameratene sine på tur. Kan grunnleggende sjøvett, men kan undervurdere risiko.
Viktigste behov: En sjekk før avreise som er rask nok til faktisk å bli gjort, og betryggende nok til at foreldrene kan slappe av.
Anette, 47
ForelderHenrik sin mor. Kjører ikke båt selv og har lite båtkunnskaper. Urolig hver gang båten forlater brygga.
Viktigste behov: Å vite at sjekklisten er gjort, og hvor båten er hvis noe skjer.
Pernille, 12
Ung båtførerKjører båt med venninner, har en 9,9 hester som brukes til korte distanser.
Viktigste behov: Å kunne dra på korte båtturer med venninner på en trygg og enkel måte, med hjelp til sjekkliste, risiko og hva hun skal gjøre hvis noe uforutsett skjer.
Per-Ivar, 43
ForelderEr far til Pernille. Stor interesse for båt og båtliv. Kjører Goldfish 28 Bullet.
Viktigste behov: Å kunne gi Pernille frihet på sjøen, samtidig som han får trygghet gjennom sikkerhetssjekk, varsler og oversikt hvis noe skulle skje.
Min rolle
I et team på fem hadde jeg ansvaret for design og testing. Konseptutvikling i FigJam, wireframes, designsystemet, high-fidelity-prototypen, og planlegging, gjennomføring og analyse av samtlige brukertester.
Prosessen, 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.
- Research
- Concept
- Prototype
- Test ×2
- Build
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. La folk utforske, snakke, reagere. 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. Halvparten av testerne misforsto e-læringsmodulen fullstendig. Men det løse formatet ga oss også sprikende data fra økt til økt, og noen av de yngste deltakerne falt av underveis.
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. Forskjellen var umiddelbar. 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, og den nye runden avdekket ønsker på neste nivå, som familiedeling av båter og kontakter, i stedet for grunnleggende brukervennlighetsfeil.
Utvalgte funn fra begge testrundene.
| Funn | Hyppighet | Alvorlighetsgrad | Status |
|---|---|---|---|
| Navigasjon via navbaren fungerte godt | 7 av 8 | Positiv | Beholdt |
| E-læringsmodulen ble misforstått | 4 av 8 | Høy | Bygget om, bekreftet løst i runde to |
| Blindveier uten tilbakeknapper | 3 av 8 | Høy | Løst, bekreftet i runde to |
| Dedikerte nødkontakter i appen føltes unødvendige | 2 av 8 | Høy | Funksjonen fjernet |
| Mørk modus ønsket | 1 av 8 | Ønske | Notert til versjon to |
| Funn | Hyppighet | Alvorlighetsgrad | Status |
|---|---|---|---|
| Navigasjonen enkel og intuitiv | 7 av 7 | Positiv | Beholdt |
| Sjekklisten enkel å bruke | 7 av 7 | Positiv | Beholdt |
| Ville brukt appen | 7 av 7 | Positiv | Hovedresultatet |
| Ønsket tydeligere onboarding | 2 av 7 | Middels | Anbefalt til versjon to |
| Familiedeling av båter og kontakter | 1 av 7 | Ønske | Vår viktigste anbefaling til versjon to |
Designet er lekent, men aldri på bekostning av tydelighet. Sikkerhetstilbakemeldingene bruker trafikklysfarger, med en egen modus for fargeblinde og tekst på hver tilstand, slik at ingen informasjon bor i fargen alene. Rubik-fonten for lesbarhet på små skjermer. En mørk maritim blåfarge i bunn, rolig nok til å skape tillit, med nok rom til at appen føles levende. Gamification-grepene fulgte Octalysis-rammeverket i stedet for magefølelse: fremdriftsindikator og små animasjoner for hvert fullførte punkt. Duolingo-mekanikk, rettet mot redningsvester. Testerne sa appen føltes morsom og at 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å. Jeg ville gjort samme bytte igjen. Men friheten i runde én gjorde også nytten sin. Den 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. Telefonen gjør den jobben bedre allerede.
Personlighet i et sikkerhetsprodukt.
Vennlig språk og leken animasjon, pakket rundt strenge kontrastkrav og tilgjengelighetssjekker. Brukervennlig og særpreget er ikke motsetninger. Det var selve oppgaven.
Resultatet
En fungerende kryssplattform-app (React Native og Firebase), levert og formelt godkjent av Nautilus Sjø mot kravene som ble satt ved prosjektstart. Daglig leder beskrev teamet som «godt koordinerte, disiplinerte og profesjonelle» og trakk frem evnen til å tenke helhetlig. Alle sju testerne i siste runde sa de ville brukt appen om den ble lansert.
godt koordinerte, disiplinerte og profesjonelle
Daglig leder, Nautilus Sjø · ved formell levering
Hva jeg ville gjort annerledes
To ting. Verifisere tilgjengelighet med reelle brukere i stedet for bare å designe etter retningslinjene. Vi bygde en modus for fargeblinde, men testet den aldri på fargeblinde. Bygge familiedeling av båter og kontakter fra dag én. Den toppet våre egne anbefalinger til versjon to.