产品设计的迭代过程中，难免会遇到需求量大、上线时间周期短、人力紧缺、研发技术实现等问题，通常这种情况，无论是互联网大厂还是中小型公司，都会采用项目组的形式统一协调管理。

设计师作为其中重要一环，在项目启动之前、项目推进过程中、以及项目收尾阶段，主要的工作内容和职责是什么？在不同阶段有哪些需要注意的事项？近期参与了公司的一个此类大型项目，尝试着将以上问题做个梳理，希望对你有帮助。

一. 项目启动阶段

1.1 评估需求内容、工作量和人力

前期通常是业务方、产品、设计、研发和测试各方向负责人，大概圈定出各产品线的需求内容与需求量，并且确定全部需求上线的时间节点。

依据这份需求清单和限定时间，各职能方向的负责人需要对照本部门现有人力，大概评估可能存在的风险点。对于设计负责人主要关注的点包括：留给设计交付的时间是否足够？限定时间内现有人力是否满足？是否缺少完成特定需求的设计师？

存在以上问题需要及时反馈给项目负责人，接下来自然是挨个解决问题。设计交付时间如果可以适当延长更好，如果节点已卡死只能是现有人力加大工作效率和产出、或者增加人力支援、或者紧急招人。

一般来说紧急招人肯定是来不及的，另外新人的业务沉淀不够、并且没有经过实习期对工作流程和内部设计内容的积累，很难适应高强度高要求的设计工作。这次我参与的项目，人力方面调集了公司其他事业部的设计师前来支援。

1.2 了解支援设计师的专业能力/过往项目经历/擅长方向

如果时间上来得及，可以提前与前来支援的设计师、或者他们的主管进行简要沟通，了解他们当前专业能力所处的阶段、过往大型项目的经历，以及擅长的方向等。

以此为依据，结合本次项目中不同需求的特点：比如需求复杂度、涉及多终端、视觉表现力等，分配任务。

1.3 设计部各方向负责人开会，明确需求内容并分配设计工作

设计交付时间已明确、人力问题已解决，那就开干吧。设计部主管会先召集设计内部各方向负责人开会，包括交互、视觉和运营方向的设计负责人。首先设计部各方向协调人要明确需求内容、统一话术表达、理清整体和局部的业务流程。

接着根据划定的内容、结合设计师的专业水平和擅长特点，分配设计工作内容。注意这里的分配也是大概圈定，后期项目推进中可能会有一些不确定因素，需要随时根据变动情况灵活调整人力。

1.4 规划工位，项目相关人集中坐在一起

由于有支援的小伙伴，为了便于设计内部和上下游不同职能同事之间及时沟通，项目组相关成员最好集中位置办公，这样可以提升沟通效率、节约沟通成本。

二. 项目推进阶段

2.1 提前汇总并公布设计工作注意事项

多人协作的设计项目，需要特别注意以下问题：

支援的设计师对业务了解程度不够，有必要组织介绍项目背景。

向参与的设计师讲解项目的业务流程，便于设计师明确自己负责的需求所处的环节和目标。

设计稿产出需要遵守本部门各端的设计规范。

设计师需要明确自己在项目不同阶段的任务和产出、以及上下游跟进人...

因此需要提前针对这些问题，汇总并公布相关文档、链接和说明，帮助设计师增强对业务的了解，让支援的小伙伴明确协作流程和上下游对接人、以及各自负责的需求在不同时间节点的进度。

2.2 分配具体任务，设计各方向负责人做好协调工作

设计工作处于需求落地推进的第一阶段，研发同事需要结合设计稿才能进入前台界面功能开发，所以前期设计师工作压力会比较大。

尤其是面对时间周期比较紧张的项目，往往上下游采用同步推进的方式：比如设计稿不必全部产出且评审调整后才交付开发，而是设计初稿阶段，下游同事已开始介入。

在需求设计阶段，很有可能暴露出以下几个重要问题：

需求功能或流程调整的信息没有同步，导致负责不同终端的设计师，针对相同功能的设计方案不同。

