Structured analysis works when you can theorize potential causes and test them. However, for problems where the causes are "unknown unknowns," design thinking is superior. It starts with user empathy and observation to build a theory from the ground up, rather than imposing one prematurely.

Related Insights

Building delightful products isn't guesswork. A four-step process involves: 1) identifying functional and emotional user motivators, 2) turning them into opportunities, 3) ideating solutions and classifying them, and 4) validating them against a checklist for things like inclusivity and business impact.

Users aren't product designers; they can only identify problems and create workarounds with the tools they have. Their feature requests represent these workarounds, not the optimal solution. A researcher's job is to uncover the deeper, underlying problem.

Data's role is to reveal reality and identify problems or opportunities (the "what" and "where"). It cannot prescribe the solution. The creative, inventive process of design is still required to determine "how" to solve the problem effectively.

Conventional innovation starts with a well-defined problem. Afeyan argues this is limiting. A more powerful approach is to search for new value pools by exploring problems and potential solutions in parallel, allowing for unexpected discoveries that problem-first thinking would miss.

When handed a specific solution to build, don't just execute. Reverse-engineer the intended customer behavior and outcome. This creates an opportunity to define better success metrics, pressure-test the underlying problem, and potentially propose more effective solutions in the future.

Adopted from visual identity design, this framework involves building products while anticipating future, unknown contexts. It means considering how a user's mood, location, or time of day might affect their experience and designing flexible systems to meet them where they are.

Instead of immediately building, engage AI in a Socratic dialogue. Set rules like "ask one question at a time" and "probe assumptions." This structured conversation clarifies the problem and user scenarios, essentially replacing initial team brainstorming sessions and creating a better final prompt for prototyping tools.

Instead of faking expertise, openly admitting ignorance about technical details builds trust and empowers specialists. This allows you to focus on the 'what' and 'why' of the user experience, giving engineers and designers the autonomy to own the 'how', which fosters a more collaborative and effective environment.