DARD

A PRD answers "what are we building?" DARD asks the two questions that never get written down: "how are we designing it, and how will we know if it worked?" That's the gap I went after. Design decisions disappear. The reasoning evaporates, the rejected ideas vanish, and nobody goes back to check the call after launch. I read ten of the most popular product-planning templates and they all missed the same three things: no "why this design," no record of what got killed, no post-launch verdict. So I wrote the counterpart a PRD never had: a document format any team can pick up, that captures why a design decision was made and whether it actually worked.

The sharpest idea in it, and the reason the format exists. Most frameworks model two outcomes. The design worked: people got it right away: fast actions, no workarounds, no confusion. Or the design failed visibly: people got stuck, and you hear about it: support tickets, angry feedback, drop-offs. DARD names the third outcome: people worked around it. The task completes, the metrics stay green, and what shows up in the data is nothing. That's the problem. The design has quietly failed because users routed past it, and no dashboard is built to notice.

Design worked · design failed loudly · design failed silently; the third one produces no signal at all.

Out of that falls the line I'd defend hardest: design success is not product success: measure them separately. A feature can hit its product numbers on the back of a design people are fighting, and a clean flow can sit inside a product that's failing for reasons that have nothing to do with the design. Conflate the two and you can't tell which lever you actually pulled. DARD keeps the axes apart so each one can be read honestly.

The structure is where the systems thinking shows. Seven parts, and the format's real content is the timing, over and above the list. Each part is pinned to the moment its question is actually answerable, so the document fills itself along the way instead of being reconstructed from memory at the end.

Before you start: why I designed it this way; the guiding principles and, just as deliberately, the rejected alternatives, because killed ideas are institutional memory. And what went into this: the design system, the accessibility and brand rules, the research, the stakeholder pressure that shaped the frame.

While you work: the decision log, kept live, on one discipline: a decision without a trigger is just a preference. Preferences don't get logged; calls with reasons do.

Before handoff: what I know versus what I'm guessing, laid out on a 2×2 of confidence, with a hard rule attached: any guess must have a test before it ships. An untested guess is undocumented risk. Alongside it, what I expect to happen: the design's own success criteria, written down before anyone can retrofit them to the outcome.

Before launch: how I'll measure the design, built backwards on purpose. Write the thesis first; the signals derive from it. Metrics chosen after the fact don't measure the design; they flatter it.

Then, about thirty days after launch: what actually happened. The site calls it what it is: the most important part, and the most skipped. It's the part that turns a design document into a design record, and it's where a silent failure finally becomes visible.

DARD runs two ways. Alongside a PRD, holding the design reasoning the PRD was never built to hold. Or as the starting point, when there's no product document at all: early features, small teams, design-led work. Either way it's additive: nothing in the existing process has to move.

Three conditions, and if they hold, the format fits: design decisions affect how people experience the thing, the reasoning behind those decisions isn't written down anywhere, and silent failure is possible. That's a wide net by design: software and apps, service design, AI products, voice and chat interfaces, design systems, even civic and policy design. Anywhere a person can quietly route around a decision someone forgot they made.

The whole format is seven parts; the entry point is three. Take one live feature. Fill in part 1 (why it was designed this way), part 4 (what went into it), and part 6 (what actually happened). Then look at part 6 and ask whether it surfaced anything you didn't already know. If it did, the format just paid for itself on a single feature, and it compounds from there. One filled-out DARD is a good document. Ten of them is a design brain: a team's accumulated record of what was decided, why, and whether it held.

Honestly: the format is written, the site is live, and it's built for teams in general; nothing enforces it yet, and no process has proven it. That's the right shape for a stake in the ground. The point of view underneath it is settled (decisions need triggers, guesses need tests, signals derive from the thesis, and design gets measured on its own axis), and the framework around it is openly still maturing. The next step is the obvious one: a real, filled-in DARD on a real project. Until then, this is the argument, stated clearly enough to be disagreed with.