Design: User Needs

The most common design failure is building the wrong thing well. People don't articulate needs — they articulate solutions. "I want a faster horse," "I need a bigger inbox," "give me more options." These are requests framed as solutions to problems the user hasn't quite stated. A designer who takes them at face value will build a faster horse, a bigger inbox, more options — and miss the underlying need entirely.

Clayton Christensen's jobs-to-be-done framework makes the shift explicit: people don't buy products, they hire them to do a job. Understanding the job — not the product request — is the designer's actual brief. Don Norman extended this with the distinction between stated needs (what people say), observed needs (what people do), and latent needs (what people don't yet know they need but would recognise immediately if you showed them). All three matter. Only one of them is given to you directly.

This skill works through all three levels, using structured inquiry to separate the real need from the stated proxy and surface the design target that actually matters.

Your Process

Step 1: State the Request Write down exactly what was asked for, in the words it was stated. Preserve the phrasing — the precise language reveals how the person is framing the problem.