Keeping a useful design decision log

A few months into a project, we found ourselves discussing the same navigation choice for the third time. Everyone remembered a different reason for the original decision. The mockups showed what we had chosen, but they did not explain why.

Record the question while it is still fresh

We started keeping a small decision log beside the project notes. Each entry began with a concrete question, such as whether saved items belonged in the main navigation or within a project.

The next paragraph described what we knew. We linked the relevant research notes and separated observations from assumptions. “Two participants looked for this in the sidebar” was more useful than “users expect this here.”

Keep the rejected option understandable

We recorded the strongest alternative and the reason we did not choose it at that moment. That helped future teammates understand the tradeoff without having to reconstruct a meeting from scattered comments.

A decision log should make it easier to change your mind when the evidence changes.

Each entry ended with a condition for revisiting the choice. For the navigation, that was the introduction of shared saved collections. For a form, it might be recurring support questions or a new requirement.

Make the habit small enough to keep

Most entries took less than ten minutes and fit on one screen. We wrote them during the work, while the context was available, and reviewed open questions at the start of the next design session.

The log did not replace conversation. It gave conversation a starting point. When the project changed direction, we could identify which assumptions had changed and move forward without treating every old choice as a mystery.