内部审核，确定参会人员范围、会议目标，应提前1天发出需求评审文档，以便评审人员提前了解具体方案，发现问题，可以避免会议过程中无序讨论争执，提高会议效率；并在会议后做好会议记录，邮件方式发生相关人员，针对评审结果对方案进行优化（后续的相关评审会议都需要这样做）；

快速验证，设定好测试案例，最好找真实用户对象进行测试，若资源、时间不允许的情况，可以找身边同事、亲人、朋友进行定性研究，3-5个即可。最小成本试错，设计最优方案，如果你想偷懒跳过该步骤，最后的方案很可能是偏离用户需求，那么将以十倍甚至更多的代价进行修改弥补，甚至错过了好的市场时机，所有的设计必须放入实际的场景中于用户对话才能得以验证，所以在产品孕育过程必须坚持与用户的对话；

设计提案，合理组织提案内容，把目标理解、需求分析、概念方案（与视觉方案一起）整个设计思路梳理清晰，另外注重个人的表达能力，这也是设计师必须课，把握好每一次这样的机会。同样提前发起会议，确定参会人员范围、会议目标，应提前1天预定会议上，并发出方案，可以提前收集关键评审人员对方案的意见，可以预期了解各个不同人员的想法，提前发现问题，预想优化方案和提议；

输出物：用户分析报告、分析过程文档、照片记录、语音记录、需求分析结果文档、概念设计方案

视觉设计师：

进行设计趋势分析，并输出分析报告；

配合交互设计进行概念方案设计，快速将ideal进行视觉呈现；

进行视觉风格推导。

输出物：概念设计方案、视觉风格推导文档

（3）设计阶段

从抽象到具象关键的一步。

产品经理：

跟进交互设计方案，确保不偏离初衷；

参与设计评审会议；

在进行方案技术评估会议上，对各交互设计、视觉设计、开发、测试的时间进行梳理和评估，时间必须精确到天，包含了版本提交和上线日期。

输出物：详细项目时间关键节点文档

交互设计师：

进行交互详细设计，包含信息架构图、页面流程图、任务流程图、整体设计方案、交互状态注释等，注意交互文档的标准化格式、文档命名、文案真实性、避免视觉化和使用截图、文件命名方式、建立标准控件，最好制定交互文档书写规范，并严格执行，这样有利于设计、开发、测试人员阅读，降低沟通成本，更能体现个人的专业度；

组织内部审核，包含自检和设计组审核（小范围），设计师本身需要养成严谨细心态度，在发出文档前一定养成自检习惯；

评审范围再次扩大，评审人员包含总监、产品、交互，会议后必须整理会议记录，并根据评审结果优化方案；

召集项目组各环节关键成员进行方案可行性评估，主要包含技术可行性评估、技术范围评估、开发时间评估，并在过程中可能会根据技术的评估会对方案进行评审，会议后必须整理会议记录，并根据评审结果优化方案，还有需确定各环节具体参与人员名单；

最后一轮方案需求评审，再次召集项目组各环节关键成员，对最终方案进行一次评审，在过程可能还会存在细枝末叶的调整，atv，但基本可以保证方案方向的确定性，确保后续开发阶段不做大的需求变动；

宣讲，应该召集项目组所有设计、开发、测试等着实参与人员，针对方案进行宣讲，过程中对方案不做具体讨论；

输出物：详细交互设计方案

在设计过程中经过了大大小小的多伦评审，这样有利于后续需求方案的稳定性，降低整个开发成本，且进入开发阶段后，产品经理可抽出身来进行下一个版本的规划和思考，具体的实施由设计师、开发、测试执行即可。

视觉设计：

关键页面设计，确定基础风格，建立基础规范；

根据交互设计方案，进行具体视觉详细设计；

组织评审：坚持自检、小组范围评审、产品范围评审等评审原则（以上交互设计环节有详细说明），避免后续不断调整风格问题，前期关键页面设计尽可多预留时间进行设计推导；

输出设计资源给予开发或前端工程师，注意模块分组、图标命名、以及不同分辨率的设计和管理；

输出物：详细设计设计方案、设计资源

开发人员：

通过参与评审会议，熟悉了解产品逻辑、流程，设计底层框架；

提出技术支持需求；

技术评估会上评估时间需求；

测试人员：

通过参与评审会议，熟悉了解产品逻辑、流程；

技术评估会上评估测试时间；

制定测试案例和具体执行计划；

（4）开发阶段

产品经理：

在该阶段，产品经理可以进行下一个版本的规划和思考；

开发过程中，合理调配资源，支持各方需求；

还原度跟进，整理相关BUG，通过固定工具反馈给测试人员。

交互设计师：