Design decisions get made constantly: in reviews, in Slack threads, in passing conversations. Most of them disappear. This post is about why capturing those decisions matters, and what a lightweight approach to doing it actually looks like.
The problem with guesswork
When teams can't explain why a design looks the way it does, they're in trouble. Not because the design is necessarily wrong (it might be exactly right), but because the next person to touch it has no foundation to build on. They make a change, something breaks, and nobody knows why, because the original reasoning was never written down.
This is especially common in public sector services, where teams rotate frequently, projects span years, and the people who made early decisions are rarely around to explain them. The result is what I think of as accumulated guesswork: decisions that look arbitrary because the rationale has been lost, even when it was well-considered at the time.
What design decision tracking actually is
It's not a process overhead. It's not a document you fill in at the end of a sprint. It's a lightweight habit of recording three things alongside any significant design decision: what you decided, why you decided it, and what you considered and ruled out.
That's it. It doesn't need to live in a special tool. It doesn't need to be formatted a particular way. It just needs to exist, somewhere the team can find it, in plain language that someone who wasn't in the room can understand.
In practice
On the projects I've worked on, the most useful version of decision tracking has been a single Figma page or a short wiki entry per significant design choice, linked directly from the relevant component or screen. The person reviewing the design can see the rationale without having to ask for it. The person joining the team mid-project has somewhere to start.
The key thing is that it has to be maintained. A decision log that's six months out of date is worse than no decision log, because it creates false confidence. Someone needs to own it, not as a full-time job, but as a recognised part of how the team works.
Standards versus quality
One thing I've found worth being explicit about: meeting a standard and doing quality work are not the same thing. A service can pass a GDS assessment and still be confusing to use. A component can comply with WCAG and still create unnecessary friction.
Standards set a floor. Quality is about what you do above the floor. Decision tracking helps teams articulate both: it shows that you understood the standard and made a deliberate choice about how to go beyond it, or about why the standard was the right endpoint for this particular case.
This distinction matters most when teams are challenged on their decisions by stakeholders or assessors. Being able to say "we considered X, ruled it out because of Y, and chose Z because of Z" is a fundamentally different position to "that's just how it is."
Conclusion
Design decision tracking is one of the cheapest investments a team can make in the long-term quality of their service. The effort is low. The payoff, in reduced rework, faster onboarding, and clearer stakeholder conversations, compounds over time.
The best version of it is invisible: it just becomes how the team works, not something anyone thinks of as extra effort. Getting there takes time, and it takes someone willing to model the behaviour until it sticks.