产品设计过程(产品设计的工作流程规范)

这个过程只适用于软件产品开发。尽情享受~

在行业内，产品开发线包含的岗位有产品经理、项目经理、用户研究、交互设计师、视觉设计师、前台工程师、开发vs服务、测试等角色。有的公司产品经理也做项目经理，或者交互设计师也做用户调研，甚至交互和视觉设计都是由产品设计师共同承担。这也是行业发展的需要和趋势，每个角色的能力要求会越来越高，不同的企业，不同的。产品是整个团队共同努力的产物。除了团队成员的个人能力，一个好产品的诞生还需要构建一套标准化的协同工作流程。

以下是产品经理、交互设计师、视觉设计师、开发和测试的团队案例的详细讲解。

怎么建？

1.定义产品设计的五个阶段。

所有软件都会经历这五个阶段，即:

项目启动阶段:在正式的项目启动会议后，项目正式开始。

参与者:项目经理、产品经理、设计师、开发和测试项目团队的主要成员参加。

需求阶段:主要梳理用户需求、业务需求、客户需求。

参与者:产品经理、用户研究、交互设计师

设计阶段:主要包括交互和视觉方案的详细设计。

参与者:交互设计师，视觉设计师

开发阶段:实现产品方案。

参与者:开发vs服务

验证阶段:检查产品质量，设计师根据实施情况进行检查。

参与者:测试人员、产品经理和设计师。

项目组成员必须充分了解每个阶段的目标以及每个阶段的主要职责和目标。

2.每个阶段的主要目标和责任

(1)项目立项阶段

产品经理:输出产品简要描述，主要描述本项目的主要目标和任务；

发起项目立项会议，制定会议议题，讨论项目的大致时间计划要求，需要多方确认(包括:资源分配、技术可行性评估等。)项目立项前；

输出:项目时间表

交互设计师:进行目标用户分析(也就是你为什么要这么做？这种需求针对的用户群体是什么？用户特征是什么？)，具体方法有目标用户定位、桌面研究、人物角色、竞争分析、真实镜像调查等。，发现和了解用户需求；

输出:产品总结文件

视觉设计师:这个阶段的需求不完全清晰，可以根据产品类型和方向来分析设计趋势；

输出:设计趋势分析文件

(2)需求阶段

需求阶段包括需求发现、需求分析和需求管理。

产品经理:

洞察行业，了解用户，明确业务目标；

收集所有来源的需求，包括:用户反馈、研究和分析需求、设计需求、市场需求、领导需求等。，并实行分类管理；

进行需求讨论，邀请专家、研究、交互设计师进行讨论，使用KANO模型、优先级排序、二维感知图等工具进行分析；

将确定的需求组织成需求列表，输出给交互设计师和视觉设计师；

撰写产品PRD文件，组织多方评审会议；

方案通过后，输出PRD文档给交互、愿景、开发；

组织交互设计师评估交互设计时间表；

关闭需求闸门，控制该版本的需求数量，避免因不断更改或添加需求而失去对项目的控制。

输出:具体需求清单和产品需求文件。

互动设计师:

挖掘用户需求，发现用户痛点(你遇到什么场景？使用过程中的痛点在哪里？当前主导需求和潜在需求？)，使用流程图、用户行程图、生态系统图、亲和度图等工具，这是研究和交互的核心部分，所有的设计思路都需要建立在目标用户和使用场景的基础上，没有用户就谈不上设计；

将痛点整理成需求清单，输出给产品经理汇总；

产品经理输出PRD工艺文件后，可以根据需求进行初步的概念设计方案。概念方案的输出形式可以是草图、DEMO、动态演示、高保真原型，没有具体限制。目标可以是定义表的设计思想。一般迭代版本控制在3天左右，大型项目控制在7天左右。

内部审核，确定参会人员范围和会议目标，需要审核文件应提前一天发出，以便审核人员提前了解具体方案，发现问题，可以避免会议过程中的无序讨论和争执，提高会议效率；会后做会议纪要，邮寄相关人员，根据评审结果优化方案(后续所有相关评审会议都需要这么做)；

快速验证和设置测试用例。最好能找到真实的用户对象进行测试。如果资源和时间不允许，可以找身边的同事、亲戚、朋友进行定性研究，3-5个即可。最小成本试错，设计出最佳方案。如果你想偷懒，跳过这一步，最终的方案很可能偏离了用户的需求，那么就会以十倍甚至更多的成本进行修改和补偿，甚至错过了一个很好的市场机会。所有的设计都要放到实际场景中与用户进行对话才能得到验证，所以在产品孵化过程中一定要坚持与用户的对话；

设计方案，合理组织方案内容，把目标理解、需求分析、概念方案(连同视觉方案)的整体设计思路梳理清楚，注重个性表达能力，这也是设计师把握好每一个这样的机会的必要一课。同样，提前发起会议以确定与会人员范围和会议目标，应提前一天预订会议，并发布计划，以便提前收集关键审查人员对计划的意见，并预计了解不同人员的想法，提前发现问题，并预计优化的计划和提案。

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

视觉设计师:

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

配合交互设计设计概念方案，快速视觉呈现理想；

