虽然作为 UI 设计师，但在公司日常的工作里肯定少不了设计运营相关的需求，比如设计一些广告 Banner，线上的活动页面，线下的展架等等。

大多数设计师在处理这类需求的时候都力不从心，疲于奔命。原因有很大一部分不是设计内容本身的难处，而是在于项目混乱的流程和执行上，比如其中一个学生“糯米”的例子。

糯米目前在一家电商类的公司，最主要的工作都集中在运营类页面的设计，日常加班不断，多次和我吐槽流程毫无章法，设计师之间配合也没有任何规范，加班的来源都是因为内部的混乱导致，让本来几个小时能处理完的事情硬生生的拖了好几倍的时间。

所以我们来分析分析有哪些情况。

比如要做一个促销活动页面，具备海量的活动文案和商品信息，还需要同时设计 PC 端的网页和移动端的网页（也就是以前说过的H5），比如下面的图例活动。

这时候，这个活动的需求方有策划A、策划B、运营A、运营B，PC和移动端分别由设计A和设计B负责。

通常，整个项目的流程理论上是需求方内部确定好方案，做出文档，然后和设计开会沟通，进入设计阶段，设计做完以后评审，得到修改建议后改完导出，开始开发。

但是真开始执行，完成第一版设计的要开始收集修改意见时，问题就来了，会有很多在评审会议以外的单独修改建议通过沟通软件或者邮件发送出来。

比如运营A突然说产品玩法要更新，需要修改某些活动内容和产品。设计A和设计B手忙脚乱的改起来，刚改好上传图片，策划A的修改建议也来了，又要调整某些产品名称，于是很短的时间内改好再进行上传。刚上传好运营B又说，XX发现库存没有了，要删掉……

以此类推，反复执行十几次以后，就会出现讨论群和邮件导出图满天飞，导致：

• 运营和策划开始不知道哪个版本是最新的

• 运营和策划不知道对方提出什么修改建议导致提出的内容有冲突

• 设计会遗漏某些重要修改建议做了无用功

• 两个设计最后导出的版本内容不匹配

• 再次审查时记不住之前所有调整的内容有哪些，重新翻记录

• ……

有一个特别有代表性的细节，设计A请假，运营需要修改一个他设计页面的价格，由设计B来改，因为没有他的源文件，所以直接在 JPG 文件中替换图形元素。

设计A回公司以后，又对页面有了新的修改建议，他又用了自己的源文件进行修改，但前面变动的价格并没有体现在他后来修改的源文件中。

所以一个版本的文件出现分叉，并保存到不同成员的电脑中，最后只能得到不完美的结果。审核时老板拍桌子：为什么价格错误这么多？

然后就是推锅和撕逼的环节……

以上问题每天都在上演，整个项目的时长随修改的数量呈几何倍数增长。改稿不仅让我们折寿得更快，也是推高我们发际线的罪魁祸首！

所以，简单来讲讲工作中遇到问题的原因是什么，才能做出有效的分析进行规避。

1、修改建议提交方式零散琐碎，没有进行收集记录

2、导出图片上传的方式不规范，版本混乱

3、源文件存放方式封闭，容易导致版本分叉

4、评审方式原始，效率低下

设计的环节如果没有合理的流程，那么持续累积上面 4 个问题以后，就会不停的降低我们的工作效率，让原本应该很简单的事情变得异常复杂，同事关系变得异常严峻。

想要摆脱这样的困境，就建议大家开始执行下面的方法。

从上面知道我们要解决以下四件事情，需求管理、效果图管理、源文件管理、评审管理，在后面一步步进行解释。

需求管理

第一步需求管理，可以参考在 UI 中测试的环节，推荐使用类型 Teambition 类的看板管理工具，将每次修改的流程分为 4 个步骤，待确认、确认、审核、已完成。

策划和运营，需要做出的所有修改建议，都需要单独提交到「待确认」列表中去，一个问题提交一个卡片，并可以在里面增加对应的细节说明、截止时间。如果出现需要多个版本修改的地方，可以再在子任务中添加不同版本的修改标识。

设计每天固定时间审查一遍确认需求，一方面是搞清楚这条内容具体修改什么，另一方面也要看看会不会在需求池中就出现了冲突的内容需要提前进行协调。

被确认的条目就要设计师自己拖动卡片到确认列表中，等待执行。设计师逐条进行解决，没完成一条，就可以将它拖动到审核的列表中去，等待审核方验收。

最终，只有需求方可以在完成审核以后，将卡片拖动进已完成列表，并勾选完成。

这样每一条需求从记录到完成都可以非常清晰的展示在看板列表中，不会有遗漏，便于进一步的写作。

效果图管理

效果图管理一样建议使用工具，这里推荐蓝湖。因为它有两个功能可以非常便于使用。

第一个是版本管理功能，第二个是添加备注功能。

每次我们完成修改，就将设计提交到蓝湖上，并生成对应的项目链接给运营，保证他们每次只能从一个地方看见最新的版本，不会每个人电脑里存的还是聊天记录里有很多版本图片。

在使用版本管理上，我建议每天定义成一个版本，或者对整个需求做出极大变动作为一个版本。在更换版本前，每次我们提交的新修改图片都覆盖原先的文件，并在修改的地方添加标注文字，这样每个版本的文件可以记录下所有当前版本修改过的地方。

然后每次审查查看旁边的批注列表，就可以快速定位到修改过的位置。

源文件管理

至于源文件管理，在之前项目文件命名的章节中提过，就是使用同步盘了，无论是坚果云还是 Dropbox 都可以，保证一个项目中所有设计文件的唯一性，任何设计师修改了能同步给其它设计师即可。

审核管理

最后，就进入审核管理了。要对前面的步骤有严格的执行，在最后审核的管理上才会有序高效。

普通的审核就是在设计师拖动完问题卡片到 「待审核」 状态以后，在蓝湖中预览。但建议每个工作日刚上班或是准备下班前，对当前的版本做一次完整的评审，而评审的标准就是从核对已完成的列表开始一条条过。

需要所有项目的需求方人员到场，哪一条修改有误或者沟通没有到位的，那就现场对这条问题商量解决方案或者重新拖回待确认中，没完成一次审核，那么就可以在蓝湖中创建一个新的版本。

这样，就能保证每次评审的时间压缩到最小（只是核对设计修改项），而且最有效，任何问题，无论是提出的人本身有误，或是设计师执行不到位，都可以定位到责任人，避免没有意义的撕逼。

可能很多人会觉得流程化的解决步骤特别繁琐，但这是我们从无序低效过度到高效的必经之路。

这种流程往往也需要设计师自己发起，让团队成员接受并持续做出改进。想要保证不被没有意义的加班拖累，有更多的时间留给创作和生活，就积极的推进规范化的协作方式吧！

祝大家少加点班，守住自己的发际线……