Here's a situation that will feel familiar.
You're in construction documents. A detail question comes up: something about how a transition condition is handled at a specific location. You're pretty sure this was decided in schematic design. You remember the conversation. You might even remember what the answer was.
But you cannot find where it was documented.
You check your email. You check the meeting minutes. You search the project folder. Twenty minutes later, you either reconstruct the decision from memory (with low confidence) or you make the call again, hoping it matches what was decided the first time.
This is a design decision tracking problem. And it's one of the most common — and most preventable. Sources of rework, inconsistency, and project friction.
Why Design Decisions Are Hard to Track
Decisions on a design project don't happen in neat, documented batches. They happen in hallway conversations, on phone calls, in the middle of a design review meeting, via email thread buried under thirty other threads, and sometimes as informal agreements that everyone assumes someone else wrote down.
The design process is also nonlinear. You make a decision in week three, revisit it in week seven when a structural constraint changes, and finalize it in week twelve. But the documentation from all three of those moments lives in different places, if it lives anywhere at all.
Most firms handle this by relying on meeting minutes as their primary record. Meeting minutes are better than nothing. But they're not organized for retrieval, they're organized chronologically, which means finding a specific decision requires reading through weeks of notes looking for the relevant entry.
What a Decision Log Actually Looks Like
A design decision log is exactly what it sounds like: a running record of decisions made on the project, organized by topic rather than by date.
The simplest version is a shared spreadsheet with these columns:
| Decision # | Date | Description | Made By | Related Scope | Status | Notes |
|---|
Breaking down what each column is for:
Decision #, a sequential number. Lets you reference decisions by number in other documents ("see Decision 47 for the basis of this detail").
Date: when the decision was made, not when you documented it.
Description. — a clear, one or two sentence statement of what was decided. "The exterior cladding at the north elevation will be fiber cement panel in lieu of metal panel, per the client's direction on 3/14." Not "cladding discussion." The description should be specific enough that someone who wasn't in the room understands what was decided and why.
Made By.: who authorized the decision. For decisions that required client approval, note that explicitly.
Related Scope. — which part of the project this affects. Helps with retrieval — if you're looking for everything related to the lobby, you can filter by scope rather than scrolling through dates.
Status. — open, confirmed, or superseded. When a decision gets revisited and changed, mark the old entry as superseded and create a new one. Don't delete old entries: the record of what changed and when is valuable.
Notes. — links to the meeting minutes where it was discussed, the email thread where the client confirmed it, or any other supporting documentation.
When to Capture Decisions
The log only works if it's updated as decisions are made: not reconstructed at the end of the week from memory.
The practical trigger is the end of any meeting or call where a decision was made. Before you close your laptop, add the decision to the log. Two minutes now saves twenty minutes later.
For decisions that happen outside of formal meetings — the hallway conversation, the quick call — the habit is harder to build but more important. These are the decisions most likely to be lost. A simple rule: if you made a design decision, it goes in the log before end of day.
Some firms assign one person per project to maintain the log, that works if the person is disciplined and present for all the relevant conversations. A more resilient approach is making it a shared responsibility, anyone on the team who makes or witnesses a decision is responsible for logging it.
Making the Log Retrievable
A decision log you can't search is nearly as bad as no log at all.
If you're working in a spreadsheet, filters are your friend. Tag decisions with consistent terminology. The same word for the same scope area every time — so filtering actually works. If you use "lobby" in some entries and "ground floor entry" in others, you'll miss results when you search.
For larger projects, some teams use a tag system: structural, envelope, interiors, MEP coordination, client-directed, code-driven. A decision can have multiple tags. When you need to find everything related to a specific discipline or scope area, you filter by tag.
The goal is to be able to answer "what did we decide about X?" in under two minutes, regardless of when the decision was made.
Connecting Decisions to the Rest of the Project
A decision log is most useful when it's connected to the other documentation on the project, not siloed in its own spreadsheet.
When you issue revised drawings, reference the decision number that drove the revision. When you write a response to a design review comment, link to the decision that established the direction. When a contractor asks why something is detailed a certain way during construction, you can point to the decision and the date it was made.
This cross-referencing does two things: it makes the decision log feel worth maintaining (because people actually use it), and it creates an audit trail that's genuinely useful if a dispute arises later.
The Realistic Bar
Perfection is the enemy of actually doing this.
You won't capture every decision. Some will slip through. That's fine. A decision log that captures 85% of decisions is enormously more useful than the alternative. The goal isn't a perfect record — it's a reliable enough record that you can find what you need when you need it.
Start simple. A shared spreadsheet, a consistent format, a team habit of updating it after every meeting. That's the whole system. Add complexity later if you need it.
The test is simple: six months from now, when someone asks "what did we decide about the storefront at the east entry and why?", can you find the answer in two minutes? If yes, the system is working.