Start From the User

Good products and designs begin from the needs of the people who will use them and reason backward to the solution, rather than starting from the technology, the implementation, or internal convenience. The user's experience is the fixed point; everything else is negotiable in service of it.

Reinforced By

• Human-Centered Design — start from the real needs and behavior of the people who will use something, and iterate against them.
• Working Backwards — start from the desired customer experience and reason back to what to build.
• Product Discovery — test what is worth building against real users before committing to it, so the user's need, not the roadmap, decides what gets made.
• Interviewing for Needs — ground understanding in specific stories of real customer behavior rather than stated preferences, so the user you design for is the real one.

Why it Matters

The Design of Everyday Things makes the case for objects and interfaces: design fails when it is built around the technology or the designer's assumptions instead of observed human behavior, so you start from human needs and iterate. Working Backwards makes the same case for products: define the desired customer experience first, in a press release written before the product exists, and work back to what to build. Across artifact design and product strategy the discipline is identical, anchor on the person and let needs pull the solution into existence, rather than pushing technology out in search of a user. Inspired operationalizes the same principle inside product teams: discovery exists to validate that an idea solves a real user problem before engineering builds it, so the user's need, not an internal roadmap, decides what is worth making. Continuous Discovery Habits turns it into a weekly habit, keeping the team in steady contact with real customers so the connection to the user never goes stale.

Tension

Starting from the user competes with starting from what is feasible or cheap, and users cannot always articulate what they need, so "listen to the user" must mean observing behavior and inferring needs, not taking requests literally.