FOUR SELECTED CASES
I have owned products from first concept to implemented solution and through post launch iterations. In two of these I defined the brief myself. In the two others it was given and I delivered within given constraints.
Mendi
Case 01 · HANDED OFF
A marketplace with three roles in one ecosystem: customer, tailor and admin. I was asked to redesign screens, mapped the platform in a flow diagram, found the failure was trust in the flow, and expanded the brief. Shows information architecture across roles, admin tooling, and prioritisation under hard constraints.
Lind
Case 02 · CONCEPT
A self-initiated concept for public mental health care, grounded in waiting-time documentation from the Norwegian Directorate of Health. Shows that I frame a problem before anyone asks me to, and design for people in a vulnerable situation with plain language and accessibility as premises.
Ravina
Case 03 · SHIPPED
My first company and my first digital product, launched in 2021, with a B2B dashboard and a B2C app in the same service. Shows ownership from idea to launch, a pivot made on test data, and the lesson that changed how I work.
Oppned
Case 04 · TBD
An online store with mobile AR and an integration between CMS and e-commerce. Shows how I bring in the tools and integrations that make a product work in practice.
The thread through all four
I design dependency out of products, so that users and teams can act on their own.
Mendi
Customer service went from a fixed step in the flow to a tool for exceptions, and the admin dashboard collects what the team needs on one surface.
Oppned
I set up the content structure in CMS so the studio can manage the store on its own, including the AR layer that lets customers visualise a product at home before buying.
Ravina and Lind
The onboarding is built so the user understands the service before asking for anything.
VENTURE CASES

Ravina · venture
Four tests before the pivot

La Pomme
350 kr before I committed
Method
My priority is understanding the problem behind the need. That is how I balance user needs and business goals.
01
Insight
I test the product myself and map complex systems in flow diagrams before I propose anything. I gather user insight where it exists: interviews in person or over screen share, feedback across channels, and the team that already knows the users. I research the domain and market to understand what the product has to be to hold, including regulatory and security requirements.
02
Prototyping
I test assumptions in working prototypes before we spend developer time — either to establish shared understanding with the engineers, or to put competing hypotheses against each other. All interface copy I write in plain language, including help text, error messages and form labels.
03
Testing
Qualitative to see where hesitation appears, quantitative where the volume is large enough to measure proportions. I treat qualitative findings as direction rather than proof. With small samples I say how many people I spoke to, and I separate what I have seen from what I am assuming.
04
Documentation
Issues sorted by severity against user needs and business goals, and split into what must be in place before launch and what can wait (Linear, Github).
05
AI
AI moved my time from production to product thinking. I build testable apps in Lovable and Figma Make, either for new functionality or before developer time is spent. I built Mendi's admin dashboard with Retool AI, then reworked it and connected it to the database myself. AI synthesises interviews and test notes faster, but I draw the conclusions myself against the recordings.
06
Handover
In writing, so the product can be run without me.
About
Since 2020 I have owned products from problem-framing to delivered solution.
I map complex systems before I propose anything, and structure the information so each role gets what it needs to act. I test assumptions in working prototypes before we spend developer time, balancing user needs against business goals and technical constraints in one decision.
A background in psychology keeps me focused on what sits behind the need, particularly for users deciding under pressure. I give as much attention to the flow across roles as to the detail in the one screen nobody has thought about.
I have been responsible for the whole thing: design system, roadmap, funding, handover. I made the calls, and the best ones came from thinking them through with engineers first. Now I want to do it with people who are better than me at parts of it. A team, a mature design system, and a product that gets to keep running.
Open to roles in Oslo. If you have a product where several groups have to act for it to work, I would like to hear about it.