The UX Design Process

The foundation of the design cycle. We set aside our assumptions to gain deep insight into users and their lives. Understand the why behind user behavior.

• Let go of assumptions
• Look for "unknown unknowns"
• Observe users in their actual environment
• Find the workarounds they've created — problems they might not even realize they have

Processes: ethnographic research (interviews), contextual inquiry, longitudinal diary studies, storyboarding, journey mapping, stakeholder interviews

Frame the point of view from multiple users to paint the picture of what needs to be solved.

• Define desires and pain points
• Move past "what they want" to "why they want it"
• "A busy parent needs a way to feel connected to their child's education despite their 60-hour work week"
• Users can describe pain, but they can't always diagnose the problem with the system

Processes: user stories, problem statements, personas, landscape analysis, taxonomy & schema mapping

Many organizations jump straight here — skipping Empathize and Define entirely. They design for business directives and PM backlogs, not for users. That's how you ship features nobody asked for.

The real purpose of this phase isn't to find the solution. It's to build material that helps us discuss the problem. A rough prototype surfaces assumptions we didn't know we had. It forces conversations that no spec document ever could.

• Build rough, disposable prototypes to test our understanding of the problem, not to validate a solution
• Loop back to Empathize and Define constantly — every prototype that fails is sharpening the problem definition
• Only once we truly understand the problem can we design the right solution

Processes: sketching, mind-mapping, "worst possible idea", Wizard of Oz prototypes, heuristic evaluation, cognitive walkthrough

The goal of most testing should not be to validate that the product is 'useable'. Most testing should be spent validating that we are solving the right problems. Without knowing the problem we are solving, we cannot make a product that improves people's lives.

There's a difference between a product that is 'useable' (i.e. the tasks given were completed), and a product that addresses the user's most critical needs.

• Often, testing a prototype reveals that we defined the wrong problem entirely.
• Most of testing should be about validating problem definitions.
• More budget spent here saves multiples on saved development later.

Processes: think-aloud protocol, problem-validation interviews, assumption mapping, card sorting, sacrificial concept testing, usability testing, A/B testing, occlusion testing

Political realities often get in the way of the research and design cycle. When business directives and tight release timelines put constraints on what must be delivered, research is often the first thing to go.

Great political capital must be spent to change this process and change is often slower than we want. In the meantime we can:

• Empathize with the stakeholders (PM's, Product Leads, and engineers) — they have lives too!
• Run lightweight validation with fellow designers or engineers
• Lean on design heuristics and landscape analysis — decades of established interaction patterns and competitors exist for our benefit
• Build the case for research with data (document every assumption made)
• Invest political capital only on the highest-risk features where skipping research will cost the most downstream