Creating an Evidence-Based Design Decision Log

Hello. In the previous lesson, you used usability heuristics to identify likely interface problems without treating those findings as proof of user behavior. You now need a way to preserve that reasoning once a team decides what to change.

This final lesson in the foundations module introduces the design decision log: a lightweight, shared record of important choices. By the end, you will be able to set up a log in which each decision can be traced back to a user need, project goal, constraint, and specific evidence. This will become useful throughout the rest of the course: research findings, user flows, wireframes, visual choices, and usability-test revisions all create decisions worth documenting.

---

Why record design decisions?

Design work often produces visible outputs but loses the reasoning behind them. A team can see a redesigned checkout screen, but six weeks later may not remember:

• What problem the change addressed
• Which user need or business goal mattered
• What evidence supported the choice
• Which alternatives were considered
• What trade-offs the team knowingly accepted
• What would make the team revisit the choice

A decision log prevents that loss. It is not a diary of every adjustment made while moving pixels. It is a compact record of meaningful choices, especially choices that affect a core user task, introduce a trade-off, use team time, or may be questioned later.

For example, “Changed button corner radius from 8 px to 10 px” usually does not require a formal record. But “Moved pickup-slot selection earlier in checkout” probably does, because it changes a key task flow and may affect conversion, engineering work, and users’ confidence.

A good log creates a chain of reasoning:

1. A problem, need, or opportunity is identified.
2. The team considers realistic approaches.
3. The team chooses an approach based on available evidence and project goals.
4. The team records consequences and conditions for revisiting the choice.

This does not mean that every decision must be slow or bureaucratic. The log should be proportional to the decision. A reversible visual adjustment can receive a short note. A change to navigation, authentication, payments, or a major workflow deserves a fuller record.

Watch this short explanation of why concise UX documentation matters, particularly when work changes quickly.

The principle is simple: record enough context that a future teammate can understand and evaluate the decision without reconstructing the entire project from memory.

---

The anatomy of a useful decision record

A decision log has two levels:

1. An index, which gives the team a quick overview of decisions.
2. An individual decision record, which holds the reasoning behind one important choice.

The image below shows one way to organize a decision record. It separates the problem, research insights, solution hypothesis, options, follow-up, and source files. The specific layout is flexible; the traceability between these parts is what matters.

The five-part structure below is a reliable core. Add a few practical fields around it, but do not remove the parts that make the rationale understandable.

Part	What it records	Useful prompt
Context	The problem, affected user task, relevant project goal, and constraints	What prompted this decision, and why does it matter now?
Decision	The chosen approach in one clear sentence	What did we decide to do?
Alternatives considered	Plausible options and why they were not selected	What else could we have done, and what trade-off ruled it out?
Evidence	Specific research, analytics, heuristic findings, technical input, or prior knowledge	What supports this choice, and where can someone inspect it?
Consequences	Expected benefits, costs, dependencies, risks, and accepted trade-offs	What becomes easier, harder, required, or uncertain because of this choice?

Read the following guide for a fuller explanation of this structure and two ready-to-use templates.

The critical links: goals, evidence, and choices

A decision record is useful only when it connects three distinct things:

Element	Example	What it is not
Project goal	Help returning shoppers complete pickup checkout confidently	A preferred interface style
Evidence	A heuristic review found that the selected pickup time disappears after the shopper continues	Proof that every shopper will fail
Design choice	Show the selected pickup time persistently in the checkout summary, with a Change control	The goal itself

Keeping these separate protects your thinking.

Suppose a stakeholder says, “Users need more reassurance during checkout.” That is not yet evidence; it is an interpretation or hypothesis. If usability sessions later show that several participants cannot tell whether their pickup slot was saved, that observed behavior becomes evidence. A design choice might then be to display the selected slot in a persistent order summary.

The decision log should state the strength and limits of its evidence. A heuristic evaluation, like the one from the prior lesson, provides a credible expert concern. It does not establish how frequently a real user problem occurs. Record it accurately:

Heuristic review finding: after a shopper selects a pickup slot, the next screen does not show the selected time. This may reduce visibility of system status. Validate this concern in usability testing.

That wording is far more useful than either extreme:

• “The design is definitely broken.”
• “This is only an opinion, so it does not belong in the log.”

---

Set up a decision-log home

For a personal learning project, a shared document, a note-taking workspace, or a dedicated page in your project documentation is enough. Later, you may maintain related source material in Figma, research files, or a team knowledge base. The tool matters less than having one findable location that the team agrees to use.

Start with an index at the top of the document.

ID	Decision	Status	Owner	Linked goal	Evidence	Revisit when
DD-01	Keep pickup selection visible throughout checkout	Proposed	Designer	Confident pickup checkout	Heuristic finding HC-03	After usability testing
DD-02	Use one label for pickup time across checkout	Accepted	Designer	Clear task language	Interface audit	If terminology changes

A simple ID lets you connect a decision to other artifacts without repeating its whole history. For instance, a wireframe annotation might say “See DD-01” rather than re-explaining the rationale beside every screen.

Use statuses consistently:

• Proposed: an option is being considered, but has not been agreed.
• Accepted: the team has chosen the direction and is acting on it.
• Superseded: a newer decision replaced it. Do not delete the old record; link to its replacement.
• Revisited: new evidence or a changed constraint caused the team to reconsider it.

Deleting rejected or superseded reasoning creates a false history. Keeping it helps future collaborators see which assumptions changed.

A practical full-record template

Copy this structure into your decision-log home for choices that affect an important part of the product.

## DD-01: [Decision title]

**Status:** Proposed / Accepted / Superseded  
**Owner:** [Name or role]  
**Date:** [Date]  
**Product area:** [Screen, flow, or feature]  
**Linked project goal:** [User need, business goal, or project objective]  
**Related artifacts:** [Research note, heuristic finding, wireframe, prototype]

### Context
[Describe the problem, user task, project goal, and constraints.]

### Decision
[State the chosen approach in one or two direct sentences.]

### Alternatives considered
1. **[Option]** — Not selected because [reason].
2. **[Option]** — Not selected because [reason].
3. **[Selected option]** — Selected because [reason].

### Evidence
- [Source, date, finding, and link or reference]
- [Source, date, finding, and link or reference]

### Consequences and trade-offs
- **Expected benefit:** [What this should improve]
- **Cost or risk:** [What may become harder or worse]
- **Dependency:** [Who or what else must change]
- **Open question:** [What remains uncertain]

### Follow-up
**Next step:** [Action and owner]  
**Revisit if:** [A condition, new evidence, date, or project change]  

Several fields deserve special care.

Context should be concrete. “Checkout is confusing” is too vague. “The selected pickup slot is not visible after the shopper continues, even though choosing the correct slot is necessary to complete the order” tells a future reader what is actually happening.

Decision is not a list of ideas. It is the committed choice. Write, “We will display the selected pickup date and time in the checkout summary,” rather than, “Maybe add a pickup summary.”

Evidence should be traceable. “Users said they were confused” is weak because no one can inspect it. Prefer a reference such as “Interview synthesis, finding R-04: four participants expected the chosen time to remain visible.” If you do not yet have user research, state what you do have, such as a heuristic finding, and label the evidence limitation.

Consequences should include downsides. A decision that has no apparent cost may not have been examined closely enough. A persistent summary may improve confidence, but it also uses screen space and must remain accurate if a slot expires.

---

Worked example: turning a heuristic finding into a decision

Continue the fictional QuickCart pickup-checkout scenario from the previous lesson. The heuristic review identified this concern:

After selecting a pickup slot, the shopper continues to the next screen without seeing the selected date or time. This may conflict with visibility of system status.

A weak response would be: “Add a pickup banner.” It jumps from a concern to a solution without showing the project reason, other options, or limits of the evidence.

Here is a better initial decision record.