需求调整或者信息没有及时通知相关人，导致设计交付时间可能延后。

由于产品可能按照不同业务线或者不同终端划分负责的需求，某个设计师的设计方案中可能使用到其他设计方案的设置：需要设计师之间配合，结合各自业务综合考虑调整方案...

因此设计各方向负责人，需要及时协调解决出现的信息不同步问题，把控设计稿评审和交付进度，对不同设计方案，从业务角度进行全局质量和细节把控。

2.3 组织设计稿评审

设计稿评审是需求推进过程中的重要一环，因为交互设计师承担着将产品需求、业务逻辑、任务流程，以及易用性相结合，转化为界面的职责，所以交互稿的评审非常重要。

交互稿评审目的是让上下游同事更加直观的了解需求，研发可以据此判断页面逻辑复杂度与工作量，视觉设计师可以提前构思页面排版与风格。交互设计师会针对评审会提出的功能点技术实现问题、现有设置是否合理等问题，在评审会后统一调整定稿。

即便是非常紧急的项目，仍然建议组织交互评审。考虑到紧急项目中上下游同事时间宝贵，可以集中某个时间段，依次安排不同需求的交互方案评审。

2.4 配合研发跟进解决问题

当设计阶段结束之后，接下来就该研发小哥们撸起袖子加油干了。在需求研发阶段，经常会出现以下问题：

部分功能设置因为技术实现问题，不得不寻找替代方案，可能需要对现有设计方案做调整。

由于多人协作，可能针对相同操作场景，会出现不一样的设置，需要做全局性的规则说明。

研发对于设计稿中的细节有困惑，需要得到设计师的及时反馈...

基于以上各种可能出现的问题，设计师需要及时跟进处理，不然严重的话会影响开发进度。

三. 项目收尾阶段

3.1 设计验收与问题跟进

面对上线周期比较短的项目，当测试人员完成第一轮“跑通业务功能流程”的测试之后，设计师便需要介入，开始设计还原度验收。验收阶段需要解决以下问题：

设计师汇总的验收问题、解决进度和结果、以及无法解决的原因等，需要建立一份验收清单，便于项目组相关成员及时查阅和跟进。

按照项目中不同需求内容模块，在验收清单中建立不同的验收汇总表。另外强调一个细节：设计验收往往需要上传示例图，推荐使用石墨文档(石墨文档支持上传单元格图片，这个功能真的是很棒)。

验收表中明确写清楚问题的来源终端、解决结果、备注说明、提出人、解决人等。

另外项目中的部分需求可能按照不同时间节点发布，优先验收发布时间点早的需求。设计协调人需要及时跟进开发和测试，提前通知相关设计师留意设计验收的优先级。

3.2 收集设计师记录的问题和优化建议

设计验收完成之后，验收清单中的问题大致分为这几类：已解决、未解决待优化、无法解决。我们需要重点将“未解决待优化”的问题按照某些维度分类汇总、并给出设计部建议的优先级，便于后续版本迭代。

此外可以向参与项目的每一位设计师收集他们的建议和想法，包括业务逻辑、操作流程和体验、易用性、视觉呈现等不同方面。一些好的建议和观点，同样可以为后续版本迭代提供参考。

3.3 提前与产品沟通，在后续版本逐步解决待优化问题

上面已经提到了，对于验收清单中未解决待优化的问题、以及设计师基于自身对业务思考得出的想法建议，设计部各方向负责人需要按照某些维度，比如功能模块、终端、页面功能点等维度分类汇总。然后与相关产品同事提前沟通，按照待解决问题的优先级排期。

以上是我经历整个项目之后的一些经验总结，不同公司不同类型的项目，协调管理流程肯定存在差异，但是对于项目启动阶段的准备工作、推进阶段的问题把控，以及收尾阶段的归纳梳理，本质上是一致的。

原文地址：Viksea的设计思考(公众号)

作者：Viksea 版权归作者所有，如有侵权，请联系我们删除。