一键导入
needs-articulation
Distinguish user wants from underlying needs to guide solution design. Use when stakeholders make feature requests or during Define phase.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Distinguish user wants from underlying needs to guide solution design. Use when stakeholders make feature requests or during Define phase.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Assess assumptions on certainty and risk to prioritize validation efforts. Use at project start or before phase transitions.
Test whether assumptions are true before making commitments. Use when assumptions have low certainty and high risk.
Create structured visualizations of stakeholder perspectives (says, thinks, does, feels) to build deep understanding. Use when conducting user research or validating assumptions.
Assess solution ideas on impact and feasibility to prioritize prototyping. Use during Ideate phase when deciding which ideas to pursue.
Transform raw research into actionable insights that inform design decisions. Use during Define phase after completing research.
Create clear leadership presentations that communicate findings and enable good decisions. Use at end of each phase or before major commitments.
| name | needs-articulation |
| description | Distinguish user wants from underlying needs to guide solution design. Use when stakeholders make feature requests or during Define phase. |
Clearly articulate what stakeholders actually need (vs. what they ask for) to guide solution design.
Users often express solutions, not underlying needs:
User says: "I want a dashboard with 20 widgets" Underlying need: "I need to monitor system health without checking multiple places"
User says: "Add more features like Tool X" Underlying need: "I need to accomplish Y task more efficiently"
Use the 5 Whys technique:
Request: "Make the button bigger"
Need: Design for gloved interaction in field conditions
Format: [Stakeholder] needs [capability] so they can [outcome]
Examples:
Check with stakeholders:
Not all needs are equal:
Update stakeholder profiles:
{
"id": "s1",
"name": "Field Technician",
"type": "group",
"needs": [
"Work effectively in low/no connectivity areas",
"Quick data capture with minimal interaction",
"Reliable sync when back online"
],
"pain_points": [
"Data loss when connection drops",
"Too many steps to log information",
"Interface unusable with gloves"
]
}
Watch out for: