My Design Process – The Five Stages of UX

Years ago, while building a management system for Norwegian driving schools, I spent days sitting in classrooms watching instructors juggle paper schedules, phone calls, and impatient students. Nothing in the project brief had prepared me for what I saw there. That experience taught me the lesson that has shaped fifteen years of designing digital products: great user experience doesn't happen by accident. It emerges from a disciplined process that keeps users — real ones, in their real context — at the center of every decision.

And "real context" matters more than we often admit. The people I design for are rarely calm, focused users sitting in a quiet office. Working with public institutions, NGOs, and organizations like the Equality and Anti-Discrimination Ombud means designing for people who arrive stressed, in crisis, or navigating a system in their second or third language. Someone searching an ombud's website about discrimination they've just experienced is not browsing — they're coping. Their attention is fragmented, their reading comprehension reduced, their patience for confusing navigation near zero.

This is why I treat universal design not as a compliance checklist, but as a mindset that runs through every stage of my process. Frameworks like WCAG and W3C's COGA (Cognitive Accessibility) design goals aren't add-ons at the end — they inform how I research, analyze, ideate, validate, and iterate.

My workflow revolves around five interconnected stages: Understand, Analyze, Ideate, Validate, and Iterate. These aren't theoretical concepts — they're practical phases I move through on every project. What makes the approach work in practice is combining qualitative research with quantitative data, using privacy-first, open-source analytics. Let me walk you through how these stages play out in my day-to-day work.

1. Understand: Starting With the User's Reality

Every project begins with understanding. Not assumptions, not stakeholder opinions, but actual insight into how people experience the problem you're trying to solve.

I start by talking directly with users. Real conversations, not just survey checkboxes. I want to hear their frustrations in their own words, watch them struggle with current solutions, and understand the context in which they'll use what I'm building. For the driving school system, this meant sitting in classrooms, talking to instructors, and observing how they actually managed their day-to-day operations.

Part of understanding is asking: in what state will people use this? A parent filling out a school application at 23:00 after a long shift. A person reporting discrimination while still shaken by it. Stress and crisis change how the brain works — focus fragments, tunnel vision sets in, and the ability to interpret vague language drops sharply. If my research only captures users at their calmest, I'm designing for a person who may not exist at the moment of use.

But interviews only tell part of the story. People often can't articulate exactly what they do, or they describe their idealized behavior rather than their actual habits. This is where behavioral data becomes invaluable. With analytics running, I can see patterns users themselves might not recognize: which features they actually use versus which ones they say they use, where they consistently get stuck, which paths different segments take through the interface.

The key is treating both sources as equally important. Interviews give me the "why" behind behaviors. Analytics show me the "what" at scale. Together, they create a complete picture of the user's reality.

2. Analyze: Finding Patterns in the Noise

Understanding generates a mountain of information — interview transcripts, survey responses, analytics dashboards, support tickets. Analysis is about transforming that raw material into actionable insights.

I look for patterns across all these sources. When three different users describe the same frustration, that's a signal. When analytics show a 60% drop-off at a specific step that users also complained about in interviews, that's a priority issue.

Journey mapping helps me visualize how problems connect. Maybe users aren't failing at one discrete point — maybe there's a cumulative frustration building across multiple interactions. Funnel analysis shows me exactly where people abandon processes, while heatmaps reveal which elements they interact with and which they ignore.

I also analyze through an accessibility lens: are drop-offs concentrated in steps that demand memory, dense reading, or unfamiliar jargon? Those are exactly the barriers that hit hardest for users with cognitive disabilities — and for anyone under acute stress.

For the Equality and Anti-Discrimination Ombud's website, this phase revealed that users were looking for specific case precedents but getting lost in general information architecture. High search usage and short time-on-page for category landing pages told the story: people were bouncing because they couldn't quickly assess whether the content was relevant to their situation. For a visitor already in a difficult situation, that kind of dead end isn't a minor annoyance — it can be the point where they give up on getting help at all.

What I'm really doing in this phase is building empathy at scale. Individual user stories give me emotional connection to the problem. Data shows me how widespread each issue is and helps me prioritize what to tackle first.

3. Ideate: Generating Solutions Grounded in Evidence

With a clear problem definition, I can start exploring solutions. But ideation isn't about picking the first idea that sounds good — it's about generating multiple approaches and considering the trade-offs of each.

I sketch a lot in this phase: wireframes, user flows, interface concepts. For any significant problem, I want to explore at least three different approaches before committing to one. This forces me beyond my initial instincts and often leads to hybrid solutions that combine the best aspects of multiple ideas.

