Back to Details

running-design-reviews

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Running Design Reviews

开展设计评审

Scope

适用范围

Covers
  • Planning a design review with a clear decision and requested feedback type(s)
  • Running a live demo–centered critique (or async review when needed)
  • Capturing feedback without “design-by-committee”
  • Synthesizing feedback using Value → Ease of Use → Delight prioritization
  • Recording decisions, tradeoffs, and follow-ups so the review changes the work
When to use
  • “Prepare and run a design critique for this Figma prototype.”
  • “We need a structured design review agenda and feedback log.”
  • “Help us review this flow and decide what to change before we ship.”
  • “Turn messy comments into prioritized feedback + next steps.”
When NOT to use
  • You don’t have a defined problem, target user, or goal yet (use 
    problem-definition
    first).
  • You need build-ready interaction specs / acceptance criteria (use 
    writing-specs-designs
    ).
  • You need evidence from users rather than expert critique (use 
    usability-testing
    ).
  • You’re doing launch planning, comms, rollout/rollback (use 
    shipping-products
    ).
涵盖内容
  • 规划目标明确、所需反馈类型清晰的设计评审
  • 开展以实时演示为核心的评审（必要时也可采用异步评审）
  • 收集反馈，避免“委员会式设计”
  • 采用价值→易用性→愉悦度的优先级框架整合反馈
  • 记录决策、权衡方案及跟进事项，确保评审切实推动工作进展
适用场景
  • “为这个Figma原型准备并开展一次设计评审。”
  • “我们需要结构化的设计评审议程和反馈日志。”
  • “帮我们评审这个流程，确定上线前需要修改的内容。”
  • “将零散的意见转化为优先级明确的反馈+后续步骤。”
不适用场景
  • 尚未明确问题、目标用户或目标（请先使用
    problem-definition
    ）。
  • 需要可直接用于开发的交互规范/验收标准（请使用
    writing-specs-designs
    ）。
  • 需要用户反馈而非专家评审（请使用
    usability-testing
    ）。
  • 正在进行上线规划、沟通、发布/回滚（请使用
    shipping-products
    ）。

Inputs

输入要求

Minimum required
  • Design artifact(s): link(s) or screenshots (e.g., Figma/prototype) + what parts are in scope
  • The decision needed (what will change after the review)
  • Target user + job-to-be-done (1–2 sentences)
  • Success criteria (1–3) and constraints (time, platform, accessibility, tech)
  • Review format + logistics: live vs async, time box, attendees/roles
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md, then proceed.
  • If answers aren’t available, make explicit assumptions and clearly label them.
  • Do not request secrets or credentials.
最低要求
  • 设计产物：链接或截图（如Figma/原型）+ 明确评审范围
  • 所需决策（评审后将做出哪些改变）
  • 目标用户+用户任务（1–2句话）
  • 成功标准（1–3条）及约束条件（时间、平台、无障碍要求、技术限制）
  • 评审形式+后勤安排：实时/异步、时间限制、参会人员/角色
信息缺失处理策略
  • 从references/INTAKE.md中最多提出5个问题，然后继续推进。
  • 如果无法获取答案，做出明确假设并清晰标注。
  • 不得索要机密信息或凭证。

Outputs (deliverables)

输出成果（交付物）

Produce a Design Review Pack in Markdown (in-chat by default; write to files if requested), in this order:
  1. Design review brief / pre-read (context, decision, requested feedback, links)
  2. Agenda + facilitation script (timed, prompts, roles)
  3. Feedback log (captured + categorized + prioritized)
  4. Decision record (decisions, tradeoffs, owners, due dates)
  5. Follow-up message + next review plan (what changed, what’s next)
  6. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成Markdown格式的设计评审包（默认在对话中生成；如有需求可写入文件），内容顺序如下：
  1. 设计评审摘要/预读材料（背景、所需决策、所需反馈、相关链接）
  2. 议程+引导脚本（分时段、提示语、角色分配）
  3. 反馈日志（已收集+分类+优先级排序）
  4. 决策记录（决策内容、权衡方案、负责人、截止日期）
  5. 跟进消息+下一次评审计划（已修改内容、后续安排）
  6. 风险/待解决问题/后续步骤（必须包含）
模板：references/TEMPLATES.md

Workflow (7 steps)

工作流程（7个步骤）

1) Classify the review and lock the decision

1) 分类评审并锁定决策目标

  • Inputs: Request + artifact(s) + constraints.
  • Actions: Identify the review type (concept / flow / content / visual polish / ship-readiness). Write the decision statement (“After this review we will decide ___”).
  • Outputs: Review type + decision statement + scope boundary (in/out).
  • Checks: Everyone can answer: “What will change after this review?”
  • 输入： 请求+设计产物+约束条件
  • 行动： 确定评审类型（概念/流程/内容/视觉打磨/上线准备）。撰写决策声明（“评审后我们将决定___”）。
  • 输出： 评审类型+决策声明+评审范围边界（包含/排除）
  • 检查： 所有参与者都能回答：“评审后会有哪些改变？”

2) Set the requested feedback (and what NOT to comment on)

2) 明确所需反馈（及无需评论的内容）

  • Inputs: Decision statement + stage of design.
  • Actions: Specify 1–3 feedback questions (e.g., “Is the value proposition clear?”, “Where does the flow break?”, “What edge cases are missing?”). Explicitly defer aesthetics/minutiae until Value/Ease are validated.
  • Outputs: Requested feedback list + “out of scope” feedback.
  • Checks: Feedback questions map directly to the decision.
  • 输入： 决策声明+设计阶段
  • 行动： 明确1–3个反馈问题（例如：“价值主张是否清晰？”、“流程在何处中断？”、“遗漏了哪些边缘场景？”）。在价值和易用性得到验证前，明确暂不讨论美学细节。
  • 输出： 所需反馈列表+“超出范围”的反馈内容
  • 检查： 反馈问题与决策目标直接相关

