前言

好久不见，各位安好。

今天来讲讲，设计师在团队配合中，做那些事情可以帮助项目的推进。

身为一个设计师，在项目推进过程中会经历不同的阶段：需求调研、分析、熟悉业务、设计评审、对接开发、最后页面走查，当然每个阶段参与程度是不一样的；而对于设计师在每一个阶段需要做些什么，才有利于项目的推进。在面对复杂的设计问题、复杂的业务流程，如何准确的把握，在完成设计稿和对接开发时，怎样做能减少沟通与返工的几率？

因为每个企业和团队的人员配置不同，工作流程也有所差别，本篇文章是讲我个人在做B端产品过程的总结与体会，若有不恰当之处，愿诸君指出。

了解项目背景

项目背景和属性是项目最基本的信息，项目启动前期，很多设计师觉得了解项目背景是项目总监与产品经理的活，所以不会去涉及，而我不这么认为，觉得还是挺有必要的。

我会定向的去了解，产品面向的是企业还是政府，属性是电商、办公或者是数据管理类等，虽然我不需要像产品经理对项目背景理解得透彻，但我的大脑里要有大概的信息。

那如何了解呢？最笨的方法我是直接问项目总监、产品经理，他们对项目的这方面肯定是最清楚的。

参与需求调研和分析

在项目立项前期，产品经理把收集的需求进行整理和归纳，召开需求讨论会，给团队介绍项目情况、业务线、产品目标，产品要解决什么问题等，这只是初期的讨论，在头脑风暴过后，产品经理对讨论的结果进行优化落实，然后和客户再次核对确认，最后输出产品文档、原型图。

B端设计师参与讨论有什么好处呢？好处是，对项目有更加深入的了解，对产品业务，产品目标，能解决什么问题，有进一步的认识，不至于在设计时，对产品要实现的功能不清楚，云里雾里过于被动。

做一件事之前，先要把事情弄明白，做的过程中会遇到那些坑，有什么办法避免……

做好资料素材收集

通过参与会议讨论，知道了项目要做些什么，在没有接到产品文档原型图之前，我会提前去查找相应的产品、资料来加深了解，做到未雨绸缪，在设计时不至于没有灵感和方向。

说到这，提示一下B端产品资源的局限性，因为B端面向的是企业内部和政府内部，外部人员是接触不到的，尤其是政府机构的B端系统压根你就接触不到，所以参考资源也是少，也是B端设计难点之一，最好是平时要养成积累素材的习惯。

核对产品文档

在接到产品经理的原型文档，我没有急着去做设计，而是先把文档和原型图仔细的看过几遍，把不清楚的功能点、复杂的流程和逻辑，罗列出来做好笔记。

 同时我也会甄别一些需求，标注自己的看法，做完这些后再和产品经理进行核对，把不清楚的理解到位，把复杂的流程理解清楚。为什么要核对呢？目的是预防原型文档有遗漏或者功能有缺失，更重要是加深设计师对业务、需求、产品功能的熟悉，避免信息不对称沟通不在一个频道。

设计与评审

在进展设计前，我会先考虑产品是旧版升级还是新研发，这个很重要。我就遇到过这种情况，之前做过一个旧系统改版升级项目，系统是十年前那种风格，客户已经非常习惯系统原本的操作方式，当我们把改版好的交付给客户试用后，就遭到了投诉，反馈原因是系统操作困难不方便，领导不习惯。

 最后才明白，无论他们曾经的系统使用方式和交互有多么糟糕，在改版的时候，不要试图立马能改变一个已经使用了十年的习惯，也不要尝试颠覆性的设计，而是尽量保持原有的功能入口、操作方式、按钮位置，要有循序渐进的优化思维，不能把步子迈的太大，尽管你的页面和交互方式很友好。

其次B端产品设计师要熟悉组件的样式，这个是很有必要的，遇到周期短的项目，开发可以使用封装的组件，减少开发时间。在设计稿完成后，团队会进行页面的评审，目的是在于核对功能、流程是否有偏差，或者是提出更好的设计建议，最后还要输出一份设计规范文档。 

设计稿输出

最终设计稿的输出，不仅仅是页面的导出，你可能会说很简单啦，直接用Sketch插件导出设计稿，间距、字号、颜色全部都有了，直接丢给开发就完事了，其实这样的输出是不完善的。

在做B端项目中，业务的流程会涉及到角色权限，而每个角色拥有的功能和按钮是不一样的，所以不仅要输出页面，同时还要把操作流程、页面跳转、按钮权限，通过流程图的方式表达清楚，这对开发调页面是很有帮助的。

设计对接、校验

到了与开发对接阶段，开发人员拿到设计稿，我会给开发人员把设计图讲述一遍，目的是让他们熟悉将要开发的任务，其次是把功能和要注意的点要讲清楚，特别是B端产品的流程页面，一定要讲述明白，因为页面开发完成后，要加流程和权限，如果不清楚，沟通和调试的过程挺浪费时间的。

项目在进行测试阶段，设计师要对页面进行核验，保证与设计稿能基本一致。当然也要看产品处于什么阶段，如果是产品初期、定位不明确，时间又很紧急的情况下，那就要先保证项目能落地，视觉效果和产品体验可以放到后期，当产品成熟、业务明确之后再来细化打磨。

 设计做完产品上线之后，同时要把产品使用手册、产品宣讲PPT其他的服务设计，做好项目的前后服务。

最后：建立工作方法论

在这里谈工作方法论就有点夸大了。其实想表达的是，作为设计师不要局限于做设计，也要尝试跨越，对设计的上游和下游有所涉及，培养合作的默契，当项目人员调整的情况下，也能承担职位边缘的一部分工作，让项目顺利的进行。

在进入新的团队适应时，学会根据团队的实际情况，来调整和优化自己的工作方法，把自己做到最高的价值输出。

最后的最后，希望这篇文章，能够让刚从事B端产品的设计师，想从事互联网的同学，有一丢丢帮助。

今年也是很特别的一年，愿各位身体健康，笑脸常在。

Powered by Froala Editor