User-Centered Design

Most product teams say they're user-centered. Most aren't. The test is simple: can you trace the last three features you shipped back to specific evidence from real users? Not a stakeholder request, not a competitor reaction, not "we thought it would be cool" -- actual user evidence.

User-centered design means the team deeply understands who they're building for, prioritizes solving real problems, and validates designs before investing in full implementation. This isn't a phase at the beginning of a project -- it's a continuous practice that runs alongside every iteration.

The UCD loop

Research -> Synthesize -> Design -> Validate -> Build -> Measure -> Research...

Step	What happens	Who leads
Research	Talk to users, review data, observe behavior (UX research synthesis can accelerate this)	PM + Design
Synthesize	Turn raw findings into actionable insights	PM + Design
Design	Create solutions based on insights	Design + PM
Validate	Test designs with users before building	Design + PM
Build	Implement validated solutions	Engineering
Measure	Track whether the solution achieves the intended outcome	PM + Engineering

The loop never stops. Research informs planning. Validation informs design. Measurement informs the next cycle. Teams that skip steps -- especially validate and measure -- build features that look good in demos but don't solve real problems.

The discovery diamond

Product discovery follows a predictable shape: frame the problem, discover what users need, ideate solutions, then create and validate.

Frame -- define the problem space. What are the business objectives? What constraints exist? Who are we building for?

Discover -- research the user's world. Interviews, observation, analytics, support tickets. The goal is to understand the problem before proposing solutions.

Ideate -- generate multiple solution directions. Design studios, sketching, prototyping. Quantity matters more than quality at this stage.

Create -- build the cheapest thing that tests your hypothesis. A prototype, a landing page, a wizard-of-oz test. Validate before investing in full implementation. (See experiment-driven development for the full validation process.)

This process is iterative and non-linear. You'll cycle back through phases as you learn. That's not a failure -- it's the process working.

Design principles

Principle	What it means in practice
Balance	Design, product, and engineering contribute equally to decisions -- a balanced team. Design is not a service function
Focus	Solve the problem in front of you. Resist the urge to redesign everything
Curiosity	Ask "why?" relentlessly. Understand the user's world before proposing solutions
Lean	Validate with the cheapest artifact possible -- a sketch, a prototype, a 5-minute test
Inclusivity	Design for the full range of users, abilities, and contexts -- not just the power users you interview most often
Iteration	Every design is a hypothesis. Ship it, measure it, learn from it, improve it

Research methods

Method	When to use	Effort
User interviews (30-45 min)	Understanding needs, motivations, pain points	Medium
Usability tests (15-30 min)	Validating a design or prototype with real users	Medium
Survey	Quantifying a known question across many users	Low-Medium
Analytics review	Understanding what users do today	Low
Support ticket review	Finding common pain points	Low
Competitive analysis	Understanding the landscape	Low
A/B testing	Comparing two approaches with real usage data	Medium-High

Design studio

A design studio is a structured session where the whole team -- PM, design, engineering -- generates and critiques solution ideas together.

When to use it: You have a well-defined problem but need multiple solution directions before committing.

Format (60-90 minutes):

1. Frame the problem (5 min) -- present the user problem, constraints, and success criteria
2. Sketch individually (10 min) -- everyone sketches 6-8 rough ideas on paper. Quantity over quality. No talking.
3. Present and critique (3 min per person) -- critique ideas, not people. "How does this solve the user's problem?"
4. Iterate individually (10 min) -- refine one idea based on feedback
5. Present round 2 (3 min per person) -- present refined concepts
6. Converge (10 min) -- select 1-2 directions to prototype and validate

Everyone sketches, including engineers and PMs. Stick figures are fine. The point is ideas, not polish.

Interview execution

The empathy model: expose, observe, engage

Expose -- enter the user's environment. Experience their context before asking questions.

Observe -- watch how they work:

• What are they doing? Concrete actions, steps, tools
• How are they doing it? Workarounds, sequences, effort level
• Why might they be doing it? Motivations, constraints, goals (verify in the engage step)

Engage -- ask open-ended questions. Seek stories, not yes/no answers. Replace "why did you..." with "what led you to..." Capture three channels: what you see, what you hear, and emotional signals.

Interview team: 2-3 people. One leads the conversation, one takes notes and captures emotional signals. Don't fill silences -- let the user think.

Common pitfalls

• Building without research -- "We know what users want" is almost always wrong. Talk to them.
• Research without action -- if research doesn't change priorities or designs, it was wasted effort
• Only talking to power users -- your most vocal users aren't representative. Include new users, churned users, and edge cases
• Validating too late -- test designs before engineering starts. A usability test on a prototype costs hours. A redesign after build costs weeks
• Confusing outputs with outcomes -- "Ship feature X" is an output. "Reduce time to complete task Y by 50%" is an outcome. Optimize for outcomes.

Try this today

Pick one feature your team recently shipped. Find 3 users and ask them to complete the core task using it while you watch. Don't guide them, don't explain. Just observe. What you learn in 30 minutes will reshape how you think about the next iteration.