How I design AI products.

1. LLM output patterns

At Geofy, I designed an interface where AI-generated prospect dialogue led users into a screening interface. The core challenge was that AI output varied — sometimes short, sometimes long, sometimes off. I had to design for robustness against variable output: truncation, overflow, empty states, and unexpected formatting. That's the fundamental challenge with any LLM-driven UI — you can never assume what the output looks like.

2. Feedback loops

At OwnU, I designed the feedback mechanisms behind AI-generated workout recommendations. Users could provide lightweight feedback through simple thumbs up/down interactions, creating a continuous learning loop between user behaviour and future recommendations. The focus was on designing feedback collection that felt effortless and embedded in the experience, generating high-quality signals without interrupting the user's flow.

3. Latency as a UX constraint

LLM calls take 2–10 seconds. That fundamentally changes interaction design. You can't have a button that just "loads." At OwnU, instead of showing a generic spinner while the AI generated a personalised workout plan, we designed a progressive disclosure pattern — surfacing intermediate steps like "Analysing your training history…" and "Adapting to your goals…" so the wait became part of the experience. The same principle applies to any AI feature that processes data in the background: the latency window is a design opportunity, not dead time.

4. Human-in-the-loop mechanics

AI should never take a consequential action without a clear human review step. At Geofy, every AI-qualified lead passed through a human screening interface before any action was taken — the reviewer could see exactly what the AI had collected, adjust it, and decide whether to proceed. At OwnU, the AI fitness coach never silently changed a user's training plan — every adaptation was surfaced as a suggestion the user could accept, modify, or override. The design challenge is making that review step feel lightweight and natural, not like an extra hurdle. Clear "Edit", "Approve" and "Override" actions, with confidence signals that make the AI's reasoning visible when it matters.

5. A combined example: Geofy / Elvy

At Geofy I designed a full AI-driven lead qualification flow where AI handled the initial prospect dialogue, steered leads through qualification steps, and handed them off to a human screening interface at the right moment. That handoff moment — designing what the human sees, what the AI has collected, and where human judgment takes over — is exactly the core challenge in any B2B SaaS AI feature. It combines all four patterns: variable output, feedback, latency and human-in-the-loop in one flow.

6. A second combined example: Fremtind

At Fremtind I designed a next-generation car insurance product built entirely on machine learning. Instead of historical risk tables, the ML model analysed each driver's actual behaviour in real time — It generated a completely personalised insurance price for that specific person.

This created every major AI design challenge simultaneously.

Variable output at scale. Every user saw a different price, different behavioural insights, and different recommendations — all generated by the ML model. The UI had to be robust against that variability: Layouts that worked whether your risk score was excellent or poor. Copy that felt fair regardless of the outcome. Empty states for when sensor data wasn't yet available.

Making AI decisions trustworthy. An insurance price generated by an algorithm feels arbitrary unless you can see why. I designed a transparency layer that showed users exactly which driving behaviours were influencing their price — speeding, phone use, braking patterns — The AI's reasoning was visible and actionable. Not a black box.

Human-in-the-loop through behaviour. The user couldn't override the AI's price directly — but they could change the inputs. The entire gamification layer was designed around this: giving users agency over their own data by showing them which behaviours to change and what the price impact would be. The human override wasn't a button. It was the product itself.

Latency as a constraint. Meaningful sensor data took time to accumulate. New users had no driving history, so the AI had nothing to work with. I designed an onboarding arc that set expectations clearly — explaining that the price would become more personalised over time — The latency of the ML model felt like a feature rather than a limitation.

7. Failure & Recovery

AI systems are inherently probabilistic, which means failure is not an edge case — it is part of the core system behaviour. Designing for AI therefore requires designing for when the model is wrong, uncertain, or produces incomplete output.

At Geofy and OwnU, I treated AI failure as a first-class design problem. Outputs could be misaligned, missing context, or overly confident without justification. Instead of hiding these cases, I designed interfaces that made failure legible and recoverable.

This included clear regeneration paths, editable AI outputs, and interfaces that allowed users to correct or refine results without restarting the entire flow. In more complex flows, I designed escalation paths where users could move from AI-generated suggestions to human review when confidence or quality dropped.

The key principle was simple: AI should never create dead ends. Every output — good or bad — should give the user a clear next step: adjust, retry, override, or escalate.