Field	Decision record
Title	DD-01: Keep selected pickup time visible during checkout
Status	Proposed
Product area	Mobile pickup checkout
Linked project goal	Help returning shoppers complete pickup checkout with confidence and avoid unintended collection times
Context	Selecting a pickup slot is required for order completion. After a shopper selects a slot and continues, the following screen does not show the saved date or time. Pickup-slot data can refresh, so the displayed selection must remain accurate.
Decision	Display the current pickup date and time in a persistent checkout summary. Include a clearly labelled Change control that returns the shopper to slot selection.
Alternative 1	Show a temporary confirmation message immediately after selection. Not selected because the information disappears before the shopper reaches later checkout steps.
Alternative 2	Show the pickup time only on the final confirmation screen. Not selected because uncertainty can occur before payment or order submission.
Alternative 3	Use a persistent checkout summary with Change control. Selected because it supports confirmation and correction throughout the task.
Evidence	Heuristic evaluation finding HC-03: the chosen slot is not visible on the following screen, creating a likely visibility-of-system-status concern. This is expert-review evidence, not yet validated user behavior.
Consequences	The summary uses limited mobile screen space. It requires a reliable data update when a slot changes or expires. The Change control adds a recovery path but may require preserving entered checkout information.
Follow-up	Test the checkout prototype with target shoppers. Revisit the decision if shoppers ignore the summary, cannot find Change, or if the updated layout obscures a more critical action.

Notice how this record remains intellectually honest:

• It links a design choice to the project goal of confident completion.
• It names the actual evidence source: a heuristic review.
• It does not claim that user testing has already confirmed the problem.
• It records a technical dependency: the displayed slot must stay current.
• It identifies what evidence would cause a revision.

The follow-up is not an admission that the decision is weak. It is part of responsible iterative design. Most product decisions are made under incomplete information; the important question is whether the uncertainty is visible and whether the team knows what it will check next.

---

Use lightweight records for small, reversible choices

Not every choice needs the full template. A shorter record is appropriate when a decision is low-risk, easy to reverse, and unlikely to create major dependencies.

For example:

Decision: Use “Pickup time” rather than “Fulfilment window” across the checkout flow.
Status: Accepted.
Rationale: “Pickup time” is more familiar, direct language for shoppers and better matches the task they are completing.
Evidence: Heuristic review finding HC-01, match between system and the real world.
Revisit if: Operations requires a different term to distinguish delivery and pickup scheduling.

This takes less than a minute to read, yet it still tells a future teammate why the language was chosen.

A useful rule of thumb:

Use a lightweight record when...	Use a full record when...
The choice is easy to reverse	Reversal would be expensive or disruptive
The impact is limited to a small UI detail	The choice affects navigation, a core flow, accessibility, data, or multiple teams
Evidence needs are low because the cost of being wrong is low	The choice needs strong evidence because the cost of being wrong is high
Few alternatives are realistic	Multiple approaches involve meaningful trade-offs

A short setup routine

Set up your initial log with this routine:

1. Create one decision-log document for your project and add an index table.
2. Add the full template beneath the index so it is always ready to duplicate.
3. Create a first record from a decision you made during the heuristic evaluation, such as DD-01 above.
4. Link the underlying artifact: a screenshot, a heuristic finding, a research note, or later a Figma frame.
5. Record an owner and a revisit condition before marking a decision accepted.
6. Update the record when evidence changes rather than silently replacing the rationale.

The goal is not to prove that every choice was perfect. It is to make the reasoning reviewable, challengeable, and improvable.

---

Key takeaways

A design decision log preserves the connection between a product’s visible interface and the reasoning that produced it.

• Use a decision log for meaningful choices, not every small visual adjustment.
• Record the context, decision, alternatives, evidence, and consequences.
• Link each decision to a real project goal, relevant user need, and known constraints.
• Cite evidence precisely and state its limitations. A heuristic finding is useful evidence of a likely concern, not proof of user behavior.
• Document trade-offs, dependencies, ownership, and conditions for revisiting the choice.
• Use lightweight entries for reversible craft decisions and full records for high-impact decisions.

You have now completed the UI/UX foundations module. Next, you will begin working in Figma, starting with its workspace, panels, pages, and essential design tools.