The analysis phase creates natural constraints that guide ideation. If I know users are on mobile 70% of the time, I prioritize mobile-first solutions. If session recordings show people repeatedly clicking on something that isn't interactive, I need to either make it functional or redesign it to be obviously static.

Cognitive accessibility adds constraints of its own, and I treat them as design fuel rather than limitations. COGA's design goals translate directly into ideation principles: make it obvious what things are and how they're used, don't make processes depend on memory, keep language so clear it can't be misunderstood, and give users predictability and control. Concretely, that means solutions with autosave instead of punishing time-outs, plain-language error messages that guide rather than scold, and summaries before irreversible actions like submitting an application or making a payment. For sensitive services, it can mean a quick-exit button.

A/B testing capabilities are crucial here. Rather than endless internal debates about which approach might work better, I can test variations with real users and let the data inform which direction to pursue. This doesn't mean designing by committee or letting analytics make creative decisions — I still bring design judgment and craft to the work. But quantitative validation helps me advocate for the right solution and recognize when my initial instincts were off base.

4. Validate: Testing Before You Build

The validate stage is where many projects fail. Teams get excited about their solution, invest in building it, and only discover problems after launch, when they're expensive to fix.

I validate early and often with prototypes, ranging from paper sketches to high-fidelity interactive prototypes. The fidelity depends on what I'm testing — for fundamental navigation concepts, low-fi is fine; for subtle interaction patterns, I need something more polished.

Who I test with matters as much as what I test. A solution validated only with confident, tech-savvy participants tells me very little about how it performs for the people who need it most. I make a point of recruiting participants with cognitive disabilities, low digital confidence, or limited Norwegian — often in partnership with volunteer organizations and patient associations, who can help arrange testing in surroundings where participants feel safe. You don't know how a solution works until it's been tested by the actual target group, in conditions that resemble their reality.

What I'm testing for isn't whether users "like" the design. I'm testing whether they can accomplish their goals efficiently and without frustration. Can they find what they're looking for? Do they understand how to use key features? Do error messages help them recover, or do they add stress? Are there unexpected confusion points?

For beta features, I can deploy to a limited user segment and monitor actual usage patterns before broader rollout. Sometimes analytics reveal issues that never surfaced in controlled testing — users behaving differently in their natural environment than in a research session.

I've learned that validation isn't about proving you're right. It's about discovering where you're wrong while it's still easy to fix. The ego hit of having a design rejected in testing is nothing compared to the cost of launching something that doesn't work — especially when the people it fails are those with the least capacity to work around it.

5. Iterate: Continuous Improvement Based on Real Usage

Launch isn't the end — it's the beginning of the next cycle. Once something is in production with real users, I can see how it actually performs under real conditions.

Analytics becomes my continuous feedback loop. I monitor goal completions, track new friction points as they emerge, and measure whether design changes actually improved the metrics I care about. Session recordings often reveal usage patterns I never anticipated.

A note on ethics here, because it matters: I deliberately use privacy-first, open-source analytics (Matomo) where the data stays under our control. When your users include people in asylum processes, people seeking help after discrimination, or visitors to sensitive health information, tracking is not a neutral technical choice. These users have real stakes in not being profiled by third parties. Privacy-respecting analytics lets me learn from behavior without betraying the trust the service depends on — and without the consent fatigue that itself adds cognitive load.

This stage feeds directly back into understanding. What new problems have appeared? What assumptions turned out to be wrong? What opportunities did we miss? These insights become the seeds of the next iteration. For the WordPress theme work I do, this cycle is essential: an interface that works perfectly in testing might have edge cases that only appear with real content at scale.

The key is treating iteration as proactive improvement, not reactive firefighting. I'm not waiting for users to complain — I'm actively looking for opportunities to make things better based on how people actually use what I've built.

Necessary for Some, Better for Everyone

The contrast between good and bad UX processes isn't subtle. Bad processes develop features based on internal stakeholder opinions, spend months building without user input, and launch products that miss the mark. Good processes engage users continuously, validate assumptions early, and iterate based on real feedback.

But there's a deeper reason this process works, and it's the same reason I weave accessibility and cognitive load into every stage rather than bolting them on at the end: everyone, at some point, will use a digital service with zero cognitive surplus. Illness, grief, financial crisis, a screaming toddler, plain exhaustion. When I design for people with cognitive disabilities or people in vulnerable situations, I'm designing for a state every user will eventually be in.

The five stages — Understand, Analyze, Ideate, Validate, Iterate — aren't rigid phases you complete once and move on from. They're a cycle you move through repeatedly, each iteration building on the insights from the last. Combined with evidence from real usage and a genuine respect for the humans on the other side of the screen, this approach consistently produces solutions that work when it matters most.

That's the workflow that guides my product and service design.