accelint-persona-review

基于人物角色的设计评审

从特定运营人员人物角色的视角评估 Figma 设计。泛泛的 UX 建议（“让它更直观”）会错失那些从人物角色已记录的个人档案——其职责、痛点、所监控的系统以及运营背景——中浮现出来的洞见。

工作流

1. 加载人物角色档案

首先加载人物角色索引，以查找可用的人物角色：

Read references/personas/_index.md

然后加载用户请求的特定人物角色：

Read references/personas/{persona-id}.md

不要加载多个人物角色文件——只加载用户请求的那一个。

暂时不要加载 evaluation-examples.md——等到第 4 步再加载。

如果人物角色不存在，请从索引中列出可用的选项，并请用户进行选择。

2. 收集设计背景

提供了 Figma URL： 使用合适的 Figma MCP 工具获取设计（例如，mcp__figma-desktop__get_design_context，并从 URL 模式 node-id=1-2 → 1:2 中提取出的 node ID）。

无 URL（默认）： 使用 Figma MCP 桌面端获取当前文件/选区。如果未选中任何内容，请提示用户选择一个画板或组件。

Figma MCP 不可用： 请用户提供设计的截图。使用视觉检查来分析截图，但请注意，如果没有完整的设计背景（组件属性、布局约束、交互状态），评审将仅限于视觉元素。

3. 搜索支撑文档

使用 Outline MCP 查找相关背景。由于 Outline 需要选择工作区，请使用以下模式：

ListMcpResourcesTool(server: "outline")

搜索涵盖以下内容的文档：

• 针对该运营人员角色的 UI 标准/指南
• 以往的设计评审或反馈
• 系统需求或规格
• 培训材料或用户指南

优先选择提及该人物角色的角色、职责或其交互系统的文档。

Outline MCP 不可用： 仅基于人物角色档案和设计背景进行评审。在评审中指出没有可用的支撑文档，并建议应查阅组织标准的领域。

4. 分析并评审

加载评估示例以校准你的方法：

Read references/evaluation-examples.md

使用下方的评估框架，但根据发现来调整结构——不要将洞见强行塞进僵化的章节中。

评估框架

认知负荷评估

• 信息密度：考虑到他们的经验水平和工作节奏，他们能否处理所有展示的数据？
• 视觉层级：对其角色至关重要的信息是否能立即凸显出来？
• 心智模型：界面是否与他们已经在使用的系统相匹配（记录在“看到”中）？

沟通模式契合度

• “说与做”支持：UI 是否有助于他们典型的行动和沟通？
• 工作流集成：这与已记录的工作流契合程度如何？
• 错误预防：它是否能预防与其已记录痛点相符的错误？

痛点缓解

• 直接缓解痛点：此设计解决了哪些已记录的痛点？
• 无意中制造的痛点：这是否引入了新的摩擦或复杂性？
• 系统整合：如果他们要在多个系统之间周旋，这是否减少了上下文切换？

背景感知

• 经验校准：复杂度是否与其职级/经验相符（例如，E4 与 E7）？
• 职责契合度：设计是否支持他们的具体职责？
• 日程考量：考虑到他们的工作日程/节奏，他们能否有效地使用此设计？

系统可见性

• “看到”覆盖范围：他们监控的系统是否可见/可访问（例如，BCS-F、RS-4、ERSA）？
• 集成缺口：缺少哪些关键系统？
• 冗余：是否对他们已在别处看到的信息进行了不必要的重复？

通信支持

• “Hears” 集成：设计是否支持他们的通信渠道（例如 Surveillance Net）？
• 信息传递：他们能否像 “Says & Does” 中记录的那样轻松传递信息？
• 通知设计：警报/通知是否适合他们的注意力预算？

输出结构

按以下通用格式提供评审意见（可根据需要调整）：

## Persona Review: [Persona Name]

### Design Summary
[1-2 sentence summary of what you reviewed]

### Critical Findings
[2-3 most important insights specific to this persona]

### Detailed Evaluation

**Cognitive Load**: [Assessment with specific examples from persona profile]

**Communication Patterns**: [How well it supports their "Says & Does"]

**Pain Point Mitigation**: [Which pain points addressed/created]

**Context Awareness**: [Appropriate for their experience/responsibilities]

**System Visibility**: [Coverage of their "Sees" systems]

**Communication Support**: [Integration with their "Hears" channels]

### Recommendations
[Prioritized list of actionable improvements, grounded in persona profile]

### Supporting References
[Links to relevant Outline docs found during research]

这是示例结构，不是固定模板。 根据以下因素调整：

• 特定领域中发现的深度
• 角色画像的完整程度
• 设计范围（组件 vs. 完整仪表盘）

关键要素是：

1. 与角色已记录画像的清晰关联
2. 具体、可执行的建议
3. 基于运营影响的优先级排序
4. 来自支持文档的证据（如有）

评估原则

针对角色具体化：泛泛的 UX 建议对谁都没帮助。每一条观察都应基于角色已记录的画像（Profile、About、Hears、Sees、Says & Does、Pain Points）。

优先考虑运营影响：对于高节奏操作员来说，一个破坏肌肉记忆的轻微 UI 不一致，比重大视觉打磨问题更重要。要考虑他们工作的风险。

假定具备领域专业知识：这些操作员是其领域的专家。不要提出移除其履职所需复杂性的“简化”建议。

考虑完整上下文：审阅他们的整个画像 - 洞察往往来自各部分之间的联系。某一领域的痛点可能与他们会监控的系统或使用的通信渠道有关。

跨画像部分建立联系：最有价值的洞察会综合角色画像的多个部分（例如，痛点 + 他们看到的系统 + 他们采取的行动 = 整合解决方案机会）。

评审时绝不要做

• 绝不要给出泛泛的 UX 建议，如“让它更直观”或“改善用户体验” - 这些可以适用于任何界面。每一条观察都应基于角色的具体画像。
• 绝不要建议移除必要复杂性的简化 - 这些操作员是领域专家。服务于其已记录职责的复杂性是有价值的。
• 绝不要忽略运营上下文 - 对于高节奏操作员来说，破坏肌肉记忆的轻微 UI 不一致比重大视觉打磨问题更重要。
• 绝不要把所有角色都当作相同 - 对同一界面，E4 AST 评审应与 O4 MCC 评审不同。
• 绝不要跳过加载角色画像 - 没有角色上下文的泛泛评审会错过这项技能的全部价值。

参考资料

• 角色画像：references/personas/{persona-id}.md
• 角色索引：references/personas/_index.md
• 评估示例：references/evaluation-examples.md

按需加载这些内容，以尽量减少上下文占用。