Back to Details

research-decision-room

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Research Decision Room Skill

Research Decision Room Skill

Create a single-page HTML decision artifact that helps a product or design team turn messy evidence into a clear next move. The output is not a decorative research deck. It is a working room for debate: evidence, themes, confidence, tradeoffs, and recommended experiments stay visible together.
创建一个单页HTML决策工件，帮助产品或设计团队将零散的证据转化为清晰的下一步行动方案。输出并非装饰性的研究演示文稿，而是用于讨论的工作空间：证据、主题、置信度、权衡因素和推荐实验将集中展示。

Resource map

资源地图

text
research-decision-room/
├── SKILL.md
├── example.html
└── references/
    ├── checklist.md
    └── evidence-model.md
Read 
references/evidence-model.md
before synthesis and run 
references/checklist.md
before emitting the artifact.
text
research-decision-room/
├── SKILL.md
├── example.html
└── references/
    ├── checklist.md
    └── evidence-model.md
在进行整合前阅读
references/evidence-model.md
，在生成工件前执行
references/checklist.md
中的检查项。

When to use this skill

何时使用该技能

Use this skill when the user has any mix of:
  • Interview notes, usability-test observations, support tickets, sales call notes, app-store reviews, NPS comments, survey open text, analytics snippets, or product-decision context.
  • A decision that needs evidence: "Should we build X?", "Which onboarding path should we try?", "Why are users dropping off?", "What do customers actually mean by slow?"
  • A need to share findings with stakeholders who will not read a long research report.
Do not use it for pure visual inspiration, campaign ideation, or brand moodboards.
当用户拥有以下任意组合的内容时，可使用此技能：
  • 访谈笔记、可用性测试观察记录、支持工单、销售通话笔记、应用商店评论、NPS评论、调查问卷开放文本、分析片段或产品决策背景信息。
  • 需要基于证据做出的决策："我们是否应该开发X？"、"我们应该尝试哪条入门路径？"、"用户为什么流失？"、"客户所说的‘缓慢’到底指什么？"
  • 需要向不会阅读长篇研究报告的利益相关者分享研究结果的需求。
请勿将其用于纯视觉灵感、营销活动构思或品牌情绪板制作。

Workflow

工作流程

Step 1 - Establish the decision frame

步骤1 - 确定决策框架

Identify the decision scope from the user's prompt. If the user did not give a decision, derive one from the evidence and label it as inferred.
Write a short frame with:
  • Decision question.
  • Audience or segment.
  • Time horizon.
  • Known constraints.
  • What this artifact will not decide.
If key context is missing and the task is not blocked, proceed with labelled assumptions instead of asking a broad question.
从用户的提示中明确决策范围。如果用户未给出决策，则从现有证据中推导并标记为“推断得出”。
撰写简短的框架，包含：
  • 决策问题。
  • 受众或用户细分。
  • 时间范围。
  • 已知约束条件。
  • 此工件不会做出的决策。
如果关键上下文缺失但任务未受阻，则使用带有标注的假设继续推进，而非提出宽泛的问题。

Step 2 - Build the evidence ledger

步骤2 - 构建证据分类账

Normalize every useful signal into ledger rows using the model in 
references/evidence-model.md
.
Each ledger row must include:
  • id
    : short stable id, such as 
    I-03
    , 
    T-14
    , 
    M-02
    .
  • source_type
    : interview, usability, support, survey, analytics, sales, field note, or stakeholder.
  • segment
    : user type or "unknown".
  • signal
    : one-sentence observation.
  • quote_or_metric
    : direct quote, metric, or "not provided".
  • strength
    : strong, medium, or weak.
  • limitations
    : why this evidence may be biased or incomplete.
Never invent quotes, participant counts, dates, revenue impact, or metrics. If the user did not provide a number, use "not provided" and explain what evidence would increase confidence.
使用
references/evidence-model.md
中的模型，将所有有用的信号标准化为分类账条目。
每个分类账条目必须包含：
  • id
    ：简短稳定的标识，例如
    I-03
    、
    T-14
    、
    M-02
    。
  • source_type
    ：访谈、可用性测试、支持工单、调查问卷、分析、销售、现场笔记或利益相关者。
  • segment
    ：用户类型或“未知”。
  • signal
    ：一句话的观察结论。
  • quote_or_metric
    ：直接引用、指标或“未提供”。
  • strength
    ：强、中或弱。
  • limitations
    ：该证据可能存在偏见或不完整的原因。
