前端与UI设计沟通的那些事儿

一．目的

为了减少后期的返工及后期沟通，让页面组件化，加快产品迭代，统一规范页面，使产品整齐划一，简洁大方，更方便后期维护。

二．前期收到的文件

Ui会提供以下文件给到前端工程师：

2. 1份jpg文件: 里边有各个psd的动作分解图，包括页面逻辑，或交互分解。设计师放成这样的目的在于在做设计时方便的拷贝，但对开发人员来说，如果分级过于隐藏就会漏掉某个部分的开发。

2. 1份psd文件: 一份好的psd文件是分层清晰，设计规范的文件。

3. 1份需求文档: 需求文档是对当前开发功能的基础介绍或逻辑详细描述。（产品提供）

4. 1份原型文档: 原型设计文档一般是由产品经理对最初功能设想的一份粗稿，这份稿只是对布局或交互做简单的设计，需要经过设计进行艺术的加工之后，才成为一个可以呈现给用户的完整界面。

以上拿到这些所有的结果，需要经过层层开会审核，征得各个项目组leader的同意之后通过邮件的方式发送给各个成员，最粗笨的办法就是放在局域网的共享地址可以去拿psd文件。

三．收到文件后开始制定标准

根据产品提供的需求需求文档确定网站的设计风格

1.网站的字体大小（大 中 小  届时根据实际情况调整）

2.网站可能会出现的颜色（如黑色  浅灰  深灰  红色  浅绿）

3.弹出框的大小（大 中 小）

4.表单的整体风格（验证格式是否完整）

5.按钮的大小（出现hover效果）

6.组件之间的间距 规定一个标准（如 左右  上下）

。

。后续待补充。

四．可能会出现的事儿

1.有些时候太忙或者其他原因，未及时和前端沟通，然后口头上通知前端，未修改设计稿，这样只是单方面通知，这样改的话，这就是一个坑。要不然最后做出的产品，产品说的是一套，测试测的一套，开发的一套，老板看到的又是一套，返工的可能性很大。感觉比起这个返工的可能呢，前面多化点把设计稿做好是无可厚非的，而且从整个项目开发周期来看，是节省开发周期的。

2. 有些页面设计师没有考虑到，比如：

有些页面在没有数据的时候设计师没考虑到，或者经验不丰富就没做,或者是产品提供的原型文档没有考虑那些情况。

这时候必须要求设计师，给出首页或列表页、内容详细页、用户中心等等没有数据时的效果图，以示团队所有成员知晓，并达到一致。要不然等上线之后，测试数据删除之后真实数据还没有上来之前，老板心情好要看一下的时候，页面就整体失控。

还有一种情况就是前端自己整的数据没有的提示，从交互形式，文案上都没有规范，导致最后一步测试的时候在返回来重新修改，浪费时间。

3. 数据过多的情况：

另外一种常见的问题是数据过多或者文字内容过长撑开容器，这两种问题再实际做的时候常常会被漏掉，然后等到测试的时候才发现问题提过来。

解决方案：

所有的东西都必须出效果图，并且所有团队成员达成一致，有可执行性。所有的字体，间距，颜色，必须约定统一并且完全标识清楚，并且修改后要及时通知到各个组之间。

五．前端与UI之间爱的火花

1.如果想要95%以上还原设计稿，你必须提供给设计师设计时的注意事项，当然如果设计师有前端功底，他的设计会考虑到更多的协作性，通俗点说：比如设计的PSD稿件的图层切图的形状不要太另类，不同的分辨率，元素布局上你能不能敲代码实现，容不容易做出来，不要太自我主义不考虑前端，到时候做出来的东西又返回头改死人，甚至前端出来后一塌糊涂，两败俱伤。

2.你看过的或者项目交互上想要的效果，让设计师分析这种效果拆分后该设计些什么东西？设计量有多少？能不能用图形的方式直观的设计出来？等等

3.自己用铅笔在纸上画的草图，设计中的部分重要细节和你自己的想法要亲自提醒设计师。

4.项目碰头的时间段，如何碰头，使用远程工具？使用QQ？还是直接离开办公椅面对面？还是茶水间？是1天碰头一次？还是设计完某部分碰头一次？发现问题就可以及时修改，避免事倍功半。

5.让设计师准备好详细的设计说明文档，文档可以是直接套用html模板，可以是word，可以是图片或者思维导图，总之要让前端设计师一目了然知道为什么这么设计，这样设计让前端怎么用，怎么配合。

6.如果设计师有前端功底，你还需要让他提供一些他设计时考虑到的插件或者代码（比如设计banner时他想要视差，3D，还是滑动等效果，要用到什么插件，用了什么框架等），这样能提高前端的质量和效率。