dragoon0x/everything-design-taste

design-critique

Structured frameworks for giving and receiving design feedback that makes work better, not just different.

First seen Jul 18, 2026

Installation

$ npx skills add dragoon0x/everything-design-taste --skill design-critique

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from dragoon0x/everything-design-taste · top by installs.

npx skills add dragoon0x/everything-design-taste

Browse all from dragoon0x/everything-design-taste

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 11
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,991 B
  • docs SUMMARY.md 129 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Design Critique

Giving Critique

The Framework

For every piece of feedback, hit three points:

  1. Observation — What you see (factual, not opinion)
  2. Impact — Why it matters (connects to goals, users, or principles)
  3. Direction — What to explore (not prescriptive, but generative)

Example:

  • Observation: "The CTA is the same visual weight as the navigation links."
  • Impact: "Users scanning the page won't know where to click first."
  • Direction: "Try increasing the size or contrast of the CTA, or reducing the visual weight of the nav."

What Good Critique Sounds Like

  • "I notice [observation]. How does that serve [the user/the goal]?"
  • "This works well because [specific reason]. What if we pushed it further by..."
  • "The hierarchy here reads as [X] before [Y]. Is that the intended priority?"
  • "I'm drawn to [element], but I think it might compete with [other element]."

What Bad Critique Sounds Like

  • "I don't like it" (not actionable)
  • "Make it pop" (meaningless)
  • "Can we try it in blue?" (prescriptive without rationale)
  • "This is wrong" (no direction, pure criticism)
  • "What if we added..." (solution before understanding the problem)

Critique Priority Order

  1. Strategy — Is this solving the right problem?
  2. Structure — Is the information architecture correct?
  3. Interaction — Does the flow make sense?
  4. Visual — Does it look right?
  5. Polish — Are the details refined?

Don't critique polish when the strategy is wrong.

Receiving Critique

How to Present Work for Critique

  • State what you want feedback on (scope the conversation)
  • Explain the constraints you're working within
  • Share what you've already tried and why you moved past it
  • Don't apologize for unfinished work (it's a critique, not a showcase)

How to Process Feedback

  • Write it down before responding
  • Ask clarifying questions ("Can you say more about what feels off?")
  • Look for patterns (if 3 people mention hierarchy, it's a hierarchy problem)
  • Separate "I don't prefer this" from "this doesn't work for users"
  • You don't have to act on everything. But you should understand everything.

Running a Critique Session

Format (60 min max)

  1. Context (5 min) — Designer presents the problem, constraints, current state
  2. Silent review (5 min) — Everyone looks without speaking
  3. Clarifying questions (5 min) — "What does this state do?" not "Why did you..."
  4. Feedback (30 min) — One at a time, using the observation-impact-direction framework
  5. Synthesis (10 min) — Designer summarizes what they heard and intended next steps
  6. Written follow-up — Key feedback documented within 24 hours