3) Assign roles (incl. a sponsor) and prepare a live demo

3) 分配角色（含发起人）并准备实时演示

  • Inputs: Attendees list + timeline/risk.
  • Actions: Assign: Presenter, Facilitator, Note-taker, and a Sponsor/DRI (senior owner who focuses on “why” + core concept). Decide whether leadership must review all user-facing screens before ship (for high-craft products).
  • Outputs: Roles list + demo plan (what will be shown, in what order).
  • Checks: Decision rights are clear; the review is anchored in a live demo, not a slide deck.
  • 输入： 参会人员列表+时间线/风险
  • 行动： 分配角色：演示者、引导者、记录者，以及发起人/负责人（DRI）（资深负责人，聚焦“原因”和核心概念）。对于高品质产品，需确定是否需要领导层在上线前评审所有面向用户的界面。
  • 输出： 角色列表+演示计划（演示内容及顺序）
  • 检查： 决策权限清晰；评审以实时演示为核心，而非幻灯片

4) Produce the pre-read (context first, then artifacts)

4) 生成预读材料（先背景，后产物）

  • Inputs: references/TEMPLATES.md (brief template) + project context.
  • Actions: Write a 1–2 page brief: problem → user → success criteria → constraints → options considered → risks/tradeoffs → open questions → links.
  • Outputs: Shareable pre-read + “how to review” instructions.
  • Checks: A reviewer can give useful feedback asynchronously without a live context dump.
  • 输入： references/TEMPLATES.md（摘要模板）+项目背景
  • 行动： 撰写1–2页的摘要：问题→用户→成功标准→约束条件→已考虑的方案→风险/权衡→待解决问题→相关链接
  • 输出： 可共享的预读材料+“评审指南”
  • 检查： 评审者无需实时背景介绍即可异步给出有效反馈

5) Run the review (big picture → Value → Ease → Delight)

5) 开展评审（全局→价值→易用性→愉悦度）

  • Inputs: Agenda + demo + notes/feedback log.
  • Actions: Start with goals/feelings (“What’s bothering us overall?”), then evaluate:
    1. Value: is it solving the right problem?
    2. Ease: can users do it without friction?
    3. Delight: polish, aesthetics, extra joy (only after 1–2) Capture feedback as observations + impact + suggestion, not opinions.
  • Outputs: Filled feedback log with categories and severities.
  • Checks: The review does not get stuck in minutiae before Value/Ease are resolved.
  • 输入： 议程+演示+笔记/反馈日志
  • 行动： 从目标/整体感受开始（“我们整体上存在哪些困扰？”），然后依次评估：
    1. 价值： 是否解决了正确的问题？
    2. 易用性： 用户能否顺畅完成操作？
    3. 愉悦度： 打磨细节、美学设计、额外惊喜（仅在1–2项完成后讨论） 反馈需记录为观察结果+影响+建议，而非主观意见
  • 输出： 已填写的反馈日志，包含分类和严重程度
  • 检查： 在价值和易用性问题解决前，评审不会陷入细节讨论

6) Synthesize + prioritize feedback into a change plan

6) 整合并按优先级排序反馈，形成变更计划

  • Inputs: Feedback log.
  • Actions: Deduplicate comments; resolve conflicts by returning to goals and constraints; prioritize by user impact and risk. Convert top items into explicit changes with owners and due dates.
  • Outputs: Prioritized change list + updated feedback log status/owners.
  • Checks: Top 3 issues are clear; each has a proposed action and owner.
  • 输入： 反馈日志
  • 行动： 去重评论；回归目标和约束条件解决冲突；按用户影响和风险排序。将优先级最高的事项转化为明确的变更任务，分配负责人和截止日期
  • 输出： 优先级明确的变更列表+更新后的反馈日志状态/负责人
  • 检查： 前3个核心问题清晰，每个问题都有对应的行动方案和负责人

7) Decide, document tradeoffs, and close the loop

7) 做出决策、记录权衡方案并闭环

  • Inputs: Proposed change plan + remaining open questions.
  • Actions: Record decisions and rationale; list tradeoffs and risks; define what must be re-reviewed. Send a follow-up summary and schedule the next review or ship gate.
  • Outputs: Decision record + follow-up message + Risks/Open questions/Next steps.
  • Checks: Decisions and action items are captured in writing; no critical decision is left implicit.
  • 输入： 拟议变更计划+剩余待解决问题
  • 行动： 记录决策及理由；列出权衡方案和风险；确定需重新评审的内容。发送跟进摘要，并安排下一次评审或上线 gate
  • 输出： 决策记录+跟进消息+风险/待解决问题/后续步骤
  • 检查： 决策和行动项已书面记录；无关键决策被隐含遗漏

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and score with references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md并通过references/RUBRIC.md进行评分
  • 必须包含：风险、待解决问题、后续步骤

Examples

示例

See references/EXAMPLES.md.
查看references/EXAMPLES.md

Reference files

参考文件

  • references/INTAKE.md
  • references/WORKFLOW.md
  • references/TEMPLATES.md
  • references/CHECKLISTS.md
  • references/RUBRIC.md
  • references/SOURCE_SUMMARY.md
  • references/EXAMPLES.md
  • references/INTAKE.md
  • references/WORKFLOW.md
  • references/TEMPLATES.md
  • references/CHECKLISTS.md
  • references/RUBRIC.md
  • references/SOURCE_SUMMARY.md
  • references/EXAMPLES.md