Don Norman, 2006

“Don’t reason your way to a solution—observe real people.”

Don Norman used this advice while challenging the “engineer’s fallacy,” the belief that logical argument alone can describe how people will behave. He urged designers to accept actual behavior, including preferences and workarounds that may look irrational from inside a technical model. Observation reveals the environment, time pressure, interruptions, social cues, prior knowledge, and competing goals that an abstract requirement misses. Good design works with human capabilities and limitations rather than demanding that users become the person an engineer finds easiest to model. Read closely, the line is not a promise of easy certainty. It asks decision makers to examine the assumptions and conditions behind ordinary results, especially when familiar routines conceal what customers, employees, or the wider system actually experience.

Teams can watch representative people attempt a real task, ask what they expected, and record where the design produces hesitation, error, or recovery. Findings should change prototypes, which are then tested again instead of being defended through a better presentation. Managers can make the principle observable by naming the decision it should change, the evidence they will review, and the person accountable for follow-through. That discipline keeps an admired quotation from becoming wall decoration and turns it into a repeatable way of working.

Observation is not self-explanatory. A small sample can reinforce bias, visible behavior may have several causes, and research can intrude on privacy. Designers need consent, diverse participants, careful interpretation, and complementary quantitative evidence. The useful interpretation keeps ambition and restraint together. Leaders should ask who benefits, who bears the risk, what would disconfirm the current belief, and whether people have a fair way to challenge the decision before a local success is mistaken for a durable one.

AI systems often infer user intent from traces at enormous scale. Direct research remains essential because a click, abandonment, or repeated prompt does not explain the person’s goal, confusion, risk, or adaptation to a poor interface. A design decision should cite the observed behavior it addresses and the follow-up test that will show whether the change truly helped. A practical review can compare the stated promise with customer outcomes, employee experience, operating evidence, and unintended effects. It should record what changed, what remains uncertain, and when the decision will be examined again with documented evidence. The final test is not whether the line sounds inspiring, but whether it helps the organization learn sooner, act more responsibly, and create value that can survive scrutiny over time.