衍生视觉风格。

输出:概念设计方案和视觉风格衍生文档。

(3)设计阶段

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

产品经理:

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

参加设计评审会议；

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

输出:详细的项目时间关键节点文件

互动设计师:

进行交互详细设计，包括信息架构图、页面流程图、任务流程图、总体设计方案、交互状态注释等。注意交互文档的标准化格式、文档命名、文案真实性、避免可视化和使用截图、文档命名方法、建立标准控制。最好制定交互文档写作规范，并严格执行。这将有助于设计师、开发人员和测试人员阅读，减少沟通成本，更好地体现个人的专业性。

组织内部审核，包括自检和设计组审核(小范围内)。设计师自身需要养成严谨细致的态度，在发文前一定要养成自查的习惯；

审核范围再次扩大，审核人包括总监、产品、交互。会后必须整理会议纪要，根据评审结果优化方案。

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

在最后一轮方案需求评审中，将再次召集项目组各环节的关键成员对最终方案进行评审。过程中可能会有一些小的调整，但方案方向的确定性基本可以保证，后续开发阶段不会有大的需求变化。

宣讲，要召集项目组所有参与设计、开发、测试的人员宣讲方案，过程中不详细讨论方案；

输出:详细的交互设计方案

在设计过程中，我们已经通过了多伦评审，有利于后续需求方案的稳定，降低整体开发成本。进入开发阶段后，产品经理可以花时间去规划和思考下一个版本，具体的实现可以由设计师、开发、测试来进行。

视觉设计:

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

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

组织评审:坚持自检、小组范围评审、产品范围评审等评审原则(在上面的交互设计环节有详细描述)，避免后续不断调整风格的问题，前期尽量预留关键页面的设计推演时间；

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

输出:详细的设计方案和设计资源。

开发者:

参加评审会议，熟悉产品逻辑和流程，设计底层框架；

提出技术支持需求；

在技术会议上评估时间要求；

测试仪:

通过参加评审会议，熟悉产品逻辑和流程；

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

开发测试案例和具体的实施计划；

(4)发展阶段

产品经理:

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

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

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

互动设计师:

整理交互设计规范，包括基本原则、常用交互规范、基本控件交互规范、扩展控件交互规范、信息提示规范、导航规范、典型页面视图规范、窗口规范、文本规范等。，作为后续设计指导；

跟踪还原程度，整理相关bug，通过固定工具反馈给测试人员；

制定反馈和改进计划。

视觉设计师:

组织视觉设计规范，包括:标准颜色、标准文本组合、基本布局、图标样式、基本控件、通用页面结构等。，作为后续设计指导；

跟踪还原程度，整理相关bug，通过固定工具反馈给测试人员；

制定反馈和改进计划。

开发者:

按计划进行具体开发；

测试仪:

制作详细的测试用例；

根据开发结果，进行了初步试验。

(5)验证阶段

产品经理:

策划上线准备，包括:运营推广、产品上线准备(指南页面、应用商店截图、用户反馈渠道部署等。);

收集测试反馈产品问题；

跟踪遗留问题；

准备上线后获取用户反馈和数据分析方法工具。

和交互式视觉设计:

跟踪遗留问题；

跟踪还原程度，整理相关bug，通过固定工具反馈给测试人员；

开发者:

根据测试反馈修复Bug。

测试仪:

进行第一轮和第二轮测试；

合理安排试题并及时反馈给产品、设计和开发；

组织最终测试报告。

即以上所述的整个产品设计过程，简要阐述了五个阶段不同角色的不同职责，规范了投入和产出，有效控制了团队的节奏，合理推动项目塑造产品。在实际工作中，不会完全按照流程来执行，而是根据实际的团队匹配和项目的大小来部署。特别是巨无霸项目，一定要分成几个模块，每个模块都遵循这个流程，类似于敏捷开发中提到的sprint的概念。

相对敏捷开发:

上图是敏捷宣言遵循的原则。可以看出，敏捷强调去文档化、去流程化，通过高效的沟通来传递信息，对团队之间的耦合性要求更高，更适合创业型团队。一般企业中的都不推荐完全去文档化的流程，我们需要考虑版本迭代、团队扩充、人员变动。同时，文档可以节省一些标准问题中的沟通成本，降低错误率。但敏捷中的“灵敏”可以应用到上述流程中，各个模块可以更精细的拆解，加快流程。在同一个流程中，使用站会(整理当天要完成和计划的任务)、倦怠图(一个项目管理工具)和故事板(四栏:待开发、开发中、测试中、测试中、待发布)，将每一个额外的任务需求放入故事板。

适用范围:

如果你的团队没有一个标准的流程，你可以在此基础上实施，然后根据自己的特点进行改进。

团队成员超过10人或多条产品线的企业，可以以此作为流程规范，让团队对流程有深入的理解，并据此对号入座；

转型中的企业还没有达到互联网产品团队的成熟度和效率，每次版本迭代都可以基于这个过程稳定下来；

如果敏捷方法没有实施，我们可以将敏捷的精髓融入到这个过程中，尝试一下。

最后，我希望你能从官员那里学到一些东西。欢迎交流学习！

[结束]