Skydd. So young boaters can get home safely.
- Client
- Nautilus Sjø AS (part of Kystrederiene)
- Context
- Bachelor’s project, Kristiania University College, January to May 2025
- Team
- 5 people (three interaction designers, two developers)
- My role
- Interaction designer and test lead
- Tools
- Figma, FigJam, Scrumwise. Built in React Native and Firebase.
In a nutshell
- We designed and delivered a working app that turns the pre-departure safety check into something teenagers actually want to complete. The gamification elements actually serve a purpose. They’re not just for show.
- I was responsible for the design process and led all 15 user tests spread over two rounds. Halfway through, I changed our testing methodology because the initial approach yielded weak data.
- The client formally approved the finished app and described our team as “well-coordinated, disciplined, and professional.” In the final round of testing, 7 out of 7 users said they would use it.
15
User tests
7 out of 7
Would use the app
2
Test rounds
The problem
There were 39 deaths at sea in Norway in 2024.
And the numbers are heading in the wrong direction. The Norwegian Maritime Authority has a “zero vision” for deaths at sea. Our client, Nautilus Sjø, wanted to reach a specific group that current tools overlook: young boaters who borrow the family boat. Apps like RS SafeTrx focus on rescue after an accident has already occurred. There’s nothing on the market that helps a 16-year-old avoid the accident in the first place, or gives parents who hand over the keys a reason to relax.
The mission: a mobile app where young boaters conduct a risk assessment before setting out, with notifications sent to parents. The primary target group is ages 12 to 20, with parents as the secondary group.
Who we designed for
Henrik, 19
Young boaterHas just passed his boating license exam and received a boat from his family for his birthday. Uses it for leisure and often takes his friends along on trips. Knows basic boating safety, but may underestimate risks.
Key need: A pre-departure check that’s quick enough to actually be done, and reassuring enough for parents to relax.
Anette, 47
ParentHenrik’s mother. Doesn’t drive a boat herself and has little knowledge of boating. Gets anxious every time the boat leaves the dock.
Key need: To know that the checklist has been completed, and where the boat is if something happens.
Pernille, 12
Young boaterDrives with friends; has a 9.9-horsepower motor used for short distances.
Key need: To be able to go on short boat trips with friends in a safe and easy way, with guidance on the checklist, risks, and what to do if something unexpected happens.
Per-Ivar, 43
ParentIs Pernille’s father. Has a keen interest in boats and boating. Drives a Goldfish 28 Bullet.
Key need: To be able to give Pernille freedom on the water, while ensuring his own peace of mind through safety checks, alerts, and oversight in case something happens.
My role
As part of a team of five, I was responsible for design and testing. Concept development in FigJam, wireframes, the design system, the high-fidelity prototype, and the planning, execution, and analysis of all user tests.
The process, including what went wrong
We adopted a “design-first” principle early on: nothing would be built until it had been tested on people from the target groups.
- Research
- Concept
- Prototype
- Test ×2
- Build
Round one taught us about our users, and at least as much about our methodology. I conducted the wireframe test with 8 participants and deliberately kept it unstructured. I let people explore, talk, and react. It revealed real problems. Users ignored the emergency contacts within the app because they trusted their phone’s own contact list more. Several users ended up stuck without back buttons. Half of the testers completely misunderstood the e-learning module. But the loose format also gave us inconsistent data from session to session, and some of the youngest participants dropped out along the way.
So I changed the method. For round two, I wrote a structured protocol: ten fixed tasks and ten fixed questions, in the same order for everyone. The difference was immediate. The results were comparable across all seven sessions, and we could rank findings by frequency and severity instead of discussing anecdotes. All the issues from round one were confirmed to be resolved, and the new round revealed next-level needs, such as family sharing of boats and contacts, rather than basic usability flaws.
Selected findings from both test rounds.
| Finding | Frequency | Severity | Status |
|---|---|---|---|
| Navigation via the bottom bar worked well | 7 of 8 | Positive | Kept |
| The e-learning module was misunderstood | 4 of 8 | High | Rebuilt; confirmed fixed in round two |
| Dead ends without back buttons | 3 of 8 | High | Fixed; confirmed in round two |
| Dedicated emergency contacts in the app felt unnecessary | 2 of 8 | High | Feature removed |
| Dark mode requested | 1 of 8 | Request | Noted for version two |
| Finding | Frequency | Severity | Status |
|---|---|---|---|
| Navigation was simple and intuitive | 7 of 7 | Positive | Kept |
| The checklist was easy to use | 7 of 7 | Positive | Kept |
| Would use the app | 7 of 7 | Positive | Main result |
| Wanted clearer onboarding | 2 of 7 | Medium | Recommended for version two |
| Family sharing of boats and contacts | 1 of 7 | Request | Our most important recommendation for version two |
The design is playful, but never at the expense of clarity. The safety feedback uses traffic light colors, with a separate mode for color-blind users and text for each status, so that no information relies solely on color. The Rubik font ensures readability on small screens. A dark maritime blue background, calm enough to inspire trust, yet with enough space to make the app feel lively. The gamification elements followed the Octalysis framework rather than gut instinct: a progress indicator and small animations for each completed step. Duolingo-style mechanics, tailored for life jackets. Testers said the app felt fun and that the safety check felt less like a chore. That was exactly what we were after.
Choices I stand by
Prevention over rescue.
We positioned Skydd in the one gap the market had left open: before departure, not after a crisis.
Structure over spontaneity in testing.
We sacrificed some flexibility but gained actionable data. I’d make the same trade-off again. But the freedom in round one also served its purpose. It captured the insight about the contact list, something a script might have overlooked.
Removing our own feature.
Emergency contacts in the app obviously felt useful to us. Users disagreed, so the feature was scrapped. The phone already does that job better.
Personality in a security product.
Friendly language and playful animation, wrapped around strict contrast requirements and accessibility checks. User-friendly and distinctive are not mutually exclusive. That was the task itself.
The result
A fully functional cross-platform app (React Native and Firebase), delivered and formally approved by Nautilus Sjø in accordance with the requirements set at the start of the project. The CEO described the team as “well-coordinated, disciplined, and professional” and highlighted their ability to think holistically. All seven testers in the final round said they would use the app if it were launched.
well-coordinated, disciplined, and professional
CEO, Nautilus Sjø · upon formal delivery
What I would have done differently
Two things. Verify accessibility with real users instead of just designing according to the guidelines. We built a mode for color-blind users but never tested it on color-blind users. Build family sharing for boats and contacts from day one. That topped our own recommendations for version two.