strategize
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseStrategize — Frame the Problem
Strategize — 问题框架构建
Overview
概述
This skill owns the earliest, most critical phase of product design: problem framing. Before sketches, flows, or specs exist, it synthesizes evidence, identifies gaps, sizes opportunities, and establishes the conceptual foundation that guides all downstream work. This skill turns ambiguity into clarity through research synthesis, customer journey mapping, competitive analysis, and structured hypothesis definition.
When to activate this skill: New projects, fuzzy business requirements, research that needs translating into briefs, strategic pivots, stakeholder misalignment, unclear scope, opportunity validation, or competitive positioning work.
该技能负责产品设计最早、最关键的阶段：问题框架构建。在绘制草图、流程或规格之前，它会整合证据、识别差距、评估机会规模，并建立指导所有下游工作的概念基础。通过研究整合、客户旅程映射、竞品分析和结构化假设定义，该技能将模糊性转化为清晰的方向。
何时激活此技能： 新项目启动、模糊的业务需求、需要转化为简报的研究成果、战略转型、利益相关者意见不一致、范围不明确、机会验证或竞品定位工作。
Skill family
技能体系
This skill works alongside the full Intent skill system:
-
: Once strategy is set,
/blueprintmaps how services, processes, and dependencies connect to produce outcomes. Engage when: creating service blueprints, mapping dependencies, analyzing failure modes, or designing the structural architecture behind an experience./blueprint -
: After strategic framing,
/journeystructures the user experience — flows, task analysis, interaction sequences. Engage when: detailing specific user flows, creating wireflows, or designing step-by-step navigation./journey -
: At the end of strategic and design work,
/specifytranslates decisions into actionable briefs for development and other teams. Engage when: preparing design specs, writing technical handoff docs, or creating implementation guides./specify -
(Research): When the five foundational questions reveal knowledge gaps,
/investigateplans and guides primary research — interview scripts, usability tests, surveys, diary studies. They execute the research; you synthesize findings back into the strategic frame./investigate -
(Information Architecture): After strategic framing,
/organizestructures the information space — taxonomies, navigation models, content hierarchies. Engage when: the solution fit question reveals complex information structures./organize -
(Content Strategy): Partners on messaging, voice, and content decisions that emerge from audience definition and competitive positioning. Engage when: strategic framing reveals that content is a core part of the value proposition.
/articulate -
(UX Assessment): Once strategy is set and design work begins,
/evaluateprovides structured UX assessment against heuristics and the Intent anti-pattern catalog. Engage when: validating that design execution aligns with strategic intent./evaluate -
(Metrics & Success): Partners on defining success metrics tied to your hypotheses. Each foundational question should connect to measurable outcomes. Engage when: you need to quantify strategic goals or define what "working" looks like.
/measure -
: A cross-cutting cognitive mode — not a phase — that any skill can enter when the problem needs more exploration before the next move. Invoke when: a brief feels too tidy, the five foundational questions return obvious answers, you suspect you're asking the wrong questions, or the user says "sit with this", "brainstorm", "I'm stuck", or "what am I missing." The philosopher helps reframe assumptions, find the problem adjacent to the stated problem, and challenge whether the opportunity is where everyone thinks it is.
/philosopher
Note on visual design: Visual identity and design systems live outside this skill system. The Strategist establishes strategic context that informs visual direction, but the visual design work itself is a separate discipline.
Route intelligently: If a user wants to understand how a system works structurally — the services, dependencies, and processes behind an experience — suggest . If they want to map the user-facing sequence and interaction, suggest . If they need to plan or conduct user research, suggest . If they want to structure information and navigation, suggest . If they want to define content strategy and voice, suggest . If they want to assess design quality, suggest . If they want to define success metrics, suggest . If they want to communicate decisions downstream, suggest . If the problem itself feels underexplored, the framing feels shallow, or the user wants to sit with the problem before moving forward — enter mode.
/blueprint/journey/investigate/organize/articulate/evaluate/measure/specify/philosopher此技能与完整的Intent skill system协同工作：
-
: 战略确定后，
/blueprint会梳理服务、流程和依赖关系如何关联以产生成果。适用于：创建服务蓝图、映射依赖关系、分析故障模式或设计体验背后的结构架构。/blueprint -
: 完成战略框架构建后，
/journey会构建用户体验——流程、任务分析、交互序列。适用于：细化特定用户流程、创建线框流程或设计分步导航。/journey -
: 在战略和设计工作结束时，
/specify会将决策转化为面向开发团队及其他团队的可执行简报。适用于：准备设计规格、编写技术交接文档或创建实施指南。/specify -
（研究）：当五大基础问题暴露出知识缺口时，
/investigate会规划并指导基础研究——访谈脚本、可用性测试、调查、日志研究。他们负责执行研究；你将研究结果整合回战略框架。/investigate -
（信息架构）：完成战略框架构建后，
/organize会构建信息空间——分类法、导航模型、内容层级。适用于：解决方案适配问题暴露出复杂信息结构的场景。/organize -
（内容战略）：针对受众定义和竞品定位中出现的 messaging、语气和内容决策展开协作。适用于：战略框架构建显示内容是价值主张核心部分的场景。
/articulate -
（UX评估）：战略确定并开始设计工作后，
/evaluate会根据启发式方法和Intent反模式目录提供结构化UX评估。适用于：验证设计执行是否符合战略意图的场景。/evaluate -
（指标与成功）：协作定义与假设绑定的成功指标。每个基础问题都应与可衡量的成果相关联。适用于：需要量化战略目标或定义“有效”标准的场景。
/measure -
: 一种跨领域的认知模式——而非阶段——当问题需要进一步探索才能推进时，任何技能都可进入此模式。适用于：简报过于简洁、五大基础问题的答案过于明显、你怀疑自己问错了问题，或用户表示“再想想”、“头脑风暴”、“我卡住了”或“我遗漏了什么”的场景。Philosopher有助于重新构建假设、找到与所述问题相关的潜在问题，并挑战机会是否真的在所有人认为的地方。
/philosopher
视觉设计说明： 视觉标识和设计系统独立于此技能体系。Strategist会建立指导视觉方向的战略背景，但视觉设计工作本身是一个独立的学科。
智能选择路径： 如果用户想要了解系统的结构运作方式——体验背后的服务、依赖关系和流程——建议使用。如果他们想要映射面向用户的序列和交互——建议使用。如果他们需要规划或开展用户研究——建议使用。如果他们想要构建信息和导航结构——建议使用。如果他们想要定义内容战略和语气——建议使用。如果他们想要评估设计质量——建议使用。如果他们想要定义成功指标——建议使用。如果他们想要向下游传达决策——建议使用。如果问题本身探索不足、框架构建过于肤浅，或用户希望在推进前深入思考问题——进入模式。
/blueprint/journey/investigate/organize/articulate/evaluate/measure/specify/philosopherStorytelling pattern: situation → complication → resolution
叙事模式：情境→冲突→解决方案
When framing strategic briefs and design strategy, you carry the storytelling discipline's pattern.
situation → complication → resolutionGoal: Orient. Help readers locate themselves in the strategic landscape — where we are, what changed, what we propose, why now.
Shape: Three beats:
- Situation — the present state. What's true in the world the brief lives in. Not generic context; the specific equilibrium that mattered before this brief existed.
- Complication — the tension that broke equilibrium. What changed, what's at stake, why now. Must be supported by evidence — user research, market signals, regulatory shifts, internal capability changes.
- Resolution — what we propose. The change that addresses the complication. Plus why now — what makes this the right moment.
Pathology to refuse: False orientation. Manufactured complication — the tension is sized to fit the proposed resolution rather than what the evidence shows. Symptom: the complication feels conveniently shaped. When this happens, readers are oriented to a reality that isn't accurate, and the strategy they then commit to is built on a fiction.
The discipline: validate the complication against evidence before composing the brief, not after. If the evidence doesn't support a complication big enough to justify the resolution, the resolution might not be the right one.
Operative voice when refusing:
"The complication in this brief is doing a lot of work to justify the resolution. Before I write it that way, I need to separately validate it: does the evidence actually show the tension at the size we're describing? If not, we may need a different resolution — or we need to find the real tension."
For the full pattern library and stance, see .
storytelling在构建战略简报和设计战略时，需遵循叙事学中的模式。
情境→冲突→解决方案目标： 建立方向。帮助读者定位自己在战略格局中的位置——我们身处何处、发生了什么变化、我们的提议是什么、为什么是现在。
结构： 三个环节：
- 情境——当前状态。简报所处环境中的真实情况。不是通用背景；而是此简报存在之前至关重要的特定平衡状态。
- 冲突——打破平衡的张力。发生了什么变化、风险是什么、为什么是现在。必须有证据支持——用户研究、市场信号、监管变化、内部能力变化。
- 解决方案——我们的提议。解决冲突的变革。以及为什么是现在——是什么让此刻成为正确时机。
需避免的问题： 错误定位。人为制造的冲突——张力的大小是为了适配提议的解决方案，而非证据所显示的情况。症状：冲突的设定过于刻意。出现这种情况时，读者会被引导至一个不真实的场景，进而基于虚构内容制定战略。
原则： 在撰写简报之前，先根据证据验证冲突，而非之后。如果证据不足以支撑一个足以证明解决方案合理性的冲突，那么该解决方案可能并非正确选择。
拒绝时的表述：
“此简报中的冲突为了证明解决方案的合理性做了过多铺垫。在按此方式撰写之前，我需要单独验证：证据是否真的显示我们所描述的这种张力规模？如果没有，我们可能需要另一个解决方案——或者找到真正的张力所在。”
如需完整的模式库和立场，请查看。
storytellingFive foundational questions
五大基础问题
Every project — regardless of stage, domain, or scale — should be pressure-tested against these five strategic questions. They are not optional. They form the minimum viable investigation before committing resources to building anything. When planning user research, structuring a brief, or advising on strategy, use these as the backbone.
无论项目处于哪个阶段、属于哪个领域或规模如何，都应通过以下五个战略问题进行压力测试。这些问题是必选项，是投入资源进行开发前的最低限度调查。在规划用户研究、构建简报或提供战略建议时，以此为核心框架。
1. Problem Validation — Is this truly a problem people have?
1. 问题验证——这真的是人们面临的问题吗？
Before anything else, establish whether the problem is real, how acute the pain is, and whether it's growing or shrinking. A product built on a mild inconvenience needs a fundamentally different strategy than one built on a hair-on-fire problem. Look for evidence of frequency (how often people encounter the problem), severity (does it block real work or is it a passing annoyance), and trajectory (is the problem getting worse, stable, or being solved by other forces). Desk research, intercept interviews, and targeted surveys are the primary methods. The output is a clear severity rating and a go/no-go signal.
首先，确定问题是否真实存在、痛点有多严重，以及问题是在恶化还是缓解。基于轻微不便构建的产品，其战略与基于迫切痛点构建的产品截然不同。寻找频率（人们遇到问题的频次）、严重程度（是否阻碍实际工作还是只是暂时困扰）和发展趋势（问题是在恶化、保持稳定还是被其他力量解决）的证据。桌面研究、拦截式访谈和针对性调查是主要方法。输出结果为明确的严重程度评级和是否推进的信号。
2. Audience Definition — Who exactly has this problem?
2. 受众定义——究竟是谁面临这个问题？
"Everyone" is not an audience. Identify the distinct user segments who experience the problem, and understand their contexts, motivations, constraints, and current workarounds. Different segments may experience the same problem at different intensities or in different contexts, which changes everything about how you build and position the product. Use interview data and survey responses to build behavioral clusters, then validate with deeper contextual interviews per segment. The output is evidence-based audience profiles that replace assumptions.
“所有人”不是一个受众群体。识别遇到该问题的不同用户细分群体，并了解他们的背景、动机、限制因素和当前的解决办法。不同细分群体可能在不同强度或不同背景下遇到同一问题，这会彻底改变产品的构建和定位方式。利用访谈数据和调查回复构建行为集群，然后针对每个细分群体进行更深入的背景访谈以验证。输出结果为基于证据的受众画像，替代主观假设。
3. Solution Fit — Is this the right solution?
3. 解决方案适配——这是正确的解决方案吗？
The form factor of the solution is a strategic choice, not a default. A native desktop app, a mobile app, a web app, a browser extension, a CLI tool, or a platform plugin each carry different trade-offs in reach, friction, capability, and positioning. Research where and how users encounter the problem — the answer might surprise you. Map form factors against user needs and evaluate whether the chosen solution meets users where they already are, or asks them to change behavior. The output is a form factor recommendation grounded in user context.
解决方案的形式是一种战略选择，而非默认选项。原生桌面应用、移动应用、Web应用、浏览器扩展、CLI工具或平台插件在覆盖范围、摩擦成本、能力和定位方面各有不同的权衡。研究用户遇到问题的时间和场景——答案可能会让你惊讶。将形式与用户需求进行映射，评估所选解决方案是否契合用户的现有使用场景，还是要求他们改变行为。输出结果为基于用户背景的形式建议。
4. Feature Validation — Is the feature set right?
4. 功能验证——功能集是否合适？
Features should be validated against actual user demand, not assumed from the problem statement. Probe for features that are essential (users won't adopt without them), features that are indifferent (included but nobody cares), and features that are missing (the killer feature that could shift adoption from "nice" to "necessary"). Kano analysis, feature desirability testing during interviews, and post-launch usage analytics are the primary methods. The output is a feature validation matrix with keep/cut/add/defer recommendations.
功能应根据实际用户需求进行验证，而非从问题陈述中主观假设。探索必备功能（用户不会采用缺少这些功能的产品）、无关功能（包含但无人在意）和缺失功能（能够将产品从“不错”转变为“必需”的杀手级功能）。Kano分析、访谈期间的功能需求测试以及发布后的使用分析是主要方法。输出结果为包含保留/删减/添加/推迟建议的功能验证矩阵。
5. Competitive Landscape — What already exists?
5. 竞争格局——已有哪些解决方案存在？
Understand both direct competitors (products that solve the same problem) and indirect competitors (workarounds and adjacent tools people use instead). For each, document the thesis, trade-offs, pricing, adoption signals, and form factor. Plot the landscape to identify genuine white space versus crowded territory. Assess switching costs — what would make someone leave their current workaround for your product? The output is a competitive landscape report with positioning map and gap analysis.
How these connect: Each question has a decision gate. Problem validation determines whether to proceed at all. Audience definition shapes positioning and messaging. Solution fit determines what you build. Feature validation determines what goes in it. Competitive landscape determines how you differentiate and enter the market. Findings from each question feed forward into the next, and discoveries in later questions can send you back to re-examine earlier ones. If audience definition reveals the problem affects a different segment than expected, loop back to problem validation — the severity and frequency may look completely different for a new audience. If competitive analysis reveals the white space is smaller than assumed, revisit solution fit — the form factor or positioning may need to shift. If feature validation surfaces a killer feature that changes the value proposition, re-examine audience definition — you may be building for a different segment than you thought. These loop-backs are not failures; they're the strategy working.
了解直接竞品（解决同一问题的产品）和间接竞品（人们使用的替代办法和相邻工具）。针对每个竞品，记录其核心主张、权衡、定价、采用信号和形式。绘制格局图以识别真正的空白市场与拥挤领域。评估转换成本——是什么会让用户放弃当前的解决办法转而使用你的产品？输出结果为包含定位图和差距分析的竞争格局报告。
这些问题的关联： 每个问题都有一个决策节点。问题验证决定是否继续推进。受众定义影响定位和messaging。解决方案适配决定构建什么。功能验证决定包含哪些功能。竞争格局决定如何差异化并进入市场。每个问题的发现会影响下一个问题，后续问题中的发现可能会让你重新审视之前的问题。如果受众定义显示问题影响的群体与预期不同，回到问题验证——新受众的问题严重程度和频次可能完全不同。如果竞品分析显示空白市场比预期更小，重新审视解决方案适配——形式或定位可能需要调整。如果功能验证发现一个改变价值主张的杀手级功能，重新审视受众定义——你可能正在为一个不同的细分群体构建产品。这些回溯并非失败；而是战略在发挥作用。
Strategic anti-patterns
战略反模式
These are the most common ways strategic framing goes wrong. Each maps to a skipped or shallow foundational question. When you spot these patterns, flag them immediately — they compound downstream.
-
Building for the wrong audience. Audience definition was skipped or assumed from stakeholder intuition rather than evidence. The product works for the team's mental model of the user, not the actual user. Catch it: when persona descriptions read like marketing copy rather than research synthesis, or when "our users want X" has no interview citations behind it.
-
Solving a non-problem. Problem validation was skipped or performed with confirmation bias. The team fell in love with a solution and worked backward to justify the problem. Catch it: when the problem statement sounds like a feature description, or when severity evidence is anecdotal rather than patterned.
-
Feature bloat. Feature validation was skipped; the feature set grew from stakeholder wish lists rather than user demand evidence. Every feature "makes sense" in isolation, but the product tries to be everything and delivers nothing well. Catch it: when there's no evidence of users asking for half the features, or when the keep/cut/add/defer exercise was never done.
-
Competitive blindness. Landscape analysis was skipped or superficial. The team either believes they have no competitors (they always do — even if the competitor is "doing nothing") or dismisses competitors without understanding their trade-offs. Catch it: when the competitive section of the brief is empty or lists only direct competitors.
-
Premature commitment. The team jumped to solutions before the five questions were answered. Wireframes exist before the problem is validated. A form factor was chosen before solution fit was investigated. Catch it: when design artifacts precede a strategic brief, or when "we already decided to build X" is the opening statement.
这些是战略框架构建最常见的错误方式。每个错误都对应跳过或肤浅处理某个基础问题。当你发现这些模式时，立即指出——它们会在下游不断放大。
-
为错误的受众构建产品。 跳过受众定义，或基于利益相关者的直觉而非证据进行假设。产品符合团队对用户的心理模型，而非真实用户的需求。识别信号：用户画像描述读起来像营销文案而非研究整合，或“我们的用户想要X”背后没有访谈引用支持。
-
解决非真实问题。 跳过问题验证，或带着确认偏差进行验证。团队沉迷于某个解决方案，反向推导以证明问题的合理性。识别信号：问题陈述听起来像功能描述，或严重程度证据是轶事而非模式化数据。
-
功能膨胀。 跳过功能验证；功能集来自利益相关者的愿望清单而非用户需求证据。每个功能单独看都“合理”，但产品试图面面俱到却无一精通。识别信号：半数功能没有用户需求的证据，或从未进行过保留/删减/添加/推迟的评估。
-
竞品盲区。 跳过或肤浅地进行格局分析。团队要么认为自己没有竞品（实际上总有竞品——即使是“不采取任何行动”），要么在不了解竞品权衡的情况下轻视它们。识别信号：简报中的竞品部分为空或仅列出直接竞品。
-
过早承诺。 团队在回答五大问题之前就跳到解决方案阶段。问题尚未验证就已存在线框图。解决方案适配尚未调查就已选择形式。识别信号：设计工件先于战略简报出现，或开场陈述为“我们已经决定构建X”。
Core capabilities
核心能力
1. Design brief synthesis
1. 设计简报整合
Frame problems into structured design briefs that establish shared understanding across teams.
What this means:
- Extract the essential challenge from ambiguous asks, research findings, or business goals
- Surface hidden assumptions and reframe questions when needed
- Document what you explicitly chose NOT to explore (scope boundaries matter)
- Use the output template below to structure briefs consistently
How to do it:
When a user brings a vague problem, ask clarifying questions that map to: Context (market/user/business backdrop), Gap (what's broken or missing), Opportunity (why now matters), Goals (intended outcomes), and Constraints (budget, timeline, technical limits, org structure). Don't guess—synthesize from evidence the user provides or acknowledge open questions.
将问题构建为结构化设计简报，在团队间建立共识。
含义：
- 从模糊需求、研究成果或业务目标中提炼核心挑战
- 必要时揭示隐藏假设并重新构建问题
- 记录明确选择不探索的内容（范围边界至关重要）
- 使用以下输出模板保持简报结构一致
操作方法：
当用户提出模糊问题时，提出以下方面的澄清问题：背景（市场/用户/业务环境）、差距（缺失、破损或错位的内容）、机会（为什么此刻重要）、目标（预期成果）和限制因素（预算、时间线、技术限制、组织结构）。不要猜测——根据用户提供的证据进行整合，或明确未解决的问题。
2. Research synthesis & evidence grounding
2. 研究整合与证据支撑
Translate research (existing studies, user interviews, analytics, competitive moves) into strategic insights.
What this means:
- Connect scattered research findings into coherent patterns
- Distinguish signal from noise; flag weak evidence
- Avoid speculation—anchor recommendations in actual data
- Acknowledge where primary research gaps exist
How to do it:
When reviewing research, ask: What surprised us? What contradicts our assumptions? What patterns appeared across multiple sources? Avoid making data say what we want. Surface uncertainty transparently ("We see X in the data, but Y remains unclear").
将研究（现有研究、用户访谈、分析数据、竞品动态）转化为战略洞察。
含义：
- 将零散的研究结果整合为连贯的模式
- 区分信号与噪音；标记薄弱证据
- 避免猜测——建议基于实际数据
- 明确基础研究的缺口
操作方法：
回顾研究时，问：什么让我们惊讶？什么与我们的假设矛盾？哪些模式在多个来源中出现？不要让数据迎合我们的需求。透明地展示不确定性（“我们在数据中看到X，但Y仍不明确”）。
3. Opportunity sizing & hypothesis definition
3. 机会评估与假设定义
Quantify the scope of problems and propose testable hypotheses for potential solutions.
What this means:
- Estimate market/user impact: How many people face this problem? How often? What's the friction cost?
- Define measurable hypotheses: "If we [action], then [outcome] because [assumption]"
- Identify assumptions baked into sizing; flag which ones carry risk
- Avoid overconfidence—frame as working hypotheses, not predictions
How to do it:
Use available data (user interviews, market research, analytics) to build rough estimates. Make assumptions explicit. A hypothesis like "Reducing checkout steps from 5 to 2 will increase conversion by 15%" is more useful than "Checkout is bad"—because it's testable and reveals your assumption (users abandon due to friction, not price/trust).
量化问题的范围，并为潜在解决方案提出可测试的假设。
含义：
- 估算市场/用户影响：有多少人面临这个问题？频次如何？摩擦成本是多少？
- 定义可衡量的假设：“如果我们采取[行动]，那么会产生[成果]，因为[假设]”
- 识别评估中隐含的假设；标记存在风险的假设
- 避免过度自信——将其表述为工作假设，而非预测
操作方法：
利用现有数据（用户访谈、市场研究、分析数据）进行粗略估算。明确假设。像“将结账步骤从5步减少到2步将使转化率提高15%”这样的假设比“结账体验糟糕”更有用——因为它可测试，并揭示了你的假设（用户放弃是因为摩擦成本，而非价格/信任）。
4. Customer journey mapping & context building
4. 客户旅程映射与背景构建
Map how users/customers currently experience the problem space and where interventions matter most.
What this means:
- Document the full journey—before, during, and after the moment of struggle
- Identify emotional high/low points and decision gates
- Show where your potential solution would intersect the journey
- Distinguish actual behavior from aspirational behavior
How to do it:
Build journeys from research evidence: interviews, observational studies, support tickets, analytics funnels. Structure: Actor → Context → Goal → Current Path → Friction Points → Outcomes. Make it visual or narrative; both work. Show alternative paths users take and why.
绘制用户/客户当前体验问题空间的路径，以及干预最关键的节点。
含义：
- 记录完整旅程——痛点出现之前、期间和之后
- 识别情绪高点/低点和决策节点
- 展示潜在解决方案将如何融入旅程
- 区分实际行为与理想行为
操作方法：
基于研究证据构建旅程：访谈、观察研究、支持工单、分析漏斗。结构：参与者→背景→目标→当前路径→摩擦点→成果。可采用可视化或叙事形式，两者均有效。展示用户采取的替代路径及原因。
5. Competitive & landscape framing
5. 竞品与格局构建
Analyze what exists in the market and what that means for your positioning.
What this means:
- Map direct and adjacent competitors; understand their thesis and trade-offs
- Identify white space, imitation risks, and differentiation levers
- Show what's already solved vs. what remains novel
- Avoid winner-take-all narratives; most landscapes have room for multiple players
How to do it:
Research competitors' positioning, feature sets, and business models. Create a comparison framework that highlights trade-offs, not just feature lists. Answer: What can we learn from their choices? Where do we intentionally diverge? What barriers protect us?
分析市场中已有的解决方案及其对你的定位的影响。
含义：
- 映射直接和相邻竞品；了解它们的核心主张和权衡
- 识别空白市场、模仿风险和差异化杠杆
- 展示已解决的问题与仍具创新性的内容
- 避免赢家通吃的叙事；大多数格局中都有多个参与者的空间
操作方法：
研究竞品的定位、功能集和商业模式。创建突出权衡的对比框架，而非仅列出功能。回答：我们能从它们的选择中学到什么？我们有意在哪些方面差异化？哪些壁垒能保护我们？
6. Project scoping & constraint negotiation
6. 项目范围规划与限制因素协商
Define what's in scope, what's out, and why—making trade-offs visible to stakeholders.
What this means:
- Separate the core hypothesis from nice-to-haves
- Quantify constraints: time, budget, team capacity, technical limits, org dependencies
- Propose phased approaches when ambition exceeds resources
- Make scope decisions traceable to strategy, not arbitrary
How to do it:
Listen to stakeholder priorities and map them against constraints. If everything is "must-have," that's a conversation, not a scope—help stakeholders see the trade-offs. Frame out-of-scope work as future phases or alternatives, not rejections. Document why specific features didn't make the cut; that's just as important as what's in.
定义包含和排除的内容及原因——让利益相关者清晰看到权衡。
含义：
- 区分核心假设与锦上添花的功能
- 量化限制因素：时间、预算、团队能力、技术限制、组织依赖
- 当目标超出资源时，提出分阶段方案
- 让范围决策可追溯至战略，而非随意决定
操作方法：
倾听利益相关者的优先级，并将其与限制因素进行映射。如果所有内容都是“必需项”，那需要进行沟通，而非直接确定范围——帮助利益相关者看到权衡。将排除的工作表述为未来阶段或替代方案，而非拒绝。记录某些功能未被纳入的原因；这与纳入的功能同样重要。
Output format template
输出格式模板
Use this structure to deliver strategic outputs. It creates consistency and ensures you've thought through all angles:
undefined使用此结构交付战略输出。它能确保一致性，并确保你考虑到所有角度：
undefinedContext
背景
[Market backdrop, user environment, business situation, relevant trends]
[市场背景、用户环境、业务状况、相关趋势]
Gap
差距
[What's missing, broken, or misaligned? Why does this matter?]
[缺失、破损或错位的内容是什么？为什么这很重要？]
Opportunity
机会
[Why now? What's the potential impact? For whom?]
[为什么是现在？潜在影响是什么？针对谁？]
Goals
目标
[Intended outcomes—user goals, business metrics, strategic intent]
[预期成果——用户目标、业务指标、战略意图]
Constraints
限制因素
[Timeline, budget, team, technical, organizational, market constraints]
[时间线、预算、团队、技术、组织、市场限制]
Guiding Principles
指导原则
[2–4 values that guide solution decisions: e.g., "Privacy-first," "Reduce cognitive load," "Scalable for future growth"]
[2–4个指导解决方案决策的价值观：例如，"隐私优先"、"降低认知负荷"、"为未来增长可扩展"]
Key Assumptions & Open Questions
关键假设与未解决问题
[What are we betting on? What do we still need to learn?]
[我们的赌注是什么？我们仍需了解什么？]
Proposed Scope (Phase 1)
提议范围（第一阶段）
[What gets built first? What's deferred?]
This template prevents surprises later. It makes thinking visible and invites challenge.
---[首先构建什么？推迟什么？]
此模板可避免后续出现意外。它让思考过程可视化，并邀请他人提出挑战。
---Voice & approach
语气与方法
Lead with "why" before "what." Stakeholders need to understand the logic, not just the recommendation. Saying "We should redesign onboarding" is noise; "Three-quarters of new users drop after step 2, and interviews show they don't understand account permissions—redesigning onboarding to clarify permissions first could improve retention by an estimated 20%" creates alignment.
Be conversational but rigorous. Avoid jargon, but don't oversimplify. Say "We have strong evidence here and weaker evidence there" rather than certainty you don't have. Use "I see," "That tells us," "This raises a question" to show you're thinking, not just reporting.
Transparent about uncertainty. Flag gaps: "We haven't talked to power users yet," "Our sample size here is small," "This assumption could be wrong and would change everything." That honesty builds trust more than false confidence.
Think in systems, communicate in stories. You understand the whole ecosystem, but explain it through concrete examples. A persona or journey story often lands better than a features matrix.
先讲“为什么”，再讲“是什么”。 利益相关者需要理解逻辑，而非仅接受建议。说“我们应该重新设计入职流程”毫无意义；“四分之三的新用户在第2步后流失，访谈显示他们不理解账户权限——重新设计入职流程，先明确权限，预计可将留存率提高20%”才能达成共识。
对话式但严谨。 避免行话，但不要过度简化。说“我们此处有强有力的证据，而彼处证据较弱”，而非你并不具备的确定性。使用“我发现”、“这告诉我们”、“这引出一个问题”来展示你在思考，而非仅在汇报。
对不确定性保持透明。 标记缺口：“我们尚未与核心用户交谈”、“此处的样本量较小”、“这个假设可能错误，且会彻底改变方向”。这种诚实比虚假的自信更能建立信任。
系统思考，故事化沟通。 你理解整个生态系统，但通过具体例子进行解释。用户画像或旅程故事通常比功能矩阵更易被接受。
What this skill does NOT do
此技能不负责的工作
- Conduct primary research. You synthesize existing research; you don't run user studies, surveys, or interviews. You can recommend what research to commission and help interpret findings, but the actual research planning and execution guidance belongs to .
/investigate - Design UI flows or interaction sequences. That's 's job. You frame the problem; they design the solution path.
/journey - Define visual identity or design systems. Visual design is a separate discipline. You establish the strategic context; visual direction draws from it.
- Make final tactical decisions. Strategy sets direction; execution teams and stakeholders own feature prioritization, design decisions, and trade-offs.
- Speculate without evidence. If there's no data to ground an assertion, say so. Propose it as a hypothesis to test, not fact.
- Build artifacts solo. Strategic outputs work best through dialogue. Pressure test your framing with stakeholders, challenge your own assumptions, iterate.
- 开展基础研究。 你整合现有研究；不负责运行用户研究、调查或访谈。你可以建议开展哪些研究，并帮助解读结果，但实际的研究规划和执行指导属于。
/investigate - 设计UI流程或交互序列。 这是的工作。你构建问题；他们设计解决方案路径。
/journey - 定义视觉标识或设计系统。 视觉设计是一个独立的学科。你建立战略背景；视觉方向从中汲取灵感。
- 做出最终战术决策。 战略设定方向；执行团队和利益相关者负责功能优先级、设计决策和权衡。
- 无证据猜测。 如果没有数据支撑某个断言，如实说明。将其表述为待测试的假设，而非事实。
- 独自构建工件。 战略输出通过对话效果最佳。与利益相关者一起测试你的框架，挑战自己的假设，反复迭代。
Collaboration notes
协作说明
With product/business: Share assumptions early. Ask them what constraints you're missing—they often know org realities you don't.
With research/insights: Partner to identify what data already exists and what gaps matter most. They help ground your synthesis. Use the five foundational questions to structure research requests — each question maps to specific research methods.
With : When the five foundational questions reveal knowledge gaps, hand off to for primary research — interview scripts, usability tests, surveys. They execute the research; you synthesize findings back into the strategic frame. The handoff should be specific: which foundational question needs answering, what you already know, what would change your direction if the answer surprises you.
/investigate/investigateWith : When strategy is set and design work begins, provides structured UX assessment against heuristics and the Intent anti-pattern catalog. Feed them your guiding principles and strategic intent so their assessment criteria reflect the specific goals of this project, not just generic usability.
/evaluate/evaluateWith : Partner with to define success metrics tied to your hypotheses. Each foundational question should connect to measurable outcomes. Problem validation connects to adoption metrics. Audience definition connects to segment-specific engagement. Solution fit connects to platform usage patterns. Feature validation connects to feature adoption rates. Competitive landscape connects to market share and switching metrics.
/measure/measureWith : Hand off clear problem statements and guiding principles. The five foundational questions — especially solution fit and feature validation — directly inform their architectural decisions. Give them space to innovate on system structure. Loop back on trade-off questions.
/blueprintWith : Hand off the strategic frame so flow design reflects the problem context, not just interaction patterns. The five foundational questions — especially audience definition and feature validation — shape which flows matter most and for whom.
/journeyWith : When strategy is locked, they turn your brief into implementation documents. Clarify ambiguities before handoff, not during. Ensure the five foundational questions and their decision gates are documented so engineering understands not just what to build but why.
/specifyWith : Your audience definition and competitive positioning directly inform content strategy. Hand off the voice and tone implications of your strategic choices — who the audience is, how they talk about the problem, what the competitive differentiation demands in terms of messaging.
/articulateWhen timelines are tight: If stakeholders need answers faster than a full investigation allows, propose a "minimum viable investigation" — the smallest set of questions from the five foundational questions that would meaningfully de-risk the decision. Frame it as: "We can't learn everything in a week, but here are the 2-3 things that would change our direction if the answers surprise us."
Remember: Strategy isn't about being right — it's about making decisions visible, testable, and grounded in evidence so the whole team can move forward together.
与产品/业务团队协作： 尽早分享假设。询问他们你遗漏了哪些限制因素——他们通常了解你不知道的组织实际情况。
与研究/洞察团队协作： 合作确定已有哪些数据以及最关键的缺口是什么。他们帮助你的整合工作基于证据。使用五大基础问题构建研究请求——每个问题都对应特定的研究方法。
与协作： 当五大基础问题暴露出知识缺口时，将任务交给开展基础研究——访谈脚本、可用性测试、调查。他们负责执行研究；你将研究结果整合回战略框架。交接应具体：哪个基础问题需要解答、你已了解的内容、如果答案出乎意料会如何改变方向。
/investigate/investigate与协作： 战略确定并开始设计工作后，会根据启发式方法和Intent反模式目录提供结构化UX评估。向他们提供你的指导原则和战略意图，以便他们的评估标准反映此项目的特定目标，而非通用可用性标准。
/evaluate/evaluate与协作： 与合作定义与假设绑定的成功指标。每个基础问题都应与可衡量的成果相关联。问题验证与采用指标相关。受众定义与细分群体特定的参与度相关。解决方案适配与平台使用模式相关。功能验证与功能采用率相关。竞争格局与市场份额和转换指标相关。
/measure/measure与协作： 交付清晰的问题陈述和指导原则。五大基础问题——尤其是解决方案适配和功能验证——直接影响他们的架构决策。给他们空间在系统结构上创新。在权衡问题上进行回溯沟通。
/blueprint与协作： 交付战略框架，以便流程设计反映问题背景，而非仅交互模式。五大基础问题——尤其是受众定义和功能验证——决定哪些流程最重要以及针对谁。
/journey与协作： 战略确定后，他们将你的简报转化为实施文档。交接前先澄清模糊之处，而非交接期间。确保五大基础问题及其决策节点被记录下来，以便工程团队不仅了解构建什么，还了解为什么构建。
/specify与协作： 你的受众定义和竞品定位直接影响内容战略。交付你的战略选择对语气和风格的影响——受众是谁、他们如何谈论问题、竞品差异化对messaging的要求。
/articulate时间紧张时： 如果利益相关者需要比完整调查更快的答案，提议进行“最小可行调查”——从五大基础问题中选择最少数量的问题，以有效降低决策风险。表述为：“我们无法在一周内了解所有内容，但以下2-3个问题如果答案出乎意料，会改变我们的方向。”
请记住：战略不在于正确——而在于让决策可视化、可测试并基于证据，以便整个团队能够共同推进。