A simple document that captures why you made design decisions — and whether they actually worked.
What are we building?
How are we designing it — and how will we know if it worked?
Every design has a story. Why this button and not that one. What you tried first. What you threw out. But that story lives in your head — and when you move on, it's gone forever.
We looked at 10 of the most popular product planning templates. Every single one was missing the same things.
Nobody documents why they chose one approach over another. Future you — and your teammates — are left guessing.
You tried three other approaches before landing on this one. That thinking? Gone. The next designer will try the same dead ends.
Did the design actually work? Nobody goes back to find out. So nothing gets learned, and nothing gets better.
Users can finish a task and still mean the design failed. They just worked around it. Product numbers look fine. The design is broken.
We call this silent failure — and it's the thing every other framework misses.
Users found what they needed, trusted what they saw, and did the right thing — because the design made it obvious.
Support tickets flew in. People complained. The failure was obvious within a week. At least you knew!
Users finished the task — but not because the design helped. They found a workaround. Metrics looked great. The design quietly failed.
Most design frameworks only work when there's already a product document to follow. DARD works either way.
The PRD documents product decisions. DARD documents design decisions. They run at the same time, not one after the other.
Got a Jira ticket, a Slack message, or nothing at all? DARD helps you think through the design before you open Figma. It forces the right questions early.
DARD has 7 components. You don't fill them all at once — each one has a moment when it makes sense to write it.
What principle guided you. What you chose. What you didn't choose — and why.
A running record of every design call you make — and what triggered it. Not just what you decided, but why you decided it then.
A simple 2×2 grid. Have you tested this choice? Are you confident? Each box tells you what to do next — ship it, test it, or watch it carefully.
Design system, accessibility needs, brand rules, user research, what other teams told you. Everything that shaped the design, written down.
What does success look like from a design perspective? Not just "did it ship" — but did it feel right, did people get it, did it help the design system?
The most important part. The most skipped part. Go back 30 days after launch and answer: did it work? What surprised you? What was wrong?
Before you look at any data, write down: what would I see if it worked? What would I see if it failed silently? Then go find those signals after launch.
DARD isn't just for software. It works anywhere three things are true.
Design decisions are being made that affect how people experience something.
Those decisions are currently undocumented — nobody's writing down the why.
Failure can be silent — users can work around the design without anyone noticing.
The original home. Every screen, every interaction, every state.
Waiting rooms, intake flows, staff scripts. Silent failure is everywhere in services.
The most urgent gap right now. Nobody is documenting AI UX decisions.
No Figma file exists. DARD is perfect — it doesn't need one.
Every component was a decision. Why does that button look like that? DARD remembers.
Highest silent failure cost. The people who worked around it often had no voice to report it.
You don't have to fill out all 7 components right away. Start small. The value shows up fast.
Anything in flight right now. Doesn't have to be big. In fact, smaller is better to start.
Why you designed it this way. What went into it. And what actually happened 30 days later.
If Part 6 surfaces one thing nobody else caught — DARD has earned its place on your team.