产品设计

请你作为一位精通 Stanford d.school 设计思维方法论的产品设计导师，引导我完成以下产品设计挑战的全流程分析。

【产品设计挑战】：[在这里描述你要设计的产品或要解决的问题，例如：为独居老人设计一款简单易用的健康管理 App]

请按照设计思维五步法的完整流程进行分析：

## 第一步：共情（Empathize）

### 用户画像构建
- 目标用户是谁？请构建 2-3 个具有代表性的用户画像（Persona），包括：
  - 基本人口统计信息（年龄、职业、生活状态）
  - 行为模式和日常习惯
  - 核心需求和深层动机
  - 痛点和挫折来源
  - 技术素养和使用习惯

### 共情地图（Empathy Map）
针对主要用户画像，绘制共情地图：
- **说（Say）**：用户在描述这个问题时会说什么？
- **想（Think）**：用户内心真正在想什么？（可能与说的不一样）
- **做（Do）**：用户当前是如何处理这个问题的？
- **感（Feel）**：用户在处理过程中的情绪变化？

### 田野调查建议
- 建议进行哪些类型的用户研究？（访谈、观察、日记研究等）
- 设计 5 个关键的用户访谈问题
- 识别哪些是用户表达的需求（Explicit Needs），哪些是未表达的潜在需求（Latent Needs）

## 第二步：定义（Define）

### 问题重构
- 基于共情阶段的发现，真正的问题是什么？（可能与最初描述的不同）
- 使用 POV（Point of View）陈述格式：
  "[用户] 需要 [某种方式] 来 [达成目标]，因为 [深层洞察]"
- 提出 3 个不同角度的 HMW（How Might We）问题：
  "我们如何能够……"

### 设计原则
- 基于用户洞察，提炼 3-5 条设计原则（Design Principles）
- 这些原则将指导后续所有设计决策

## 第三步：构思（Ideate）

### 发散阶段
- 针对每个 HMW 问题，用"疯狂八分钟"（Crazy 8s）思维方式，快速产生 8 个创意方案
- 运用类比思维：其他行业如何解决类似问题？
- 运用逆向思维：如果故意把体验做差，会怎样？反过来呢？
- 运用极端用户思维：最极端的用户会需要什么？

### 收敛阶段
- 使用"2x2 矩阵"（可行性 × 影响力）对创意进行分类
- 筛选出 3 个最值得原型验证的方案
- 每个方案用一句话描述核心价值主张

## 第四步：原型（Prototype）

针对筛选出的方案：
- 每个方案的最小原型应该是什么？（纸面原型、线框图、故事板等）
- 原型需要验证的核心假设是什么？
- 原型不需要包含什么？（明确原型边界）
- 建议的原型制作工具和方法
- 预计制作时间

## 第五步：测试（Test）

### 测试方案设计
- 建议的测试方式（可用性测试、A/B 测试、走廊测试等）
- 需要多少测试用户？如何招募？
- 设计 3-5 个核心测试任务
- 需要观察和记录的关键指标

### 反馈收集框架
- 哪些反馈表明方案成功？
- 哪些反馈表明需要迭代？
- 下一轮迭代的优先级建议

请确保每个步骤的输出都是具体可执行的，而不是抽象的方法论描述。

请你作为一位精通 Don Norman 设计心理学的资深交互设计评审专家，使用诺曼七大设计原则对以下产品/功能进行系统性审查。

【待审查产品/功能】：[在这里描述产品或具体功能，例如：某银行 App 的转账功能]

请按照以下框架逐一审查：

## 原则一：可视性（Visibility）

### 审查要点
- 用户打开页面/界面后，能否立即看清所有可用操作？
- 是否存在隐藏的功能入口需要用户"发现"？
- 系统当前状态（加载中、已完成、出错等）是否清晰可见？
- 重要信息是否被视觉层级（大小、颜色、位置）正确突出？

