需求的定义
需求是用户或业务方对产品提出的具体期望或要求，用于解决特定问题或满足特定目标。它是产品设计的核心依据，贯穿产品生命周期的各个环节。需求是用户的预期和现状存在差异。
需求的分类
1.需求可以是用户提出的问题 2.用户明确要到达的目的（整体销售量提升）3.用户提供的明确方案
功能性需求
描述产品必须具备的具体功能或能力，例如"用户可以通过手机号注册账号"。
非功能性需求
涉及性能、安全性、兼容性等非直接功能的要求，例如"系统响应时间需在2秒内"。
业务需求
反映企业或组织的宏观目标，例如"提升用户留存率至30%"。
用户需求
从用户视角出发的具体诉求，例如"希望一键导出所有历史订单"。
需求的典型来源
主要分为两类：内部来源------管理层、其他部门员工、同事（Boss）
外部来源------用户、市场、竞品
内部需求较容易获取，其中老板的需求倾向于命令。外部需求需要进行获取数据调研等
- 用户调研与反馈
- 市场竞品分析
- 内部战略规划
- 技术发展趋势
用户访谈流程：
访谈可以进行 直接、间接访谈------>基于目的去设计问题------>筛选活跃用户
访谈问题：
访谈模版：
访问问题记录：痛点------哪里不爽了
可以给用户些具体的案例。
错误案例：
1.我们改进了这个功能，您觉得怎么样？ 引导性，用户不好意思说不好
2.您对投资理财有啥看法 问题太开放
3.您觉得微信里面的三个小点按钮用的怎么样 问题过细，用户难以回想
题目：
明确8.0.0版本的新功能有哪些（表情、小程序）
1.您目前使用wx，觉得表情包够用吗？
2.您觉得UI页面设计足够美观吗？
3.购物使用微信支付时，是否便利
解决方案：你希望怎么解决？你目前是怎么解决的？
需求文档的核心要素
- 背景说明：需求产生的上下文。
- 详细描述：功能逻辑、交互流程、数据规则等。
- 验收标准：明确达成条件的量化指标。
理解原始需求（防扯皮）
原始需求未经过分析，缺乏额外解读。需要明确目标、范围和约束条件，确保后续工作方向正确。
验证需求完整性
检查需求是否覆盖所有必要场景，是否存在遗漏或矛盾。确认技术可行性和资源匹配度。
产品经理交互说明撰写规范：
1.原型先画默认状态，然后再写交互后的效果，优先写静态。
2.产品经理在设计交互逻辑时，避免让用户陷入更深层级，一般要求单流程最多跳转三次，临时视图不占次数。
3.设计强制执行页面，一般不提供其他跳转出口，让用户保持高度专注，形成逻辑闭环，减少错误发生。
4.弱执行流程（浏览查看）可提供跳转出口（分享），增加流量。完成阶段提供快速返回，让用户快速返回。