前端开发者如何与UI设计师沟通

àì夳堔傛蜴生んèń 2022-09-22 15:56 261阅读 0赞

一般设计师给前端的只有psd，没有其它多余的东西，连基础的文档都懒得给。前端期望中的设计能给予的除了psd之外，还有设计上游岗位传递下来的东西。比如：产品原型，需求文档，交互文档等等。  
一般在真正的代码开发进行之前，前端期望中设计给的东西有：  
1. 1份jpg文件: 里边有各个psd的动作分解图，包括页面逻辑，或交互分解。设计师放成这样的目的在于在做设计时方便的拷贝，但对开发人员来说，如果分级过于隐藏就会漏掉某个部分的开发。  
2. 1份psd文件: 一份好的psd文件是分层清晰，设计规范的文件。  
3. 1份需求文档: 需求文档是对当前开发功能的基础介绍或逻辑详细描述。  
4. 1份原型文档: 原型设计文档一般是由产品经理对最初功能设想的一份粗稿，这份稿只是对布局或交互做简单的设计，需要经过设计进行艺术的加工之后，才成为一个可以呈现给用户的完整界面。  
当然这些所有的结果，需要经过层层开会审核，征得各个项目组leader的同意之后通过邮件的方式发送给各个成员，最粗笨的办法就是放在局域网的共享地址可以去拿psd文件。  
恩，然后所有的中间需求变更、界面变更都要抄送相关人员，免得中间再次沟通，浪费时间。

还有公司更详细流程是这样的：  
1、需求提出，产品跟产品leader沟通需求  
2、产品leader跟开发、测试、ui/ue要人，要排期  
3、要来的人大家一起开发，挑战产品经理，跟批斗似的，产品拿着需求文档讲ppt  
4、需求回归  
5、继续批斗（4、5一直重复）  
6、需求ok了，开始ui/ue设计  
7、评审ui/ue  
8、ui/ue回归  
9、开发  
10、提测  
11、回归  
12、上线  
13、有问题回滚。

另外公司的设计是这样的：通常PSD要把交互效果的图层都做好，出JPG的时候，  
都会把默认状态，交互状态，管理员状态各自出一个，然后弹窗布局出一个，都做得很精细。  
这样导致的结果是想犯错都没有机会。

有的公司设计部有自己的规范，首先他们出的图都是很合乎规范的，  
间距、色值、布局、字体不会很多，因为整个产品多个页面风格要统一一致，  
所以越花哨是越给自己找麻烦，他们也不会有特别多种不同规格混揉在一起。

还有的是跟产品开需求会或项目立会的时候，会先就具体需求的功能点先做可行性方案的讨论，  
如果开发成本过高的话，通常都会说服需求方用一些替代方案。  
又或者是一些高级的功能模块，我们会把项目拆解，分成几期，首先先出核心功能模块，上线之后再做一些高级需求的模块，实现产品的迭代开发。

另外一个观点是从产品的高度来看，设计、前端、后端 应该是一个整体，最终应该结果导向，  
产出的产品不好，作为开发团队其实都有责任。

还有的情况是，每个项目都会有汇总目录，原型是由需求直接提供的，PSD和JPG在设计的汇总目录里，我们的制作稿又是一个汇总目录，所有环节的童鞋都可以非常直观方便的查看这些文件。

然后跟设计交流的时候的坑有以下几种情况：  
1. 有些界面出于时间或员工本身经验素质的问题就是不愿意出psd图，然后口头上通知前端，这样来就可以那样改就可以了，这就是一个坑。  
按我们的经验对这种情况做出的建议是：  
所有的东西都必须出效果图，并且所有团队成员达成一致，有可执行性。  
所有的字体，间距，颜色，必须约定统一并且完全标识清楚。  
杜绝直接这么说那么干的做法。  
要不然最后做出的产品，  
产品说的是一套，测试测的一套，开发的一套，老板看到的又是一套，  
返工的可能性很大。  
我感觉比起这个返工的可能呢，前面多化点把设计稿做好是无可厚非的，  
而且从整个项目开发周期来看，是节省开发周期的。

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

还有一种情况就是前端自己整的数据没有的提示，  
从交互形式，文案上都没有规范，导致最后一步测试的时候在返回来重新修改，浪费时间。  
3. 数据过多的情况：  
另外一种常见的问题是数据过多或者文字内容过长撑开容器，  
这两种问题再实际做的时候常常会被漏掉，  
然后等到测试的时候才发现问题提过来。

还有两种情况会遇到：  
A. 有些前端在看到设计稿的时候，难免看的不舒服，这时候就从非专业的角度开始提建议，但提的时候又不流行技巧，容易发生冲突。  
这时候给出的建议是：  
提意见是这样的，除非你干过设计或者了解设计的创作过程，否则从设计的角度最好不要提不同的意见。  
可以从交互或功能或体验上给建设性的意见，  
另外讲的时候是需要技巧的，可以先正面肯定一下他的劳动成果或努力的结果，  
然后说，我这儿看到几点问题，跟你交流一下，然后布啦布啦，  
而不是直接上去就说，我感觉这儿怎么怎么的，很主观的，说这样根本没有一个评判的标准或依据。  
最后一定要说，根据你的行业经验或自我设计标准，你肯定不会允许这样的现象出现吧，然后你看要不要在重新考虑一下。我就是想到了给你提一下。  
强调这个非正式的提法，给自己或对方都留有余地，都有可以退让的空间，皆大欢喜。

B. 要是效果图是客户提供的怎么破？在沟通是有什么经验？  
设计的质量如果本身就有问题，比方说就没考虑添加数据以后的情况，  
或者是其它页面在流程上风格上不统一怎么怎么的，  
客户又不是很懂，初期非要你按照他的想法来。  
这时候就需要站在一个更高的高度来有技巧的处理这个问题。  
比如说，你这个页面等上线后，在用户看来2个页面看到的按钮不一样，  
感觉很外行，从而导致的结果就是下次不在访问，这样用户就会丢失。  
你看有没有必要重新考虑一下。