Most UX designers take notes constantly — during user interviews, usability tests, design reviews, competitor analyses, and stakeholder meetings. The gap between having notes and having a useful knowledge base is the template: the structure that converts a dense page of observations into retrievable, citable design intelligence.
Four templates — the research session template, the competitive analysis template, the design review template, and the design decision template — cover the major knowledge-producing events in UX design work and produce specific, retrievable outputs from each one.
Template 1: The Research Session Template
The research session template is used for user interviews, usability tests, and any structured user research session. It produces two outputs: the session-level behavioral synthesis that routes cross-project insights to the research archive, and the session record that stays in the project research repository.
RESEARCH SESSION — [Date]
Project: [Product and feature/component being researched]
Session type: [User interview / Usability test / Diary study / Survey review / Other]
Participant: [Participant code — no name] | Context: [Brief relevant background: role, tech comfort, context of use]
Moderator: [Name]
Duration: [Minutes]
RESEARCH QUESTIONS THIS SESSION ADDRESSES:
1. [Research question from the anchor]
2. [...]
OBSERVATIONS BY QUESTION:
Q1: [Research question]
Observation: [What was observed — specific behavior, direct quote, task performance]
Quote (if applicable): "[Verbatim quote]" — at [time stamp in recording]
Significance: [Why this observation matters]
Q2: [...]
TOP 3 OBSERVATIONS FROM THIS SESSION:
1. [Most significant observation]
2. [Second most significant]
3. [Third]
PATTERNS TO WATCH:
[Any observation that appeared in prior sessions — potential confirmation of a pattern]
SESSION CONFIDENCE ASSESSMENT:
[ ] This session confirmed existing patterns — no new findings
[ ] This session added nuance to existing patterns
[ ] This session produced new observations worth tracking
[ ] This session challenged prior patterns — needs follow-up
CROSS-PROJECT ROUTING:
[Any observations with cross-project value — will become research archive entries]
[Route only behavioral patterns, not session-specific data]
→ Research archive entry to write: [Pattern + confidence level after this session]
Completion timing: session template is completed during and immediately after the session, while the participant's context is fresh. Direct quotes are copied verbatim with timestamp references to the recording.
The de-identification line: the participant code (P1, P2, etc.) stays in the project research repository. The cross-project research archive entry removes even the participant code — it describes the behavioral pattern in de-identified terms.
Template 2: The Competitive Analysis Template
The competitive analysis template is used when reviewing a competitor product or design example. It produces an annotated pattern capture that can be retrieved by design pattern — not by the date it was captured.
COMPETITIVE ANALYSIS ENTRY — [Date]
Product/Source: [Product name or design source]
Platform: [iOS / Android / Web / Desktop / Cross-platform]
Capture context: [What prompted this review — new product release / specific design research]
INTERACTION PATTERN FOCUS:
Primary pattern: [Pattern taxonomy label — see pattern library]
Secondary patterns (if applicable): [Other notable patterns in this example]
WHAT THIS DESIGN DOES:
[Specific description of the interaction or design approach]
[Screenshot/capture reference or URL]
WHAT IT OPTIMIZES FOR:
[The user experience quality this design prioritizes]
Example: "Reduces cognitive load by hiding secondary actions until needed"
WHAT IT SACRIFICES:
[The tradeoff this design accepts]
Example: "Discoverability of secondary features is reduced — features must be
known to be accessed"
WHEN THIS PATTERN APPLIES:
[The product context, user type, or interaction scenario where this approach works well]
WHEN THIS PATTERN DOESN'T APPLY:
[The conditions where this approach would underperform]
ROUTING:
→ Pattern library: [Pattern taxonomy section where this entry belongs]
The annotation discipline is the most important part of this template. A competitive analysis capture without the "what it optimizes for" and "what it sacrifices" annotation is a screenshot archive — browsable, not searchable. With this annotation, the same capture is retrievable when a designer asks "show me examples of patterns that prioritize discoverability over cognitive load."
Template 3: The Design Review Template
Design reviews — both informal peer reviews and formal stakeholder reviews — produce feedback that needs to be captured in a structured, actionable form. The design review template organizes feedback by type and ensures action items are clearly attributed.
DESIGN REVIEW — [Date]
Project: [Product and feature/component]
Review type: [Internal peer review / Design critique / Stakeholder review / Accessibility review]
Design stage: [Wireframe / Visual design / Prototype / Design spec]
Reviewers: [Role, not name — e.g., "Lead Designer," "Product Manager," "Accessibility Specialist"]
WHAT WAS SHOWN:
[Brief description of what was presented for review]
FEEDBACK BY CATEGORY:
Usability concerns:
[Specific usability concern — precise, not "unclear"]
[Related design element: component or interaction]
Visual design feedback:
[Specific visual feedback]
Content and information architecture:
[IA or content feedback]
Accessibility:
[Specific accessibility feedback — WCAG criteria if applicable]
Technical constraints from engineering:
[What engineering flagged as technically complex or not feasible in current sprint]
DECISIONS MADE IN THIS REVIEW:
[ ] [Specific decision — what was agreed and who agreed it]
ACTION ITEMS:
[ ] [Specific change — precise enough to be verifiable] — Owner: [Designer/PM/Engineer]
[ ] [...]
PENDING QUESTIONS:
[Questions that came up but weren't resolved in this review — who needs to answer and by when]
DESIGN DIRECTION CONFIRMED:
[ ] Overall direction confirmed — proceed with revisions
[ ] Major redirection needed — re-design before next review
[ ] Additional research needed before proceeding
The precision discipline: vague feedback ("make it clearer") can't be actioned. When feedback arrives in vague form, note the specific component being discussed ("the filter UI") and ask for the specific concern ("unclear because the labels aren't specific enough?"). A review template that captures precise feedback produces clear action items; one that captures vague feedback produces revisit meetings.
Template 4: The Design Decision Template
The design decision template documents the reasoning behind a major design choice — what options were considered, what research supported the decision, and what tradeoffs were accepted. Written immediately after the decision, it serves as the reference when the decision is challenged during design review or after launch.
DESIGN DECISION — [Date]
Project: [Product and feature/component]
Decision: [The specific design choice — one sentence, specific]
Example: "Navigation uses bottom tab bar with 4 primary destinations, not sidebar"
Not: "We decided on a navigation pattern"
DESIGN CHALLENGE:
[What interaction or layout problem this decision addresses]
OPTIONS CONSIDERED:
Option A: [Description]
What it optimizes for: [User experience quality prioritized]
What it sacrifices: [Tradeoff accepted]
Research support: [Evidence for or against — specific]
Option B: [Description]
What it optimizes for: [...]
What it sacrifices: [...]
Research support: [...]
WHY WE CHOSE [OPTION]:
[The specific reasons this option was chosen over the alternatives]
[Research that tipped the decision — specific finding with confidence level]
TRADEOFFS ACCEPTED:
[What the chosen approach sacrifices — honest assessment]
STAKEHOLDERS INFORMED:
[Who was consulted or informed before this decision was finalized]
ROUTING:
→ Design decision archive entry written: [Yes/No]
→ Pattern library: [Does this decision produce a cross-project pattern capture?]
OUTCOME (filled in post-launch):
[What post-launch data said about this decision]
[Did the decision hold? Was it revised?]
When to write the design decision template: immediately after any design decision that:
- Involved more than one option
- Required research to resolve
- Is likely to be challenged by a stakeholder
- Would be worth referencing when making a similar decision on a future product
Using Templates Efficiently
Template stacking: these templates are designed to work together. A competitive analysis session produces competitive analysis template entries; those entries inform a design decision, which produces a design decision template; the design decision is validated in a design review, which produces a design review template. The templates create a traceable chain from research to decision to feedback.
Minimum viable completion: during high-velocity design work, full template completion may not be possible in the moment. The minimum viable entries:
- Competitive analysis: pattern label + one sentence for "what it does" + routing decision
- Design review: action items with owners (everything else can be added later)
- Design decision: the decision + the top reason for it + tradeoffs accepted
Full completion is better; minimum viable completion is better than no structure.
The routing decision is required on every template. Every template ends with a routing decision: does anything from this session go to the cross-project knowledge base? The routing decision is the step that converts project-specific note-taking into a professional knowledge base.
Key Takeaways
-
Four templates cover the major knowledge-producing events in UX design work: research session (behavioral observations + cross-project routing), competitive analysis (pattern annotation with what-it-optimizes + what-it-sacrifices + routing), design review (actionable feedback + decisions + action items), design decision (options + research basis + tradeoffs accepted + outcome).
-
The competitive analysis annotation at capture is what makes the pattern library searchable. "What it optimizes for" and "what it sacrifices" convert a screenshot into a retrievable design intelligence entry. Without annotation, the competitive analysis is a screenshot collection; with annotation, it's a searchable pattern library.
-
The design decision template's highest value is during stakeholder review, not during design work. Written in 20-30 minutes immediately after the decision, it converts a 30-minute stakeholder challenge conversation into a 5-minute reference review.
-
Every template ends with a routing decision. Does any observation, example, or finding from this session have cross-project value? If yes, it routes to the appropriate knowledge base layer (research archive, pattern library, decision archive). Without this routing step, templates are project-specific documentation rather than professional knowledge building.
-
De-identification is maintained in research session templates. Participant codes replace names in project records; the cross-project research archive uses de-identified behavioral pattern descriptions. Individual participant data stays in the project research repository.
Conclusion
Note-taking templates for UX designers convert the constant observation and analysis that characterizes design work into retrievable professional knowledge. The research session template extracts behavioral patterns from individual sessions and routes them to the cross-project research archive; the competitive analysis template converts competitive examples into searchable pattern library entries through annotation; the design review template converts review feedback into precise action items and routing decisions; and the design decision template preserves the research-to-decision connection through stakeholder review and post-launch evaluation. Used consistently, these four templates produce the knowledge base that makes each successive design project start from a higher intelligence baseline than the previous one.
Related reading: The Ultimate Guide to Web Clipping.