@chantezy/mcp-product-design 0.1.0 → 0.1.2

package/skills/requirements-content-analysis/SKILL.md

@@ -0,0 +1,792 @@
+---
+name: requirements-content-analysis
+description: 面向产品需求文档（PRD）的结构化内容解析与交互设计导向分析能力。通过对需求目标、核心功能、用户路径及关键场景的快速拆解，提炼影响体验质量的关键要素，识别潜在的交互风险与设计机会点，并输出高度凝练的重点分析报告。该能力有助于设计师在早期阶段建立对需求的系统性认知，提升设计决策的前瞻性与有效性，同时为后续体验方案的制定提供清晰依据。
+trigger: 当用户需要分析需求、拆解需求、梳理需求背景、理解业务目标、识别交互风险时使用
+---
+# 需求内容分析
+
+
+## 概述
+
+  
+
+生成全面、结构清晰的交互设计分析报告，统一利益相关者意见并指导设计项目。此技能帮助设计师创建清晰的需求分析报告，定义项目范围、目标、约束条件和成功标准。
+
+  
+  
+
+---
+
+  
+
+## 快速开始
+
+  
+
+这将引导您创建一个涵盖以下内容的需求分析报告：
+
+- 项目背景
+
+- 目标用户
+
+- 设计优先级评估
+
+- 方案设计
+
+- 验证标准
+
+
+
+  
+
+---
+
+  
+
+## 核心工作流程
+
+  
+
+### 何时创建分析报告
+
+  
+
+**使用设计简报的场景：**
+
+- 产品/功能设计需求分析
+
+- 快速整理PRD内容并梳理重要信息
+
+  
+
+**不建议使用的场景：**
+
+- 微小的 UI 调整
+
+- Bug 修复
+
+- 现有设计的小迭代
+
+  
+
+---
+
+  
+
+## 需求分析组件
+
+  
+
+### 一、需求背景
+
+  
+
+**包含内容：**
+
+- 项目名称和描述
+
+- 背景描述和上下文
+
+- 为什么这个需求现在很重要
+
+- 业务目标
+
+- 要解决的用户问题
+
+- 功能影响范围
+
+  
+
+**示例：**
+
+```markdown
+
+## 需求背景
+
+  
+
+**项目：** 游拍直播首页样式优化
+
+**背景：** 因游拍业务定位调整，签约公会在减少，后续主播的量也慢慢减少，展示内容再不断减少且短时间无法改变，所以首页内容展示策略上需要做下优化
+
+**业务目标：** 降低直播内容数少的用户感知，避免用户形成平台活跃度低的负面印象
+
+**用户问题：** 内容减少后对浏览的体验会变差，对平台失去信任度加速流失
+
+```
+
+  
+
+---
+
+  
+
+### 二、目标用户与用户场景
+
+  
+
+**我们为谁而设计：**
+
+- 主要目标用户类型
+
+- 用户需求和痛点
+
+- 用户目标和动机
+
+- 技术熟练度
+
+- 使用场景
+  - 用户在什么情况，以及何时何地碰到这个问题
+  - 痛点问题
+  - 理解目标用户的期望，需要，动机
+
+
+**示例：**
+
+```markdown
+
+## 目标用户与使用场景
+
+  
+
+**目标用户：** 主播用户和观看直播用户两类
+
+- **年龄层：** 主要在15-25 岁
+
+- **目标：** 对不同用户提供差异化功能价值。主播用户：提供更多直播内容的个性化展示，优质内容获得更多曝光；观看直播用户：更直观的直播相关信息获取，观看成本更低
+
+- **痛点：** 内容浏览太少
+
+- **场景：** 主要在桌面端使用，偶尔移动端，需要同事考虑各端对展示内容方式的影响
+
+```
+
+  
+
+---
+
+  
+
+### 三、设计目标
+
+  
+
+**设计方向实施：**
+
+- 主要设计目标
+   - 次要目标
+
+- 问题梳理
+
+- 用户关键路径
+  - 想法
+  - 操作
+  - 痛点
+  - 功能支持
+
+
+**示例：**
+
+```markdown
+
+## 设计目标
+
+  
+
+**主要目标：** 对于直播业务来说，用户的核心路径是进入直播间中，进行观看直播，并且与主播和其他用户间形成交流互动的行为。目前平台的内容量不适合用户长时间停留筛选直播间，首页的功能价值在于快速使用户做出决策进入到直播间中
+
+  
+
+**问题梳理：**
+
+- 直播推荐封面同质化严重：封面内容展示差异不大，难以形成主播之间内容区别
+
+- 推荐内容方式过于单一且分散：不同页面位置样式区分不大，较难吸引用户
+
+- 信息框架过于冗余复杂：作为分发入口，直播列表相似选择太多导致用户决策成本过高
+
+在列表展示策略上以“推荐”代替“选择”，更注重用户直播列表浏览的相关性，针对用户进行推荐策略个性化差异，区别以往的所有用户相同推荐列表的方式，目的是让内容更吸引用户并形成最终转化
+  
+
+**用户关键路径：**
+
+1. 进入首页
+
+2. 点击"直播封面"
+
+3. 进入直播间
+
+4. 用户聊天区互动
+
+|**行为**|**预期**|**机会点**|
+|---|---|---|
+|1、直播互动|发送弹幕、打赏、赠送礼物|互动体验良好，包括弹幕和礼物等功能流畅操作简单易懂|
+|3、关注主播|开播状态跟进，直播间内容二次访问|开播状态时效性通知，守护功能|
+|2、观看直播|持续观看直播，直至主播结束直播|界面清晰，直播内容高质量|
+|直播间网络，线路清晰度选择，稳定性进行持续优化|||
+|直播间切换，寻找感兴趣的直播间|||
+|直播间样式提供视觉体验|||
+   
+**功能支持：**
+
+- 调整直播推荐样式更多展示直播相关信息：整合推荐内容结构，增强差异快速识别
+
+- 满足不同用户观看直播的类型需求：动态个性化推荐，前置直播内容
+
+
+```
+  
+
+---
+
+
+
+### 四、竞品分析
+
+  
+- **产品定位与目标用户**：解决什么问题、核心人群是谁、使用场景边界
+
+- **核心功能结构**：功能模块划分、信息架构、是否有差异化能力
+
+- **关键路径体验**：注册→使用→转化的主流程是否顺畅，有没有明显阻塞点
+
+- **差异化与壁垒**：独特优势在哪，是否容易被复制
+
+
+
+**示例：**
+
+```markdown
+
+## 竞品分析
+
+竞品选择上与以往不同，业务策略改变后与头部产品有所区别，不再以大的内容量展示为基础。设计风格上偏向国外直播产品的风格趋同，更多展示直播相关信息为主的大卡片式设计。
+
+**竞品一：KICK**
+
+竞品截图流程
+
+**竞品二：Twitch**
+
+竞品截图流程
+
+**分析总结：**
+
+根据竞品设计思路进行总结，对原本平台进行更精简的结构整理，原热门和推荐两个tab内容相似度太高，进行精简化的合并处理，保留游戏分标签页内容，但对样式进行处理，增加主播相关信息和直播内容的曝光
+
+合并后的内容分为三个大类型，分别是热门推荐、用户关系、游戏分类模块，对内容进行整合，方便多入口跳转，区分“推荐”和“游戏分类”两个主要类型
+
+
+```
+
+  
+---
+
+### 五、设计策略
+
+  
+综合竞品及前面的分析内容得出可实践的设计策略，进行分点描述
+  
+
+**示例：**
+
+```markdown
+
+## 设计策略
+
+  
+
+**简化页面结构，模块化界面**
+
+列表推荐策略根据用户历史观看、关注等因素显示
+
+页面长度根据模块灵活配置，固定列表样式增加内容量，配置选项卡提升内容吸引力
+
+顶部轮播区域涉及活动等旧素材的尺寸规范和设计投入，因此不做样式改动，考虑到直播总数影响，只做减少分类图标个数的策略，降低页面高度，减少游戏分类的重复显示
+
+  
+
+**轻量化交互，高效获取信息**
+
+直播推荐中加强直播中状态强化与视频内容的区分，突出直播间的热度数据，为热门直播间引流
+
+个人信息方面加入标签系统，根据用户开播选择和个人信息相关展示，突出差异化
+
+直播自动播放和最新弹幕显示，前置直播的内容，营造热闹活跃的氛围，能更有好的吸引用户，方便筛选不同直播间
+
+
+**用户关联信息引导**
+
+针对已关注主播和未关注主播不同的信息获取侧重点，做信息差异化显示
+
+已关注主播突出正在直播状态，做排序优先策略
+
+推荐主播则突出显示主播推荐的相关信息，增加吸引力，整合所有主播推荐榜单的类型，优先显示正在直播中的用户，让用户有内容可看
+
+
+```
+
+  
+
+---
+
+
+### 六、设计原则与方向
+
+  
+
+**项目的指导原则：**
+
+- 核心设计原则
+
+- 视觉方向
+
+- 交互模式
+
+- 内容策略
+
+- 无障碍要求
+
+  
+
+**示例：**
+
+```markdown
+
+## 设计原则
+
+  
+
+1. **清晰优于巧妙** - 用户永远不需要猜测下一步该做什么
+
+2. **渐进式披露** - 显示需要的内容，隐藏复杂性
+
+3. **一致的模式** - 使用已有的设计系统组件
+
+4. **默认可访问** - WCAG AA 最低标准，争取 AAA
+
+```
+
+  
+
+
+---
+
+  
+
+
+  
+
+### 七、设计方案交付
+
+  
+
+**将交付的内容：**
+
+  
+
+**设计交付物：**
+
+- 用户研究（如需要）
+
+- 交互原型
+
+- 设计规格说明
+
+- 组件文档
+
+- 交互说明标注
+
+  
+
+---
+
+  
+
+### 八、设计验证
+
+  
+
+**如何衡量成功：**
+
+  
+
+**定性指标：**
+
+- 用户测试反馈
+
+- 利益相关者认可
+
+- 设计师评审
+
+- 无障碍审核通过
+
+  
+
+**定量指标：**
+
+- 任务成功率
+
+- 任务完成时间
+
+- 错误率
+
+  
+
+**示例：**
+
+```markdown
+
+## 设计验证标准
+
+  
+
+**可用性测试：**
+
+- 8/10 用户无需帮助即可完成主要任务
+
+- 平均 SUS 评分：75+
+
+- 零关键无障碍问题
+
+  
+
+**业务指标（上线后）：**
+
+- 第 30 天留存率 40%（从 15% 提升）
+
+- 90% 任务完成率
+
+- < 5% 错误率
+
+```
+
+  
+
+---
+
+  
+
+## 设计项目类型
+
+  
+
+### 1. 功能优化设计
+
+  
+
+**重点领域：**
+
+- 用户需求验证
+
+- 与现有产品整合
+
+- 交互模式
+
+- 边缘情况
+
+  
+
+需求分析报告：** 标准报告，重点关注用户流程
+
+  
+
+---
+
+  
+
+### 2. 新项目设计
+
+  
+
+**重点领域：**
+
+- 当前状态分析
+
+- 有效/无效的部分
+
+- 用户习惯迁移考虑
+
+
+  
+
+**附加部分：**
+
+- 当前痛点
+
+- 竞品分析
+
+- 设计审核发现
+
+  
+
+---
+
+  
+
+### 3. 设计系统
+
+  
+
+**重点领域：**
+
+- 组件清单
+
+- 设计原则
+
+- 使用指南
+
+- 治理规范
+
+  
+
+**附加部分：**
+
+- 采用策略
+
+- 文档计划
+
+- 维护计划
+
+  
+
+---
+
+  
+
+## 利益相关者对齐
+
+  
+
+### 发现问题
+
+  
+
+**开始前需询问：**
+
+1. 我们要解决什么问题？
+
+2. 用户是谁？
+
+3. 业务目标是什么？
+
+4. 时间表是什么？
+
+5. 有什么约束条件？
+
+6. 如何衡量成功？
+
+7. 谁需要批准？
+
+  
+  
+---
+
+
+## 需求分析文档最佳实践
+
+  
+
+### 应该做：
+
+- ✅ **从"为什么"开始** - 清晰陈述问题
+
+- ✅ **定义成功** - 具体、可衡量的标准
+
+- ✅ **包含约束条件** - 技术、时间、资源
+
+- ✅ **展示示例** - 参考、灵感
+
+- ✅ **尽早获得认可** - 与利益相关者审查草稿
+
+- ✅ **保持简洁** - 最多 2-3 页
+
+- ✅ **视觉化呈现** - 包含图表、设计稿、参考图
+
+  
+
+### 不应该做：
+
+- ❌ **直接跳到解决方案** - 先关注问题
+
+- ❌ **模糊不清** - "做得更好"没有帮助
+
+- ❌ **忽略约束条件** - 约束条件塑造解决方案
+
+- ❌ **孤军奋战** - 尽早让产品经理和工程团队参与
+
+- ❌ **跳过研究** - 基于数据做决策
+
+- ❌ **忘记无障碍** - 从一开始就要考虑
+
+
+
+---
+
+  
+
+## 设计简报示例
+
+  
+
+### 示例 1：
+
+  
+
+```markdown
+
+# 需求分析报告：告警平台权限管理设计
+
+  
+
+## 一、需求背景
+
+平台增加权限设计，为方便之后各个项目接入，设置统一的权限中台
+
+
+**业务目标：** 通过为角色配置权限，将用户（或用户组）与角色关联，来生效权限设置
+
+**用户问题：** 
+
+ 
+
+## 二、目标用户与用户场景
+
+对分组所有用户授权相同的权限；对用户授权相同的权限
+
+授权流程1
+授权流程2
+
+
+
+## 三、设计目标
+
+- 页面权限：进入系统后能看到哪几个页面
+- 操作权限：对页面进行增删改查（与页面权限相关联）
+- 数据权限：不同的人在相同的页面所能看到的数据不同
+
+  
+
+## 四、竞品分析
+
+- 神测数据：将所有功能结构显示平铺方便整体查看；不足是权限过多情况下，页面内容展示效率不高
+- 钉钉：对权限设置较少时有更详尽的说明信息；不足是不适合多权限
+- 飞书：对所有权限进行树状结构排序，适合显示多个关联层级；不适合整体的相同层级信息浏览
+
+  
+
+## 五、设计策略分析
+
+现有业务解决方案问题
+
+- 要作为中台接入使用的话，对功能多层级多的平台不友好
+
+满足设计目标的策略方向评估
+
+- 满足多个层级结构的方式
+  - 树状结构展开，纵向对内容进行延伸，满足数量不定的层级要求
+- 优化树状结构的信息浏览效率问题
+  - 增加搜索定位特定功能
+  - 对操作权限进行单独位置处理节省竖向空间
+
+## 六、设计方案
+
+```
+
+  
+
+---
+
+
+### 参考资料
+
+设计心理学方向参考  `references/Cognitive Psychology.md`
+设计原则方面的参考  `references/Interaction-design-principles.md`
+当用户有明确产品的平台端时，参考  `references/Multi-Platform Design Principles.md`
+  
+
+
+---
+
+  
+
+## 常见陷阱
+
+  
+
+### 陷阱 1：范围过宽
+
+  
+
+**问题：** "重新设计整个应用"
+
+**解决方案：** 分为多个阶段，分清优先级
+
+  
+
+### 陷阱 2：先入为主
+
+  
+
+**问题：** "让它看起来像苹果"
+
+**解决方案：** 从用户问题出发，而非美学
+
+  
+
+### 陷阱 3：没有约束
+
+  
+
+**问题：** 忽略技术/时间限制
+
+**解决方案：** 记录并尊重约束条件
+
+  
+
+### 陷阱 4：跳过研究
+
+  
+
+**问题：** 基于假设设计
+
+**解决方案：** 至少回顾现有数据
+
+  
+
+### 陷阱 5：成功标准模糊
+
+  
+
+**问题：** "做得更好"无法衡量
+
+**解决方案：** 定义具体、可测试的标准
+
+  
+
+---
+
+  
+
+## 总结
+
+  
+
+一个优秀的设计简报：
+
+  
+
+1. **清晰定义问题**
+
+2. **设定目标和成功标准**
+
+3. **识别用户及其需求**
+
+4. **记录约束条件**（时间、技术、预算）
+
+5. **尽早对齐利益相关者**
+
+6. **指导工作但不限定死**
+
+7. **随着学习演进**
+