切勿编造引用内容、参与者数量、日期、收入影响或指标。如果用户未提供相关数字，使用“未提供”并说明哪些证据可以提升置信度。

Step 3 - Synthesize themes and tensions

步骤3 - 整合主题与矛盾点

Cluster evidence into 4 to 6 themes. For each theme:
  • Name the theme in plain human language.
  • List the evidence ids that support it.
  • Explain the behavior behind it, not just the UI complaint.
  • Mark confidence as high, medium, or low.
  • Note contradictions or segment differences.
Prefer verbs over nouns: "Teams abandon setup when the first blank state asks for too much" is better than "Onboarding problem".
将证据归类为4至6个主题。每个主题需包含：
  • 用通俗易懂的语言为主题命名。
  • 列出支持该主题的证据标识。
  • 解释其背后的行为，而非仅停留在UI层面的抱怨。
  • 将置信度标记为高、中或低。
  • 记录矛盾点或用户细分差异。
优先使用动词而非名词：例如“当首次空白页要求过多信息时，团队会放弃设置”比“入门问题”更合适。

Step 4 - Score opportunities

步骤4 - 为机会打分

Create an opportunity matrix with 3 to 5 options. Score each option on a 1 to 5 scale:
  • Evidence strength.
  • User pain.
  • Business leverage.
  • Implementation risk, where 5 means low risk and 1 means high risk.
Show the total score, but do not let the score replace judgment. Add one sentence on why the top recommendation wins.
创建包含3至5个选项的机会矩阵。从以下维度为每个选项打1至5分：
  • 证据强度。
  • 用户痛点。
  • 业务影响力。
  • 实施风险（5分表示低风险，1分表示高风险）。
展示总分，但不要让总分取代判断。添加一句话说明为何首选推荐方案胜出。

Step 5 - Draft the decision memo

步骤5 - 起草决策备忘录

Write a decision memo with:
  1. Recommended move.
  2. Why now.
  3. What evidence supports it.
  4. What could be wrong.
  5. What to measure next.
  6. Reversible next step.
Keep the memo short enough to read in under one minute.
撰写决策备忘录，包含：
  1. 推荐行动方案。
  2. 为何选择现在执行。
  3. 支持该方案的证据。
  4. 可能存在的问题。
  5. 下一步需要衡量的指标。
  6. 可撤销的下一步行动。
备忘录需简洁到能在一分钟内读完。

Step 6 - Create the HTML artifact

步骤6 - 创建HTML工件

Produce a self-contained 
index.html
. Use the active 
DESIGN.md
for typography, spacing, color roles, and component tone, but keep the information architecture stable:
  1. Header with decision question, confidence, and last-updated label.
  2. Executive readout with recommendation, risk, and next experiment.
  3. Evidence ledger with filter chips.
  4. Theme map with evidence ids and confidence.
  5. Opportunity matrix.
  6. Decision memo.
  7. Experiment queue with owner, metric, and success threshold.
  8. Assumptions and limitations.
The artifact should be interactive but durable. Simple vanilla JavaScript is allowed for filtering evidence, switching views, or highlighting related ids. No framework dependency is required.
生成一个独立的
index.html
文件。使用当前的
DESIGN.md
来确定排版、间距、颜色角色和组件风格，但需保持信息架构稳定：
  1. 标题栏：包含决策问题、置信度和最后更新标签。
  2. 执行摘要：包含推荐方案、风险和下一个实验。
  3. 证据分类账：带有筛选标签。
  4. 主题图谱：包含证据标识和置信度。
  5. 机会矩阵。
  6. 决策备忘录。
  7. 实验队列：包含负责人、指标和成功阈值。
  8. 假设与局限性。
工件需具备交互性且持久耐用。允许使用简单的原生JavaScript实现证据筛选、视图切换或相关标识高亮功能，无需依赖任何框架。

Step 7 - Self-check and emit

步骤7 - 自我检查与输出

Run the checklist. Then emit one concise orientation sentence and one HTML artifact:
xml
<artifact identifier="research-decision-room" type="text/html" title="Research Decision Room">
<!doctype html>
<html>...</html>
</artifact>
Nothing after the closing 
</artifact>
.
执行检查清单中的内容。然后输出一句简洁的说明性语句和一个HTML工件：
xml
<artifact identifier="research-decision-room" type="text/html" title="Research Decision Room">
<!doctype html>
<html>...</html>
</artifact>
</artifact>
标签后不得添加任何内容。