### 评分：[1-10 分]
### 问题清单
- [列出所有可视性相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则二：反馈（Feedback）

### 审查要点
- 用户的每个操作（点击、滑动、输入）是否都有即时反馈？
- 反馈的形式是否合适？（视觉、听觉、触觉）
- 操作成功和失败的反馈是否有明确区分？
- 长时间操作（如加载、处理）是否有进度指示？
- 错误反馈是否告诉用户"哪里错了"和"如何修正"？

### 评分：[1-10 分]
### 问题清单
- [列出所有反馈相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则三：概念模型（Conceptual Model）

### 审查要点
- 用户对这个功能的"心理模型"是什么？
- 系统的实际运作方式与用户的心理模型是否匹配？
- 是否使用了用户熟悉的隐喻来帮助理解？（如"购物车""文件夹"）
- 新用户能否在不阅读说明的情况下理解核心功能？
- 是否存在"Gulf of Execution"（执行鸿沟）或"Gulf of Evaluation"（评估鸿沟）？

### 评分：[1-10 分]
### 问题清单
- [列出所有概念模型相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则四：启示/功能可见性（Affordance）

### 审查要点
- 可点击/可交互的元素看起来是否"可点击/可交互"？
- 按钮、链接、输入框等元素的视觉暗示是否充分？
- 是否存在"看起来能点但不能点"或"能点但看起来不能点"的元素？
- 物理产品：形状、材质、大小是否暗示了正确的操作方式？
- 数字产品：是否正确使用了感知启示（Perceived Affordance）和符号启示（Signifier）？

### 评分：[1-10 分]
### 问题清单
- [列出所有启示性相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则五：约束（Constraints）

### 审查要点
- 是否通过物理约束、逻辑约束、语义约束或文化约束来防止用户犯错？
- 不可用的操作是否被禁用或隐藏（而非让用户操作后再报错）？
- 表单输入是否有合理的格式限制和即时验证？
- 危险操作（删除、支付等）是否有确认步骤？
- 是否存在"过度约束"导致灵活性不足的问题？

### 评分：[1-10 分]
### 问题清单
- [列出所有约束相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则六：映射（Mapping）

### 审查要点
- 控件的位置和排列是否与其控制的对象有自然的空间对应关系？
- 操作方向是否符合直觉？（如向上滑动 = 增加，向右 = 前进）
- 图标和功能之间的关联是否一目了然？
- 导航结构是否反映了用户的心理模型？

### 评分：[1-10 分]
### 问题清单
- [列出所有映射相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 原则七：一致性（Consistency）

### 审查要点
- 内部一致性：产品内部的相似功能是否使用相似的交互模式？
- 外部一致性：是否遵循平台规范和行业惯例？
- 视觉一致性：颜色、字体、间距、图标风格是否统一？
- 术语一致性：同一概念是否在所有地方使用相同的词汇？
- 行为一致性：相似的操作是否产生相似的结果？

### 评分：[1-10 分]
### 问题清单
- [列出所有一致性相关的问题]
### 改进建议
- [针对每个问题给出具体改进方案]

## 综合评估报告

### 总分：[7 个维度的加权平均分]
### 最关键的 3 个问题（按严重程度排序）
### 快速修复清单（Quick Wins）：成本低但影响大的改进
### 长期改进路线图：需要更大投入的结构性改进
### 与竞品对比：在这些维度上的相对优劣势

请用具体的界面元素和交互细节来支持每一个评价，避免空泛的评论。

请你作为一位精通 Clayton Christensen JTBD 理论的产品需求分析专家，帮我深入分析以下产品/领域的用户需求。

【产品/领域描述】：[在这里描述你的产品或想要进入的市场，例如：为职场新人设计的时间管理工具]

请按照 JTBD 方法论的完整框架进行分析：

## 第一步：识别核心 Job

### Job 陈述（Job Statement）
使用标准 JTBD 陈述格式："当 [情境] 时，我想要 [动机/目标]，这样我就能 [预期结果]"

请识别：
- 1 个核心功能性 Job（用户要完成的实际任务）
- 2-3 个相关的情感性 Job（用户希望获得的感受）
- 1-2 个社会性 Job（用户希望在他人眼中的形象）

### 消费链分析
用户在完成这个 Job 的全过程中，经历了哪些步骤？
1. 意识到需要（Trigger）
2. 寻找解决方案（Search）
3. 评估选项（Evaluate）
4. 获取/购买（Acquire）
5. 使用（Use）
6. 完成/处置（Dispose）

每个步骤中的困难和不满是什么？

## 第二步：分析当前"雇佣"方案

### 现有被"雇佣"的方案
用户当前雇佣了哪些产品/方法来完成这个 Job？
- 直接竞品（完成同样 Job 的同类产品）
- 间接竞品（用不同方式完成同样 Job 的产品）
- 非消费（用户选择"不解决"这个问题）

### "解雇"分析
用户在什么情况下会"解雇"（停止使用）当前方案？
- 当前方案的哪些不足让用户不满？
- 是功能不够好，还是体验不够好，还是价格不对？
- 用户迁移到新方案的障碍是什么？（习惯、数据迁移、学习成本等）

## 第三步：需求优先级排序（Outcome-Driven Innovation）

### 期望结果（Desired Outcomes）
列出用户在完成这个 Job 时的 10-15 个期望结果，格式为：
"[方向 + 指标 + 对象 + 情境约束]"

例如：
- 最小化 确认转账到账所需的时间
- 最大化 对收款人信息正确性的信心
- 最小化 在多个账户间切换的操作步骤

### 机会评分（Opportunity Score）
对每个期望结果评估：
- **重要性**（1-10）：这个结果对用户有多重要？
- **满意度**（1-10）：当前方案满足得如何？
- **机会分数** = 重要性 + MAX(重要性 - 满意度, 0)

机会分数 > 15 = 重大未满足需求（金矿）
机会分数 10-15 = 有价值的改进空间
机会分数 < 10 = 已被充分满足（避免过度投入）

## 第四步：挖掘 Job 背后的深层动机

### "五个为什么"分析
从表面的 Job 出发，连续追问 5 次"为什么"，挖掘深层动机：
- 表面 Job → 为什么？ → 为什么？ → 为什么？ → 为什么？ → 根本动机

### 情境触发分析（Switch Interview）
分析用户从"旧方案"切换到"新方案"的四股力量：
1. **推力**（Push）：对当前方案的不满
2. **拉力**（Pull）：新方案的吸引力
3. **惯性**（Habit）：对当前方案的依赖和习惯
4. **焦虑**（Anxiety）：对新方案的不确定和担忧

如何增强推力和拉力、减少惯性和焦虑？

## 第五步：需求转化为产品策略

### 核心价值主张
基于以上分析，这个产品的核心价值主张应该是什么？
- 一句话表达（Elevator Pitch）
- 与最强竞品的差异化定位

### 功能优先级
- 必须有（Must-have）：不做就无法完成核心 Job 的功能
- 应该有（Should-have）：显著提升 Job 完成质量的功能
- 可以有（Nice-to-have）：锦上添花的功能
- 不要做（Won't-have）：虽然用户可能提到但不应该做的功能（及原因）

请确保所有分析都基于对用户"要完成的工作"的深入理解，而非产品功能的罗列。

请你作为一位资深用户体验研究员，帮我绘制以下产品/服务的完整用户体验地图。

【产品/服务描述】：[在这里描述产品或服务，例如：在线教育平台从发现课程到完成学习的全流程]
【目标用户】：[描述目标用户，例如：25-35 岁想转行进入互联网行业的职场人]

请按照以下框架构建完整的体验地图：

## 第一步：确定旅程范围

### 旅程起点和终点
- 起点：用户与产品的第一个接触点是什么？（可能早于注册/下载）
- 终点：用户完成核心任务 or 离开产品的那个时刻
- 时间跨度：这段旅程持续多长时间？（分钟/天/周/月）

### 用户场景（Scenario）
- 触发事件：什么情况促使用户开始这段旅程？
- 用户期望：用户希望通过这段旅程达成什么目标？
- 成功标准：从用户角度，什么算"成功完成"？

## 第二步：识别关键阶段和触点

### 旅程阶段划分
将整个旅程分为 5-8 个关键阶段，每个阶段包含：

**阶段 N：[阶段名称]**

| 维度 | 详细描述 |
|------|---------|
| **用户行为（Doing）** | 用户在这个阶段具体做了什么？ |
| **思考（Thinking）** | 用户在想什么？有什么疑问？ |
| **感受（Feeling）** | 用户的情绪状态如何？（用 1-10 分标注情绪值） |
| **触点（Touchpoints）** | 用户通过什么渠道/界面与产品交互？ |
| **痛点（Pain Points）** | 这个阶段让用户感到困难/沮丧的地方？ |
| **机会点（Opportunities）** | 可以改善体验的潜在机会？ |

## 第三步：绘制情绪曲线

### 情绪变化趋势
- 为每个阶段标注情绪值（1 = 极度沮丧，10 = 极度满意）
- 连接各阶段情绪值形成情绪曲线
- 标注情绪波峰和波谷

### 关键时刻识别
基于情绪曲线，识别：
- **WOW Moment**（惊喜时刻）：情绪最高的时刻及其原因
- **Pain Moment**（痛苦时刻）：情绪最低的时刻及其原因
- **Truth Moment**（真相时刻）：决定用户是否继续/留存/推荐的关键时刻

## 第四步：前台与后台分析

### 前台体验（用户可见）
- 用户界面和交互流程
- 客服和人工服务触点
- 物理环境和氛围（如适用）

### 后台支撑（用户不可见）
- 支撑前台体验的后台流程
- 需要哪些系统和数据支持
- 跨部门协作节点

### 断裂点（Breakpoints）
- 前台承诺与后台交付不匹配的地方
- 部门间交接导致体验断裂的节点
- 线上到线下（或反向）切换的断裂点

## 第五步：体验优化策略

### 优先级矩阵
将所有发现的问题和机会点放入矩阵：
- 横轴：实现难度（低→高）
- 纵轴：对用户体验的影响（低→高）

### 分层优化策略
- **立即修复**（高影响 × 低难度）：列出具体行动
- **规划推进**（高影响 × 高难度）：设计实施路线图
- **顺手改善**（低影响 × 低难度）：纳入日常迭代
- **暂时搁置**（低影响 × 高难度）：记录但不立即行动

### 峰终体验设计
基于 Kahneman 的峰终定律（Peak-End Rule）：
- 如何设计旅程中的"峰值体验"？
- 如何设计完美的"结尾体验"？
- 哪些负面峰值需要优先消除？

请用表格和清晰的结构呈现体验地图，使其可以直接作为团队讨论的文档使用。

请你作为一位拥有 10 年经验的可用性工程专家，精通 Jakob Nielsen 的启发式评估方法论，对以下产品/功能进行系统性的可用性评估。

【待评估产品/功能】：[在这里描述产品或功能，例如：某电商 App 的购物车到支付的完整流程]

请按照 Nielsen 10 条可用性启发式原则逐一评估：

## 原则 1：系统状态可见性（Visibility of System Status）
**定义：** 系统应始终通过适当反馈在合理时间内告知用户当前状态。

- 用户是否始终知道自己在流程中的哪个位置？
- 加载状态、处理进度是否有清晰的视觉指示？
- 数据更新（如购物车数量变化）是否即时反映在界面上？
- **严重程度：** [0=不是问题, 1=装饰性问题, 2=次要问题, 3=主要问题, 4=灾难性问题]
- **具体问题描述和改进建议**

## 原则 2：系统与真实世界的匹配（Match Between System and the Real World）
**定义：** 系统应使用用户的语言（词汇、短语、概念），遵循真实世界的惯例。

- 产品用语是否是用户能理解的日常语言而非技术术语？
- 信息展示顺序是否符合用户的自然逻辑？
- 图标和隐喻是否来自用户熟悉的真实世界？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 3：用户控制与自由（User Control and Freedom）
**定义：** 用户经常误操作，需要"紧急出口"来快速撤销。

- 用户能否轻松撤销（Undo）和重做（Redo）操作？
- 误操作后是否有便捷的恢复路径？
- 用户是否可以自由退出当前流程而不丢失已输入的数据？
- 是否提供了"返回"和"取消"选项？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 4：一致性与标准（Consistency and Standards）
**定义：** 用户不应需要猜测不同的词语、情境或行动是否意味着同一件事。

- 是否遵循平台设计规范（iOS HIG / Material Design）？
- 相似功能在产品内是否有一致的交互模式？
- 术语、图标、按钮位置是否保持统一？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 5：错误预防（Error Prevention）
**定义：** 比好的错误信息更好的是精心设计以防止错误发生。

- 是否通过设计减少了用户犯错的可能性？
- 重要操作前是否有确认机制？
- 表单是否有实时校验和智能默认值？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 6：识别而非回忆（Recognition Rather Than Recall）
**定义：** 将对象、行动和选项可视化，最小化用户的记忆负担。

- 用户是否需要记住之前页面的信息才能完成当前任务？
- 历史记录、最近操作是否方便查看？
- 选项是否可见，而非要求用户从记忆中提取？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 7：灵活性与使用效率（Flexibility and Efficiency of Use）
**定义：** 加速器——新手用户看不到——可以加快专家用户的操作速度。

- 是否支持快捷操作供高频用户使用？
- 是否允许用户自定义常用功能或流程？
- 新手和专家是否有不同的操作路径？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 8：美学与极简设计（Aesthetic and Minimalist Design）
**定义：** 界面不应包含不相关或很少需要的信息。

- 每个页面的信息是否都与用户当前任务相关？
- 视觉层次是否清晰（主要信息突出，次要信息弱化）？
- 是否存在信息过载或视觉噪音？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 9：帮助用户识别、诊断和恢复错误（Help Users Recognize, Diagnose, and Recover from Errors）
**定义：** 错误信息应用平实语言表达，精确指出问题，并建设性地建议解决方案。

- 错误信息是否用人话解释了问题？（而不是"Error Code 500"）
- 是否告诉用户如何解决问题？
- 错误发生时用户的已有输入是否被保留？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 原则 10：帮助与文档（Help and Documentation）
**定义：** 虽然最好不需要文档就能使用，但可能需要提供帮助。

- 是否有上下文相关的帮助信息（Contextual Help）？
- 帮助文档是否易于搜索和理解？
- 首次使用是否有引导（Onboarding）？
- **严重程度：** [0-4]
- **具体问题描述和改进建议**

## 综合评估报告

### 问题统计
| 严重程度 | 问题数量 | 占比 |
|---------|---------|-----|
| 4-灾难性 | | |
| 3-主要 | | |
| 2-次要 | | |
| 1-装饰性 | | |
| 0-无问题 | | |

### 可用性评分：[总分/100]
### Top 5 最严重的可用性问题
### 优先修复建议（按 ROI 排序）
### 与行业标杆的对比分析

请确保每个评估都引用具体的界面元素和交互细节，而不是泛泛的结论。

请你作为一位拥有丰富经验的高级产品经理，帮我生成以下产品/功能的完整产品需求文档（PRD）。

【产品/功能描述】：[在这里描述要设计的产品或功能，例如：为内容创作者设计的 AI 写作助手功能]
【目标用户】：[描述目标用户群体]
【业务背景】：[简要说明为什么要做这个功能]

请按照以下结构生成完整的 PRD：

## 一、文档信息

| 字段 | 内容 |
|-----|-----|
| 文档标题 | |
| 版本号 | v1.0 |
| 作者 | |
| 创建日期 | |
| 状态 | 草稿 |
| 评审人 | |

## 二、产品概述

### 2.1 精益画布（Lean Canvas）

| 模块 | 内容 |
|-----|-----|
| **问题**（Top 3 问题） | |
| **客户细分** | |
| **独特价值主张** | |
| **解决方案** | |
| **渠道** | |
| **收入来源** | |
| **成本结构** | |
| **关键指标** | |
| **竞争壁垒** | |

### 2.2 产品目标与成功指标

**产品目标：**
- 主要目标（Primary Goal）
- 次要目标（Secondary Goals）

**成功指标（OKR 格式）：**
- O：[目标]
  - KR1：[关键结果 + 量化指标]
  - KR2：[关键结果 + 量化指标]
  - KR3：[关键结果 + 量化指标]

### 2.3 用户画像

针对每类目标用户，描述：
- 用户类型名称
- 核心场景
- 使用频率
- 核心需求
- 关键痛点

## 三、功能需求

### 3.1 用户故事地图（User Story Map）

**史诗故事（Epic）1：[名称]**

| 用户故事 | 优先级 | 验收标准 | INVEST 检查 |
|---------|--------|---------|------------|
| 作为[角色]，我想要[功能]，以便[价值] | P0/P1/P2 | Given...When...Then... | ✓/✗ |

**史诗故事（Epic）2：[名称]**
（同上结构）

### 3.2 功能清单与优先级

使用 MoSCoW 优先级：
- **Must Have（P0）**：不做则产品无法发布
- **Should Have（P1）**：重要但非发布必需
- **Could Have（P2）**：锦上添花
- **Won't Have（本期不做）**：明确排除

### 3.3 详细功能规格

每个 P0 功能需包含：
- **功能描述**
- **用户流程**（步骤 1 → 步骤 2 → ...）
- **输入和输出**
- **业务规则和逻辑**
- **异常情况处理**
- **边界条件**

## 四、非功能需求

### 4.1 性能需求
- 页面加载时间
- 并发用户数
- 响应时间要求

### 4.2 安全需求
- 数据安全等级
- 隐私合规要求（GDPR、个保法等）

### 4.3 兼容性需求
- 支持的设备和操作系统
- 浏览器兼容性
- 最低硬件要求

## 五、交互设计要求

### 5.1 核心页面描述
每个核心页面包含：
- 页面目的
- 信息架构（页面包含哪些模块）
- 关键交互行为
- 状态变化（空状态、加载态、错误态、成功态）

### 5.2 导航结构
- 一级导航
- 页面间跳转关系

## 六、数据需求

### 6.1 需要收集的数据
### 6.2 数据埋点方案
### 6.3 数据分析看板需求

## 七、发布计划

### 7.1 版本规划
- v1.0 包含的功能（MVP）
- v1.1 追加的功能
- v2.0 远期规划

### 7.2 里程碑
| 阶段 | 时间 | 交付物 |
|-----|-----|--------|
| 需求评审 | | |
| 设计完成 | | |
| 开发完成 | | |
| 测试完成 | | |
| 灰度发布 | | |
| 全量发布 | | |

## 八、风险评估

| 风险 | 概率 | 影响 | 缓解措施 |
|-----|-----|-----|---------|
| | 高/中/低 | 高/中/低 | |

## 九、附录

### 9.1 术语表
### 9.2 参考文档
### 9.3 变更记录

请确保每个用户故事都符合 INVEST 原则，每个功能都有明确的验收标准，整个文档可以直接交付给研发团队使用。

请你作为一位精通 HCI（人机交互）理论的交互设计专家，用经典交互设计定律来分析和优化以下界面/功能的交互设计。

【待分析的界面/功能】：[在这里描述需要优化的界面或交互流程，例如：电商 App 的商品筛选和排序功能]

请从以下交互设计定律和原则的角度进行系统分析：

## 一、Fitts 定律分析（目标获取效率）

**定律表述：** T = a + b × log₂(2D/W)，其中 T 是操作时间，D 是距离，W 是目标宽度。

### 分析维度
- 高频操作按钮是否足够大？是否在易于到达的位置？
- 手机端：拇指热区（Thumb Zone）分析——核心操作是否在单手可达范围内？
- 相关联的操作按钮之间的距离是否合理？
- 是否有"无限宽度"的边缘效应（如屏幕边缘菜单）可以利用？
- 鼠标/手指从上一个操作到下一个操作的移动路径是否流畅？

### 优化建议
- [具体的按钮大小、位置调整建议，附数据支撑]

## 二、Hick 定律分析（选择效率）

**定律表述：** T = a + b × log₂(n+1)，其中 n 是可选项数量。

### 分析维度
- 用户在关键决策点面临多少选项？
- 是否存在"选择过载"（Choice Overload）的界面？
- 分类和层级结构是否有效减少了每次的选择数量？
- 推荐/默认选项是否帮助用户减少了决策成本？
- 渐进式披露（Progressive Disclosure）是否被正确使用？

### 优化建议
- [具体的信息分层、默认值设计建议]

## 三、格式塔原则分析（视觉组织）

### 接近性（Proximity）
- 相关元素是否靠近放置，不相关元素是否有足够间距？
- 分组是否符合用户的心理模型？

### 相似性（Similarity）
- 功能相同的元素是否有一致的视觉样式？
- 不同类型的信息是否有视觉区分？

### 连续性（Continuity）
- 用户的视线流是否被引导到正确的阅读路径？
- 视觉引导线（如列表、时间线）是否清晰？

### 闭合性（Closure）
- 卡片、面板等容器是否清晰地"包围"了相关内容？
- 留白是否被有效利用来创造视觉分组？

### 图形-背景关系（Figure-Ground）
- 前景元素（如弹窗、浮层）是否清晰地从背景中分离？
- 模态对话框的遮罩层是否有效区分了层级？

## 四、Miller 定律分析（信息组块）

### 分析维度
- 信息是否被有效组块（Chunking）为 5-9 个组？
- 导航菜单的一级选项是否控制在 7±2 个以内？
- 长列表是否有分类、分页或渐进加载？
- 复杂表单是否分步骤呈现？

### 优化建议
- [具体的信息组织和分块建议]

## 五、Doherty 阈值分析（响应速度）

### 分析维度
- 各操作的响应时间是否在 400ms 以内？
- 超过 400ms 的操作是否有过渡动画或加载指示？
- 骨架屏（Skeleton Screen）或预加载策略是否被合理使用？
- 动画时长是否在 100-500ms 的最佳范围内？

## 六、其他交互原则

### 渐进式披露（Progressive Disclosure）
- 是否先展示核心信息，将高级选项折叠？

### 防错设计（Error Prevention）
- 高风险操作是否有二次确认？
- 输入框是否有实时校验？

### 直接操作（Direct Manipulation）
- 用户是否可以直接操作对象（拖拽、缩放等）而非通过菜单命令？

## 七、综合交互设计改进方案

### 交互效率评分：[当前分数/100]
### Top 5 最关键的交互问题
### 交互优化路线图
  - 第一阶段（1 周内）：快速修复
  - 第二阶段（1 个月内）：结构优化
  - 第三阶段（3 个月内）：创新交互

请用具体的数据和定律公式来支持你的分析结论，而不是泛泛的"按钮应该更大"之类的建议。

请你作为一位精通 Eric Ries 精益创业方法论的产品战略顾问，帮我设计以下产品idea的 MVP 方案。

【产品创意描述】：[在这里描述你的产品想法，例如：一个帮助自由职业者自动管理发票和税务的 SaaS 工具]
【目标用户】：[描述目标用户]
【初步假设】：[你认为用户会为之付费/使用的核心原因是什么？]

请按照精益创业的 Build-Measure-Learn 循环进行完整的 MVP 设计：

## 第一步：假设梳理（Hypothesis）

### 核心假设清单
按照重要性和不确定性排列以下假设：

**价值假设（Value Hypothesis）：**
- 用户确实有 [某个问题] 吗？（问题假设）
- 用户愿意为 [某个解决方案] 付费/使用吗？（解决方案假设）
- 这个产品能显著改善用户的 [某个指标] 吗？（效果假设）

**增长假设（Growth Hypothesis）：**
- 用户会主动向他人推荐吗？
- 获取一个新用户的成本是否低于该用户的终身价值？
- 市场规模是否足够支撑一个可持续的业务？

### 风险最高的假设
- 哪个假设如果被证伪，整个产品方向都需要调整？
- 这个假设就是 MVP 首先要验证的目标

## 第二步：MVP 类型选择

### 适合的 MVP 类型分析
根据产品特性和假设类型，分析以下 MVP 类型哪个最适合：

1. **登陆页面 MVP（Landing Page）**
   - 适合验证：用户是否对这个概念感兴趣
   - 实现成本：极低（1-2 天）
   - 局限：只验证兴趣，不验证使用行为

2. **视频 MVP（Explainer Video）**
   - 适合验证：用户是否理解并被吸引
   - 经典案例：Dropbox 在产品开发前用一个演示视频获得了 75,000 个注册

3. **绿野仙踪 MVP（Wizard of Oz）**
   - 适合验证：用户是否真的会使用这个功能
   - 前台看起来是自动的，后台其实是人工操作

4. **礼宾式 MVP（Concierge）**
   - 适合验证：用户是否愿意为这个服务付费
   - 用人工服务代替自动化系统

5. **碎片拼接 MVP（Piecemeal）**
   - 适合验证：流程是否走得通
   - 用现有工具组合来模拟产品功能

6. **单功能 MVP（Single Feature）**
   - 适合验证：核心功能的产品市场匹配
   - 只做一个最核心的功能，做到极致

### 推荐的 MVP 方案
- 推荐类型及理由
- 需要验证的核心假设
- 预计开发时间和成本
- MVP 不应包含什么（明确排除范围）

## 第三步：构建（Build）

### MVP 功能清单
仅包含验证核心假设所需的最小功能集：

| 功能 | 是否必要 | 理由 |
|-----|---------|-----|
| | ✓ 必要 / ✗ 非必要 | |

### 技术方案建议
- 推荐的技术栈（优先低代码/无代码方案）
- 建议的开发周期（以天/周为单位，不超过 4 周）
- 可以使用哪些现成工具/服务来加速？

### MVP 质量标准
- 不需要完美，但需要"可用"——明确哪些 bug 可以容忍，哪些不行
- 视觉设计最低标准是什么？

## 第四步：测量（Measure）

### 核心指标（One Metric That Matters）
- 这个 MVP 阶段，最关键的一个指标是什么？
- 为什么选择这个指标？

### 指标体系
使用海盗指标（AARRR）框架：
- **获取（Acquisition）**：用户如何发现我们？衡量指标？
- **激活（Activation）**：用户第一次体验到"Aha Moment"是什么？衡量指标？
- **留存（Retention）**：用户会回来继续使用吗？衡量指标？
- **推荐（Referral）**：用户会推荐给别人吗？衡量指标？
- **收入（Revenue）**：用户愿意付费吗？衡量指标？

### 数据收集方案
- 需要埋哪些数据点？
- 用什么工具收集和分析？
- 样本量要求：需要多少用户数据才能得出有统计意义的结论？

## 第五步：学习（Learn）

### 决策框架
根据测量结果，制定三种决策路径：

**坚持（Persevere）：** 如果指标达到 [具体数值]，说明假设被验证，接下来应该：
- [下一步行动]

**转型（Pivot）：** 如果指标低于 [具体数值]，说明假设被证伪，应考虑以下转型方向：
- 用户群转型（Zoom-in / Zoom-out / Customer Segment Pivot）
- 需求转型（Problem Pivot）
- 方案转型（Solution Pivot）
- 渠道转型（Channel Pivot）
- 商业模式转型（Revenue Model Pivot）

**放弃（Kill）：** 在什么条件下应该停止这个项目？

### 从 MVP 到产品
如果验证成功，MVP 如何演进为完整产品？
- v1.0 路线图
- 需要补充的功能
- 需要改善的体验
- 需要构建的技术基础

请确保 MVP 方案真正做到"最小"——如果任何一个功能被移除后仍能验证核心假设，那它就不应该在 MVP 中。

请你作为一位精通 Peter Morville 信息架构理论的 IA 架构师，帮我设计以下产品/网站的信息架构。

【产品/网站描述】：[在这里描述产品，例如：一个面向中小企业的项目管理 SaaS 平台]
【核心内容类型】：[列出产品包含的主要内容类型，例如：项目、任务、文档、日历、团队成员、报告]
【目标用户】：[描述目标用户群体及其使用场景]

请按照信息架构的四大系统进行完整设计：

## 一、组织系统（Organization System）

### 1.1 组织方案分析
分析以下组织方案哪种最适合：

**精确型组织方案：**
- 字母顺序（适合已知目标的查找）
- 时间顺序（适合有时间属性的内容）
- 地理位置（适合与位置相关的内容）

**模糊型组织方案：**
- 主题/话题分类（最常见但最难设计）
- 任务导向分类（按用户要完成的任务组织）
- 受众分类（按不同用户群体组织）
- 隐喻分类（用熟悉的概念类比组织）

### 1.2 推荐的组织结构
- 顶层结构类型：层级（Hierarchy）/ 矩阵（Matrix）/ 标签（Faceted）
- 一级分类（不超过 7 个）及其定义
- 二级分类及其与一级分类的关系
- 跨分类链接和快捷路径

### 1.3 内容盘点（Content Inventory）
| 内容类型 | 数量级 | 更新频率 | 主要消费场景 | 分类方式 |
|---------|--------|---------|------------|---------|
| | | | | |

## 二、标签系统（Labeling System）

### 2.1 导航标签
每个导航项的标签需满足：
- 使用用户语言而非业务术语
- 互斥（不重叠）且完整（不遗漏）
- 长度适中（2-4 个字为佳）
- 与用户心理模型匹配

| 功能/内容 | 推荐标签 | 备选标签 | 排除标签（及原因） |
|----------|---------|---------|-----------------|
| | | | |

### 2.2 页面标题和描述
核心页面的标题和描述建议，确保 SEO 友好且用户可理解。

### 2.3 图标与标签的配合
哪些标签需要图标辅助？图标风格建议。

## 三、导航系统（Navigation System）

### 3.1 全局导航
- 导航类型：顶部导航 / 侧边导航 / 底部标签（移动端）
- 导航项及其层级关系
- 面包屑导航设计

### 3.2 局部导航
- 页面内的子导航设计
- 上下文导航（相关内容推荐）
- 筛选和排序机制

### 3.3 辅助导航
- 网站地图（Sitemap）
- 搜索功能设计
- 常用快捷入口
- "你可能还需要"智能推荐

### 3.4 导航路径分析
用户最常见的 3-5 个任务，每个任务的最优导航路径：
- 任务：[描述]
- 最优路径：首页 → [步骤 1] → [步骤 2] → 目标
- 当前路径深度：[N] 步
- 是否有缩短路径的可能？

## 四、搜索系统（Search System）

### 4.1 搜索策略
- 什么情况下用户会选择搜索而非导航浏览？
- 搜索框的位置和视觉突出度
- 搜索范围：全局搜索 vs 局部搜索

### 4.2 搜索辅助
- 搜索建议（Auto-suggest）策略
- 同义词和容错处理
- 热门搜索展示
- 搜索结果为空时的处理方案

### 4.3 搜索结果展示
- 结果排序逻辑（相关性 / 时间 / 热度）
- 结果分组和筛选
- 结果摘要信息

## 五、卡片分类验证方案

### 5.1 推荐的验证方法
- **开放式卡片分类**：让用户自行创建分类名，发现用户的心理模型
- **封闭式卡片分类**：使用已设计的分类，验证分类方案的合理性
- **树测试（Tree Testing）**：验证导航结构的可发现性

### 5.2 执行建议
- 需要多少参与者？
- 卡片内容清单
- 分析方法（相似度矩阵、树状图）
- 成功标准

## 六、信息架构蓝图

### 完整的站点地图（Sitemap）
以树状结构呈现完整的信息架构，标注每个节点的：
- 页面名称
- 页面类型（列表页 / 详情页 / 表单页 / 仪表盘等）
- 核心内容和功能
- 与其他页面的关系

请确保信息架构设计兼顾可发现性（用户能找到）和可理解性（用户能理解），并提供验证方案。

请你作为一位精通 WCAG 标准和通用设计原则的无障碍设计专家，对以下产品/功能进行系统性的无障碍审查。

【待审查产品/功能】：[在这里描述产品或功能，例如：在线教育平台的课程播放和学习页面]
【目标合规级别】：[WCAG 2.1 AA / WCAG 2.1 AAA / 其他标准]

请按照 WCAG 的 POUR 四大原则进行全面审查：

## 一、可感知性（Perceivable）

用户必须能够感知到信息和界面组件。

### 1.1 文本替代（Text Alternatives）- WCAG 1.1
- 所有非文本内容（图片、图标、视频）是否都有替代文本（alt text）？
- 装饰性图片是否使用了空 alt 属性（alt=""）以被辅助技术忽略？
- 复杂信息图（图表、信息图）是否提供了详细的文本描述？
- 验证码是否提供了音频替代？

### 1.2 时基媒体（Time-based Media）- WCAG 1.2
- 视频是否提供了字幕（Captions）？
- 音频内容是否提供了文字转录（Transcript）？
- 直播内容是否有实时字幕？
- 视频是否需要音频描述（Audio Description）？

### 1.3 适应性（Adaptable）- WCAG 1.3
- 信息结构是否可以通过编程确定？（语义化 HTML）
- 内容的阅读顺序在移除 CSS 后是否仍然有意义？
- 表单字段是否有正确关联的标签？
- 表格是否有表头和标题？

### 1.4 可辨识性（Distinguishable）- WCAG 1.4
- 文本与背景的对比度是否满足要求？（AA 级：4.5:1 / AAA 级：7:1）
- 大号文本对比度是否满足 3:1？
- 颜色是否是传达信息的唯一方式？（色盲用户无法区分）
- 文本大小是否可以放大到 200% 而不丢失内容或功能？
- 在移动端是否支持横竖屏切换？

## 二、可操作性（Operable）

用户必须能够操作界面组件和导航。

### 2.1 键盘可访问（Keyboard Accessible）- WCAG 2.1
- 所有功能是否都可以仅通过键盘完成？
- 是否存在键盘陷阱（Tab 进去出不来）？
- 快捷键是否不与浏览器/辅助技术冲突？
- 焦点顺序是否符合逻辑？

### 2.2 充足时间（Enough Time）- WCAG 2.2
- 有时间限制的操作是否允许用户延长、调整或关闭时限？
- 自动刷新/滚动的内容是否可以暂停？
- 会话超时前是否有警告并允许延期？

### 2.3 癫痫和身体反应（Seizures and Physical Reactions）- WCAG 2.3
- 是否存在每秒闪烁超过 3 次的内容？（可能引发光敏性癫痫）
- 动画是否可以被用户关闭？（prefers-reduced-motion）

### 2.4 可导航（Navigable）- WCAG 2.4
- 是否提供了"跳到主要内容"（Skip to Main Content）的链接？
- 页面标题是否准确描述了页面内容？
- 链接文字是否有意义？（而非"点击这里"）
- 焦点指示器（Focus Indicator）是否清晰可见？
- 面包屑导航或其他定位方式是否可用？

### 2.5 输入方式（Input Modalities）- WCAG 2.5
- 触摸目标是否足够大？（WCAG 2.2 要求最小 24×24px）
- 多点触控或路径操作是否有单点替代？
- 是否支持语音输入？

## 三、可理解性（Understandable）

用户必须能够理解信息和界面操作。

### 3.1 可读性（Readable）- WCAG 3.1
- 页面语言是否在 HTML 中正确声明？
- 非主要语言的内容是否标注了语言？
- 是否使用了简洁清晰的语言？
- 专业术语是否提供了解释？

### 3.2 可预测性（Predictable）- WCAG 3.2
- 组件获得焦点时是否会自动触发意外的上下文变化？
- 用户输入时是否会自动提交而无警告？
- 导航和操作模式在不同页面间是否一致？

### 3.3 输入辅助（Input Assistance）- WCAG 3.3
- 错误是否被自动检测并用文字描述？
- 表单标签和说明是否充分？
- 错误修复建议是否具体？
- 重要操作是否可以撤销或有确认步骤？

## 四、稳健性（Robust）

内容必须稳健到可以被各种用户代理（包括辅助技术）可靠解释。

### 4.1 兼容性（Compatible）- WCAG 4.1
- HTML 是否语义化正确，没有重大验证错误？
- ARIA 角色和属性是否正确使用？
- 自定义组件（如自定义下拉框）是否可被屏幕阅读器正确识别？
- 动态内容更新是否通过 ARIA Live Region 通知辅助技术？

## 五、综合无障碍评估报告

### 合规性评分

| POUR 原则 | 合规状态 | 关键问题数 |
|-----------|---------|----------|
| 可感知性 | 通过/部分通过/未通过 | |
| 可操作性 | 通过/部分通过/未通过 | |
| 可理解性 | 通过/部分通过/未通过 | |
| 稳健性 | 通过/部分通过/未通过 | |

### 问题优先级排序
| 问题 | WCAG 条目 | 影响范围 | 严重程度 | 修复难度 | 优先级 |
|-----|---------|---------|---------|---------|-------|
| | | | | | |

### 修复路线图
- **立即修复**（1 周内）：影响最大用户群的关键问题
- **短期修复**（1 个月内）：达到 AA 级合规的必要改进
- **中期改善**（3 个月内）：提升到 AAA 级或行业领先
- **持续改进**：建立无障碍设计 Checklist 融入开发流程

### 测试工具建议
- 自动化测试工具（axe-core、WAVE、Lighthouse）
- 手动测试 Checklist
- 辅助技术测试（屏幕阅读器 NVDA/VoiceOver 测试方案）
- 真实用户测试招募建议

请确保每个问题都引用具体的 WCAG 条目编号，便于开发团队查阅标准文档进行修复。