给设计师的《大型项目承接实战手册》

一、背景

对于一个几十人的中台型设计团队，会承接各种各样的行业和项目；而这样一个行业和项目体量是很大的，如果仅凭一两个设计师是无法Cover的；所以这时候需要一个设计PM来牵一个项目设计小组以应对行业或项目的设计工作。

笔者也是第一次做设计接口人，一开始也是茫然无措，不知道从哪里下手，也害怕在跟进项目过程中遗漏了什么，导致项目不能正常进行；另外这种大的项目会牵扯到很多其它部门的同学，业务方、产品经理、前端、后端、技术同学等等，沟通协作以及对于项目中的管理显得尤为重要；做得好项目组会觉得你很专业，做的不好可能会被其它同学投诉，可以说是压力山大。

笔者最终还是硬着头皮，摸着石头过河，最终保证了项目顺利上线；并且也让设计部门在这个项目中有一定的发声，体现了价值，那么我是怎么做的呢？

二、项目承接的流程

让事情在正确的时间点顺利发生：

作为一个设计PM，首先你需要跳脱出设计本身，或者说除了设计本身你要考虑的更多，要以一个更高的视角来看问题，比如你做了哪些事或者不做哪些事会对项目有怎样的影响。

做好项目承接其实保证一条宗旨即可：让事情在正确的时间点顺利发生。

这句话要划下重点，就是“正确”和“顺利”，如何做好这两个词，其实可以总结为一个流程：

1. 项目梳理

在项目开始之时，都会有个全员的Kick off，这个时候你会了解到项目的大背景，以及接下来要做哪些事。

所以在这个阶段，你要做好项目的梳理工作：

• 了解项目背景，相关人员，以及涉及的需求范围（目的：为了能有针对性的建立项目设计小组，选择和合适的设计师，以及做好安排和分配）；
• 创建相应的项目协作资料库（目的：为了后续设计小组内部以及设计和外部同学的协同过程中方便信息互通和整理）。

协作资料库示例：

2. 规划安排

在了解项目后，需要拉上项目涉及的设计同学进行项目的同步（笔者公司设计组同学相当于是横向的，每个人负责一个模块，因为是中台部门，所以新的项目或者行业承接时相当于是“搭积木”）：

• 拉上相关的同学进行事项同步，并让其与对应的产品经理了解情况；
• 根据整体项目时间，初步制定设计侧的时间节奏；
• 着手准备设计Kick Off资料，并与项目组确定设计Kick Off时间。

这个阶段要值得注意的是需要尽可能早的同步信息给相关同学，并让大家形成感知，进行相关工作安排。

3. 设计Kick Off

项目设计小组成立以及内部相关内容同步完成后，接下来就是对外部的设计宣导，针对本次项目我们设计侧有哪些策略、要做哪些事、安排和节奏是怎样的、有哪些是需要项目组配合的等等。

• 完成设计KO资料；
• 拉上项目组所有成员进行设计KO；
• 记录设计KO时的问题点，后续进行跟进。

设计KO提纲示例：

4. 评估设计工期

完成设计KO后，就要具体开始着手设计的工期评估以保证项目顺利进行：

• 在项目对应子模块PRD评审完成后，及时让各模块设计师同步设计工期；
• 根据各模块的设计工期以及整体项目节奏制定设计整体串联评审时间（因为中台部门的子模块会存在业务流程关系，所以在用户视角需要进行业务逻辑的串联）。

在这个阶段值得注意的是：

• 评估设计工期需要考虑整体节奏；
• 子模块PRD完成时间不一，需要尽快Push相关产品经理完成，如有风险需要及时暴露，如有必要同步给项目组。

设计工期表示例：

5. 设计产出

评估设计工期后，就是实际的设计产出阶段：

• 各模块产出对应的设计稿，并维护到对应的资料库；
• 各模块设计稿需要按照规范维护（需要考虑完整性，以及站在用户视角，在此不做展开）；
• 阶段性小组对焦，及时跟进各域的进度。

这个阶段最值得注意的就是风险的及时同步，因为设计师不仅仅只负责一个项目，如果发生了项目并行等时间问题需要及时暴露并协调解决。

风险&问题跟进表：

6. 设计评审

设计产出后，前面提到了，如果需要各模块进行设计的整体串联，则需要组织大家一起按照顺序进行设计串联评审：

评审前：

• 提前确定好各模块设计评审时长（可使用在线文档进行收集）；
• 制定设计评审时间表；
• 邮件通知全项目组，邮件包含评审时间表以及评审注意事项，另外如有必要可提前预定线上会议，若有会议码则附于邮件中。

评审时间表：

评审时：

• 选择合适的方式，提前准备，线下或者线上会议；
• 评审的各个环节需要在群中进行实时播报，上一个快结束时提前10min通知下一个要评审的相关人员尽快入会或到现场；
• 各模块需尽量严格按照评审时间表执行，若有无法确定的点可以记录下来。

