Reducing Design Risk Through Assumptions and Feedback with Chuck Moore | Episode #60

Chuck Moore's path into design began in advertising, where he learned to identify the problem a brand was trying to solve and communicate in ways that moved people to act. As digital technology created more dynamic forms of interaction, he became interested in how products could communicate meaning through an experience rather than through static print or television work.

After moving from New York to the West Coast in 2000, Chuck joined Wells Fargo and worked on online banking, including bill pay. The pace of change inside a large financial institution could be difficult, but projects exploring what the future might hold showed him another possibility: design could help large organizations align around a shared direction. He later met one of DesignMap's founders, joined the firm, and returned to Wells Fargo for another vision-focused engagement.

In this conversation with Dwayne Samuels, Chuck explains how communication builds client trust, how teams should respond when concept feedback is divided, and why experiments should target the assumptions that create the most risk. He also examines AI from two sides: as a tool within design work and as a capability that must earn a meaningful place in a customer's product.

What you'll learn

• How every meeting, artifact, and deliverable can strengthen or weaken client trust

• Why evenly divided concept feedback may mean none of the options solves the underlying problem

• How assumption workshops can focus experiments on the largest sources of risk

• Why a north star can align several teams while still leaving room for iteration

• How to evaluate whether AI supports a real need without removing meaningful parts of work

Build trust through the work itself

DesignMap often enters an organization as an outside partner. That position can bring a useful new perspective, but it also creates an immediate need for trust. Chuck says communication is embedded in the entire engagement, from how a meeting is run to how a deliverable is presented. Each touchpoint teaches the client something about what comes next and about how the two groups will work together.

This approach also helps expand a client's understanding of design. Some large organizations may still treat design mainly as a way to make software look good. Chuck's team tries to demonstrate a broader role throughout every phase and artifact. Design can help people learn together, create alignment, and connect product and technology decisions to user needs.

The practical lesson is not to reserve communication for a final presentation. Teams can make the process itself legible. Explain what is being learned, show how evidence affects direction, and use each deliverable to clarify shared responsibility. That consistency helps an outside design team and an internal client understand that they are contributing different strengths to the same outcome.

Turn feedback into focused experiments

Chuck cautions against treating a small set of interviews as a vote. People working in the same domain, such as IT administration or cybersecurity, may share problems and expectations without giving identical answers. Teams have to look across sources and triangulate a path forward.

Strong disagreement can itself be evidence. If participants split evenly among three concepts, the result does not necessarily mean the team should select one. It may indicate that all three miss what people need and that the team should return to the problem for deeper investigation. Feedback guides the next cycle rather than automatically dictating a feature.

For Chuck, a successful experiment starts with a clear account of what the team knows, what it does not know, and which assumptions create the greatest risk. DesignMap can begin with a workshop that names those assumptions and builds agreement around them. Research, workshops, and other activities can then seek answers to the questions those assumptions raise. Success is learning something that reduces uncertainty, not merely confirming a preferred concept.

A north star gives this learning a larger frame. Several teams can work on different initiatives while moving toward the same future direction. Breaking that direction into smaller efforts makes room for iteration without losing alignment.

Give AI a meaningful role

Chuck describes two design questions around large language models. First, can AI help designers complete tedious work or improve analysis and synthesis? Second, can it be integrated into a client's product in a way users understand, trust, and find useful? Excitement about new technology is not enough. DesignMap uses activities that ask whether a meaningful need exists before recommending an AI direction.

He also distinguishes work that needs to happen from work that gives people meaning. A physician's notes, for example, support documentation and compliance, but writing them can also help the physician reflect on an encounter and reconsider treatment. Automating the entire task could remove both burden and a valuable thinking step. Product teams therefore need to separate what should be automated from what should remain a human opportunity for reflection.

Listen to Episode #60

The standard Chuck offers is useful beyond AI: begin with the need, identify the risky assumptions, and design each experiment to produce evidence the team can act on.