Build the Foundation, or Keep Repeating the Same Mistake

Most teams don't fail because their research was wrong. They fail because they never did any, then act surprised when the same problem shows up on the next project, and the one after that.

Design research is the systematic work of understanding who you're building for, what they actually need, and where the current landscape sits before a single screen gets designed. It covers a wide range of methods: user interviews, exploratory studies, observational research, longitudinal studies, surveys, card sorting, usability testing, and contextual inquiry. None of it is exotic.
Most of it is cheap, fast, and well understood.

Yet across our research into 270+ organisations and conversations with more than 90 design directors, the pattern holds: teams treat research as a nice-to-have, wheeled out when there's spare time and abandoned the moment a deadline tightens. It becomes an exploratory, way-finding exercise: useful for orientation, optional for delivery.

That reflects the low maturity of the organisation and its ability to adopt.

The instinct is to blame research itself when things go wrong: "we did the interviews and still missed the mark," or "the client already knew what they wanted, so we skipped it and shipped." Both stories protect the same assumption: research is a variable you can include or cut depending on time and budget.

We flipped it. Most companies don't fail because research let them down. They fail because they never invested in it as a foundation in the first place, then wonder why the same problems — unclear requirements, disputed scope, late-stage rebuilds — keep resurfacing project after project and costing them the refactoring of a well-known feature bug or low conversion rate.

The evidence sits inside Design at Scale™ Method: not having a basic Project Identification Document, the artefact research is supposed to produce, inevitably impacts the project, driving refactoring rates up by roughly 50% on the design side and 70% on the engineering side. That’s not a research failure. That’s the cost of skipping it.

And the pattern repeats: if teams also decide to skip Show and Tell, the practice of reviewing work-in-progress with the wider business, they see 35% less awareness of what’s actually being built and a further 62% more refactoring before release. Whenever a foundational check gets skipped, the cost doesn’t disappear. It reappears later, dressed up as a different problem.

We put it plainly in the Book, after reviewing 274 design methods across two decades of practice: there is "a significant gap between exploration and actual delivery." Exploration, the very phase design research is meant to own, is routinely treated as separate from delivery rather than foundational to it.

This is exactly why Design at Scale™ doesn't treat research as a phase you sometimes reach for. It sits inside Canvas, the Mobilise stage of our pipeline, the discovery and definition work that has to happen before Proposition Shaping can even begin.

And it isn't left vague. Under Proposition Shaping, our Customer Research tool asks a direct question: is the proposition based on business or user needs, is that documented anywhere, and does it define a target market? Under Design Shaping, Validation of Landscape Analysis via Prototypes asks you to prove the function actually works, not assume it; we connect the dots between problem and solution.

Neither of these demands a six-week study, extra budget and 20 meetings to confirm the obvious. They demand a habit: research that produces a documented, shareable artefact, not a folder of sticky notes nobody revisits. That’s the distinction DaS™ draws between scaling and flipping design: scaling builds the foundation once and reuses it; flipping skips it, ships fast, and pays later in rework.

"We don't have the budget for research" is the most common objection, and it’s the wrong comparison. The real cost isn't the research you didn't do; it's the 50-70% refactoring bill you pay instead on a project that already shipped.

"The client already knows what they want" is the second. Maybe they do. But knowing what you want and having it documented, tested with real users, and agreed upon across business, design, and development are different things. A PiD isn’t bureaucracy for its own sake; in medical terms, it's a nervous system that is constantly checking (against this single artefact) whether there are five different people carrying five different assumptions into a build.

"Research slows us down" is the third and most persistent. In practice, it's the opposite. One Product Owner we worked with cut a research phase from a proposed six weeks down to three days: five interviews, one landscape scan, one card sort. The project still shipped on time, without the three-week rebuild everyone else expected. Just-in-time research costs days, not months—refactoring costs weeks.

The failure isn't research going wrong. It's research that never becomes part of the foundation, never written down, never revisited, never treated as a mandatory entry point (source) before a proposition is considered "shaped".

Before your next kickoff, ask one question: where's the documented evidence this proposition is worth building? If you can't point to it, you already know what to fix first. Explore more Supply resources on building that foundation at designatscale.co/spy.

REFERENCES

• Design at Scale™ — Book: How Individuals Shape Future Organisations Through Design, Section 2.0 The Method (internal)
• Design at Scale™ — Journal (internal)
• Adam Fard, "What is Design Research?", Medium — method inventory reference only
• Imagination Lab, Lancaster University, "So, what is Design Research anyway (and how can it help you)?" — method inventory reference only

SUMMARY

• Companies rarely fail because research misled them — they fail because they never built research into the foundation of how they work.
• DaS™'s own data show that skipping the foundational research artefact (the PiD) drives refactoring up by ~50% in design and ~70% in engineering.
• Design research belongs in Canvas (Mobilise) and feeds directly into Framework's Proposition Shaping (Customer Research) and Design Shaping (landscape validation) tools.
• The fix isn't more research; it's making research a documented, mandatory habit rather than an optional extra.
• Just-in-time research costs days; the refactoring it prevents costs weeks.

https://www.figma.com/community/file/1292155897408873114/das-design-research-process