What a decision log is for
A project can change direction for good reasons: a deadline moves, a test reveals a confusing interaction, or a client clarifies what matters most. Weeks later, the final choice may still be visible, but the reasoning behind it is harder to find. A decision log gives that reasoning a durable home. It is a short, searchable record of choices that affect the work, the alternatives considered, and the circumstances that shaped the choice.
The log is not a transcript of every conversation or a substitute for the project brief. Use it for decisions someone may need to understand, follow or revisit. A freelance designer might record why a simpler page layout replaced a more elaborate concept. A student team might record why it narrowed a prototype’s scope. A small team might record why it chose one handoff process over another. In each case, the goal is to make the choice understandable to someone who was not in the room.
Give each entry a small, consistent structure
Keep entries brief enough to write while the details are fresh. A useful entry includes a descriptive title, the date, the decision owner or participants, the choice made, the reason for it, the main alternatives, and any next step. Add links to relevant drafts, feedback or task records when they exist. If the choice is temporary, note what would prompt a review. Consistent fields make the log easier to scan than a collection of differently written meeting notes.
For example: “Navigation for the portfolio site: use a single Projects page rather than separate pages for each project type. Reason: the current collection is small, and the shared page makes it easier to compare work. Alternative: separate category pages, which may become useful as the collection grows. Follow-up: revisit when adding new projects makes the page difficult to browse.” This entry explains the present choice without pretending it will always be right.
Record the reasoning, not just the result
“We chose option B” is an announcement, not a useful decision record. Explain which requirements or constraints mattered most. Those might include the audience’s needs, the available time, accessibility considerations, maintenance effort, or what the team learned from feedback. Where the evidence is incomplete, say so. “We chose this approach to meet the handoff deadline; we have not yet tested it with new users” is more helpful than a confident claim the project cannot support.
It also helps to distinguish a decision from the discussion around it. Summarize the strongest alternative and why it was not chosen, rather than documenting every suggestion or attributing every comment. Focus on trade-offs, not on who won an argument. If an entry involves sensitive client details or personal feedback, keep the shared log appropriately limited and link to a restricted record only when needed.
Make logging part of the workflow
Choose one place for the log, such as a shared document or a dedicated page in the project workspace. Give each entry a clear title and keep the newest entries easy to find. A log scattered across chat threads, task comments and private notebooks is difficult to use, even if each individual note is well written. Link an entry from the task or deliverable it affects so collaborators can move between the decision and the work.
Decide when an entry is warranted. A useful rule is to log a choice if it changes scope, affects several people, reverses an earlier plan, or is likely to prompt “Why did we do this?” later. At the end of a review meeting, the person responsible can confirm the choice and add a short entry. If no choice was made, record an open question elsewhere rather than presenting it as settled. This keeps the log focused and trustworthy.
Use the log during delivery and review
A decision log earns its place when people consult it. Before changing a settled approach, check what constraint led to it and whether that constraint still applies. When preparing a handoff, use relevant entries to explain intentional trade-offs that may not be obvious in the finished files. During a retrospective, compare the reasoning with what happened. A choice that did not work out can still be a valuable record if the original assumptions are clear.
Update an entry when its status changes, but preserve the earlier reasoning. For example, mark a temporary choice as replaced and link to the newer decision rather than rewriting history. Over time, this creates a readable path through the project: what the team knew, what it chose, and why it changed course. Start with the next consequential choice your project faces. One clear entry is more useful than an elaborate template nobody maintains.
