Reducing Design Risk — Smashing Magazine

Where Research Happens Changes What You Learn

Teams feel constant pressure to compress discovery and usability testing. That pressure leads directly to designs based on assumptions rather than evidence. The costs are measurable: lost revenue, expensive support calls, and products that miss the mark entirely.

One technique for reducing that risk is paying close attention to where research takes place. A quiet meeting room is convenient, but it can hide the conditions that actually shape how people use a product.

When a manufacturer of large construction equipment needed UX research, bringing operators to a calm showroom seemed like the obvious approach. It would have been the wrong one. Instead, the research team traveled to construction sites across the U.S., Mexico, and Colombia to observe equipment in its real environment — dusty, loud, and demanding.

Those on-site observations surfaced what interviews in a clean room never would have:

• Wind and noise created collision risks even with the equipment's visibility features.
• Shorter operators, common in Latin American crews, had trouble reaching controls designed for taller U.S. operators.
• Salt exposure from a coastal construction site rapidly corroded metal components.

Observing real work environments reduces the chance of solving the wrong problem. It eliminates reliance on second-hand descriptions and produces findings directly relevant to design decisions.

Compromise Isn't a Weakness

A cautionary example comes from Walmart's experiment with store redesigns. Management ran a customer survey asking whether stores felt cluttered. The answer was yes — so they spent millions removing aisles and shelving. The result: a billion-dollar revenue drop and a subsequent return to the old layout.

The failure illustrates a gap between what people say and what they do. As retail researcher Paco Underhill observed, shoppers consistently describe behavior differently than what researchers witness in person.

Qualitative observation — shop-alongs, ride-alongs, contextual inquiry — is expensive, and stakeholders naturally press to accelerate the moment a study ends. That is where compromise matters. Between research completion and design implementation, resisting the urge to skip analysis prevents important insights from being lost.

The goal isn't endless reflection; it's striking a workable balance. When researchers receive adequate time to synthesize findings, two things happen: the design team gets actionable direction, and trust is built between research and product leadership.

The Endowment Effect in Design

Good relationships and better decisions are linked, but human psychology gets in the way. The endowment effect is the documented tendency to overvalue things you already possess. It applies as much to a product manager's UI as it does to a home seller's asking price.

While evaluating a programmable logic controller, one product manager stood in front of his colleagues and declared: "My name is Jim, and I love this product." The field usability data didn't persuade him — customer complaints indicated the interface was problematic, but Jim was emotionally attached.

Less than five percent of leaders surveyed for McKinsey's design study said their executives could make objective design decisions. The endowment effect is one obstacle among many, and awareness alone helps even if it doesn't eliminate the bias.

Edit Down the Design

Even the most enthusiastic product owners eventually face the question of what to remove.

A typical mobile app iteration shows the problem clearly. When everything competes for attention — numerous buttons, labels, and color blocks — nothing wins. Removing elements carefully, without sacrificing essential functionality, results in a cleaner experience better suited to users' actual decision-making patterns.

Making the Case for Less

Persuading stakeholders that removal counts as progress is often harder than the editing itself. Practical techniques include pointing out the cognitive burden of heavy interfaces and showing teams how even moderately detailed screens slow users' ability to find key controls.

A demonstration can be persuasive: share a crowded UI from an existing app, time team members while they try to locate a single feature, and then contrast it with a reduced version with the same functionality. Seeing the slowdown live often carries the point farther than arguments alone.

Video clips from this company's own prior usability research can illustrate first-hand how users travel through — or abandon — busy screens. Coupling the case with data from past user tests strengthens the recommendation further.

Here are common techniques that support reductions:

• Start the conversation around heavy cognitive load before anyone mentions the feature list.
• Ask the team to respond to concrete comparison UIs rather than abstract design theory.
• Reuse recorded research that shows attachment to unnecessary elements in older builds.