How can a large business
Keep track of
customer communication?
2025 - Fremtind summer internship
As part of a cross-disciplinary summer internship at Fremtind, I joined a team of designers and developers from UiO and NTNU to improve how the company works with customer messages — the emails and texts that trigger key actions, like signing insurance agreements.
Our task was to design a more transparent and efficient solution for managing these messages, many of which were created or edited through slow, manual processes. We didn’t know much about this system when we started — but over seven intense weeks, we dove deep into the backend, talked to key stakeholders, and built a working prototype we named Veter.
Want to jump to a Demo & lessons learned? Go here →
Improving communication from the inside out
-
I took on a bit of a leadership role in the project, drawing on previous experience from design work and internships. I helped coordinate between design and development, facilitated prioritization discussions, and made sure we stayed aligned as the scope evolved. I also contributed hands-on to UX flows, UI design, user testing, and workshop planning.
-
Fullstack MVP, user research, message system, REST API, Jøkul design system, database structure, version control, approval flows, Figma, usability testing, stakeholder interviews, design critiques, collaborative prototyping.
-
This project was part of a 7-week summer internship at Fremtind in Oslo, 2025.
Meet Veter
We called our solution Veter — a word that means "signal fire" in Norwegian dialect, traditionally used to send alerts across long distances.
It felt fitting: our tool helps Fremtind send clear, timely messages to customers — and keep track of everything behind the scenes.
Our process
1) understand
We started the project with very little prior knowledge about the messaging system. So our first goal was to understand how messages were created, stored, and updated — and where the pain points were.
To do this, we:
Interviewed stakeholders: text owners, developers, and architects
Read documentation and mapped out current processes
Sketched early ideas using Crazy 8s
Held workshops and created a prioritization matrix
We learned that small text edits could take weeks to reach production. Text owners had little visibility into the process, and developers were spending time on manual database edits that could be avoided.
2) Design
Based on our insights, we identified a clear scope for our MVP. Our goal was to give text owners more control, reduce dependency on developers, and make the process transparent from start to finish.
We designed Veter to include:
A dashboard for viewing all messages in one place
Editing and version history features
A flow for submitting and approving change proposals
Support for connecting messages to multiple distributors (like DNB and Sparebank1)
We worked iteratively in Figma, gathering feedback through user testing with real text owners and weekly design critiques. We also aligned our designs closely with Jøkul, Fremtind’s design system, to ensure consistency and feasibility.
3) Develop
While designing, we also built a working MVP in parallel — collaborating tightly across design and development.
The MVP included:
A backend with REST endpoints for retrieving, editing, and saving messages
A database setup to support message history and relationships
A frontend using Jøkul components for layout and interaction
Not everything made it into the prototype — features like preview mode and variable support remained in Figma — but we delivered a solid foundation that could be built on. More importantly, we proved that the concept worked and could significantly improve the current process.
Demo of veter 🏆👩🏼💻
We built a working MVP where users can:
View and search through messages
Edit message content and attributes
Submit changes for approval
Track history and see what’s active
This is the Figma sketch for the MVP, which closely resembled the finished product 💫🏆
This demo, as well as our process was presented for a large audicence at Fremtind, and recived alot of positive feedback (and questions on when Veter is ready to use) 🤩 🙌🏻
Lessons learned 💭
Working on Veter gave us hands-on experience with the complexity of internal tools — and how design decisions can have a big impact on everyday workflows.
Assumptions are easy to make (and dangerous).
Early on documentation hinted towards users wanting a “draft” feature. We assumed users wanted to save unfinished work. But through testing, we learned the real need was for a review step — making sure texts weren’t published immediately, but approved by someone else first.Complex ≠ better.
Some early ideas tried to cover every scenario, but they quickly became hard to use and build. We had to simplify — and learned that clarity often matters more than completeness.Design and dev have to move together.
We worked in parallel across design and development, which helped us move quickly — but also created versioning issues and technical limitations. Frequent check-ins were key to staying aligned.
These lessons helped shape not just Veter, but how we approached collaboration, prioritization, and user needs throughout the project.
