Template Overview

Design critiques easily devolve into unproductive aesthetic arguments when feedback lacks structure. Without clear design principles and objective problem framing, participants offer subjective opinions, defend personal tastes, and leave the presenter overwhelmed by contradictory advice.

A structured Design Critique establishes a disciplined evaluation arena. The presenter articulates the customer problem, constraints, and proposed variants, while reviewers provide feedback grounded in usability heuristics, visual hierarchy, and token consistency.

This template structures design critique sessions: problem framing, side-by-side variant comparisons, constructive critique feedback, accessibility evaluations, and binding design decisions.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "Design Critique: [Feature / Flow Name]"
date: [YYYY-MM-DD]
presenter: "[[Lead Product Designer]]"
facilitator: "[[Design Systems Lead]]"
attendees:
  - "[[VP Product]]"
  - "[[Lead Systems Engineer]]"
  - "[[Senior UX Researcher]]"
feature_reviewed: "Template Gallery Detail Page & Copy Actions"
decision_verdict: [Variant A Selected | Variant B Selected | Needs Re-design]
tags: [design-critique, ui-ux, design-systems, feedback, review]
---

# Design Critique: [Feature / Flow Name] — [YYYY-MM-DD]

## 1. Problem Statement & Design Objectives
- **Core User Goal:** Users landing on a Markdown template detail page must quickly evaluate its relevance and copy or download the plain text with zero confusion.
- **Constraints:** Must support dark mode and light mode seamlessly using existing design tokens; no third-party UI framework dependencies.

## 2. Variant Comparison & Trade-Off Analysis
| Evaluation Factor | Variant A: Split Hero Layout | Variant B: Single Column Layout | Winning Option |
| :--- | :--- | :--- | :--- |
| **Visual Hierarchy** | Title and actions pinned left; specs pinned right | Stacked vertical flow with actions below title | 🟢 Variant A (Faster scanability) |
| **Cognitive Load** | Clear separation between metadata and template text | Dense text block with competing buttons | 🟢 Variant A |
| **Mobile Responsiveness** | Collapses gracefully into single column below 768px | Already single column | 🟡 Tie |
| **Engineering Effort** | 4 hours CSS grid implementation | 2 hours standard flexbox | 🟡 Variant B |

## 3. Reviewer Feedback & Constructive Critique
### [[VP Product]]
- "Variant A establishes great credibility immediately. The badge pills for 'Obsidian Compatible' and 'CommonMark' build instant trust."
- *Critique:* "Ensure the copy button has a clear success state so users aren't left wondering if clipboard transfer succeeded."

### [[Lead Systems Engineer]]
- "The CSS Grid for Variant A is clean and uses our existing token spacing variables (`--s-4`, `--s-6`). Zero JavaScript layout dependencies."
- *Critique:* "Check that code block font size adheres to `--fs-code` across mobile breakpoints."

## 4. Accessibility & Token Compliance
- **Color Contrast:** Breadcrumb links verified at 5.2:1 contrast ratio against background (WCAG AA compliant).
- **Focus Rings:** All buttons render 2px solid accent focus rings on keyboard tab navigation.

## 5. Final Design Decision & Next Steps
> [!IMPORTANT] Binding Decision: Variant A Approved
> Team unanimously approved Variant A (Split Hero Layout) subject to adding the checkmark copy confirmation state and mobile code block font token check.

- [ ] [[Lead Product Designer]] Update Figma component library with approved Variant A tokens.
- [ ] [[Lead Systems Engineer]] Implement CSS Grid layout in `src/pages/templates/[category]/[slug].astro`.
- [ ] Schedule visual QA review for Friday afternoon.

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "Critique: Template Detail Hero"
date: 2026-10-07
presenter: "[[Kiran Shah]]"
decision_verdict: Variant A Selected
tags: [design-critique, ui]
---

# Critique: Template Detail Hero — October 7, 2026

## 1. Summary
Reviewed split hero layout vs single-column layout for template pages.

## 2. Decision
Variant A approved unanimously. Visual hierarchy and token spacing verified.

When to Use and When to Avoid

When to Use

  • Use during weekly design critique reviews, UI variant evaluations, and design system reviews.
  • Use to compare multiple design approaches against objective usability and token standards.
  • Use to record binding design decisions and agreed engineering implementation requirements.

When to Avoid

  • Avoid using for preliminary, rough solo brainstorming before variants are ready for review.
  • Avoid using for code-level pull request reviews (use GitHub PR reviews).

On-Device AI Integration

Capture design critique sessions with Oyma on macOS:

Analyze the design critique meeting audio transcript:
1. Synthesize the core problem statement, user goals, and technical design constraints.
2. Build the variant comparison table analyzing visual hierarchy, cognitive load, and engineering effort.
3. Group reviewer feedback by participant, noting constructive critiques and commendations.
4. Document the final binding design decision, accessibility verifications, and next action items.
Output in structured, design-oriented CommonMark.

Your team’s design critique deliberations and proprietary UI variant plans stay securely on your Mac.

Frequently Asked Questions

What makes a design critique effective?

An effective critique focuses on how well a design achieves specific user goals and design principles, rather than subjective personal aesthetics ('I don't like blue').

How does this template manage UI variant comparisons?

It evaluates design options (Variant A vs Variant B) across explicit trade-offs: visual hierarchy, cognitive load, accessibility, and engineering feasibility.

Why document design critiques in Markdown?

Markdown design logs integrate directly with design token documentation and frontend engineering repositories, creating an auditable record of design decisions.