大群播报示例：

评审后：

• 整理各模块评审时的问题点，记录下来形成Action指派到对应的人；
• 邮件将评审结果发与全项目组，内容包含各模块评审是否完成情况，以及各模块的Action，最后同步剩余模块评审时间以及Action解决掉的时间；
• 持续跟踪Action完成情况，做好阶段性同步；将剩余模块的评审完成（同以上流程）。

评审后邮件示例：

串联评审是一件需要协调整个项目组的复杂流程，所以有几项注意：

• 评审前务必提前3天及以上发出邮件同步评审时间，关键人物需要单独确认；
• 评审时注意控制评审节奏，切记不可任由其他人讨论非设计相关内容，如进行需求讨论，如发生需及时制止；
• 评审后需要及时整理评审结果，并在当天发出。

7. 可用性测试

完成设计评审后，接下来为了保证设计的质量，我们需要进行上线前的可用性测试：

测试前：

• 做好可用性测试的规划以及安排；
• 明确测试的背景，目标，内容等；
• 与项目组对焦确定项目核心模块，需要着重测试的；
• 与各模块设计师对焦确定测试任务&场景，以及测试的方式，如需可交互demo需要确定制作时间；
• 针对测试任务以及场景确定测试用户构成和范围；
• 项目组对焦合力进行招募用户，明确具体测试时间与安排；
• 确定测试工作安排，准备测试提纲（整体提纲与各模块设计师自己测试的问题提纲），统一汇总规范。

测试中：

实施测试，跟踪并整理结果，将问题汇总，由各模块设计师跟进解决。

问题列表示例：

测试后：

产出可用性测试报告，并同步项目组。

在可用性测试阶段需要注意的是：

• 测试前注意将节奏和项目组对齐；
• 测试时注意把控测试节奏，以及关键问题记录；
• 测试后整理问题，推动问题解决，以及报告同步项目组。

Ps：可用性测试相关资料请各位自行网上查询。

8. UAT（User Acceptance Test）

项目开发提测后，在上线前，设计需要进行验收，为了保证设计质量这个环节也是至关重要的。

测试前：

各模块设计师与自己的技术、测试对焦，提前准备测试数据和测试环境的可用性。

测试时：

• 每个模块开始UAT时，模块负责人带领大家提前核对好模块用例，根据模块复杂程度明确分工合作；
• UAT验收过程中，先完成模块测试，跑通流程；
• 模块测试完成后，各模块设计师自主进行模块的功能和数据验证；

测试后：

• 测试完成后，该模块的设计师们将问题统一梳理并记录下来；
• 有问题但是不需要二次测试的，明确由哪些模块内部验证直至问题关闭；
• 有问题且需要二次测试的，评估二次产品UAT验收的条件和计划；
• 最后，模块负责人将验收结果邮件同步给项目组，注明：验收情况、验收结论：是否通过、（对未通过验收的模块）下一步计划等。

针对问题各模块进行优先级排序，确定优化安排并跟进解决。

UAT问题列表（基本上问题列表内容都差不多）：

值得注意的是：

• 测试前需要做好相关准备，避免影响实际测试进度；
• 测试时用例需要围绕以用户为中心，体验用户的路径，发现问题；
• 测试后需要及时跟进并解决相关问题。

9. 体验监测

产品上线后，我们需要有定性和定量的数据来验证我们的设计是否OK；如果项目不是从0到1而是大的版本迭代，则最好有迭代前的体验相关指标，这样可以有前后对比。

所以上线一段时间后需要进行体验的监测：

• 与用研同学（如有，若没有则设计师自己协调）讨论体验监测规划；
• 协同用研同学一起把体验监测实施；
• 记录并梳理体验问题，与各模块设计师和产品经理对焦，进行排期解决；
• 协同用研同学整理产出体验监测报告，同步项目组。

我们这边用的定性研究方式是满意度调研，最终得出PSAT值：

Ps：想了解相关调研方法还请自行网上查找。

10. 项目资产沉淀

至此呢，整个项目承接的流程就结束了，但是还有一件很关键的事——那就是我们每次承接一个项目，都会有不同的认识和沉淀，无论是设计上的还是项目协作中的。

所以在项目结束后我们还要做一次整体的复盘，并且把可以沉淀的设计放到设计部门统一的资产库，另外就是横向的设计PM可以分享一些经验。

三、总结

以上就是笔者在承接大型项目的整个流程，有些节点大家在实施的时候也可以有所侧重，可能不一定适用于所有公司。

因为和公司内部的协作方式有关，所以笔者只是简单的分享了下自己在承接项目时的一些思考，分析的也比较浅，重在实际做事的流程。

大家可以用辩证的视角来看，欢迎大家一起讨论，多多交流，共同进步，谢谢～

本文作者 @江浦

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！