产品UI如何规范自己的工作流

作为一名UI设计师，我们经常需要在工作中与多方对接和协作，大家都清楚UI设计并不是一个单线作战的工种，从需求到交互，从设计到开发，再从测试到上线，UI设计虽只是项目中的一环，但想要让自己的设计产出在团队里达成共识，就需要设计师将自己的工作内容渗透进成员协作的每一环里去。

这个时候建立规范的UI工作流不仅可以提高效率，帮助自己的设计成果更好的落地，对于刚入行的新人而言，也能降低试错成本，尽早的进入到一个规范的工作状态中去。

创建规范的工作流首先需要知道UI设计在整个项目中所包含的工作内容有哪些，再根据实际情况可以在不同的项目阶段来寻找最高效的方法，以提升自己的工作效率。

上面是我建立的一个UI设计工作流的模型，需要说明的是在这里我将交互也归纳为了UI设计的工作范畴，因为视团队的不同，UI设计师或多或少都会兼负交互设计的职责，如果团队中有独立的IxD职位，那么UI设计师的工作量则更多的侧重在视觉设计上。在图中UI设计师大部分的工作量都集中在设计环节，在这一环节之前我们更多的是与需求方中的一些角色进行沟通，为设计方案输入信息，而当设计方案成型后开始与各工程师进行沟通确保方案的落地。而到了测试阶段，则建议设计师转化身份为UI测试人员，对开发的设计成果进行设计还原度走查，因为即便在这一步会有测试工程师的介入，但最熟悉UI设计问题的也只有设计师本人了。

设计师在各阶段，因其工作内容的不同所要用到的工具和方法也不同，我们不强调哪一种工具最好，而是以目的出发，结合自身情况来判断运用什么工具跟方法可以最高效的达成目标，下面我通过对工具的介绍来解释实际工作当中我们需要解决的一些效率问题。

设计阶段 (交互+视觉)

设计师应该尽量的将精力跟时间都投入到设计本身上来，节省一些重复跟机械的工作量，这也是所有的效率工具不断优化的初衷。设计阶段都是我们最基本的工作内容，所以在这里不做过多赘述，只强调一下设计阶段需要注意的一些方法。

首先交互设计是一个需要快速梳理产品逻辑解决需求问题的过程，在这一步时我们要能够借助工具方便团队进行直观的沟通和讨论即可。运用Axure/墨刀等工具，我们将绘制好的低保真能够快速的分享给同事，让大家直观的看到一些需求的解决方案，这便为接下来的讨论提供了一个基础。所以只要能够快速的表达自己的想法跟设计方案的工具都可以拿来用。

到了视觉设计的时候，除了像素级的去优化设计稿以外，还需要注意作图、及命名的规范性，养成好的作图习惯，这不同于UI设计规范，“作图、命名的规范”是一种良好的工作习惯，有利于设计成果的输出可以方便的跟客户端对接。

如何规范作图跟命名，在这里详细介绍一下。

【作图规范】

我们在制作设计稿的时候无论是运用PS还是Sketch都需要考虑元素在界面当中的空间布局，很多时候我们的设计元素它是不规则的形状，就拿一组icon举例，即便我们很认真的将icon的视觉比例调整至相同（看上去一样大），但它们的物理尺寸实际上还是不一致，甚是还会包含小数点的尺寸，

这个时候要知道前端在开发布局界面时都是以数字模型来定义的，如果一个界面里所有的元素尺寸都没有统一性，那对他们而言在做布局的时候也找不到规则可循，对于开发效率和设计稿的还原度都会直接影响。那么在这个时候对设计稿中的切图元素都要把它规则跟标准化，把它们编组成为一个“元件”单位，这个元件单位可以是一个按钮一个图标或者一副插画，每一个元件的尺寸都必须是整数，每一组元件的尺寸都必须相同，比如导航栏的同一组图标它的尺寸应该是相同的，我用Sketch作图时习惯将切图元素画在一个统一的矩形里，目的就是保证元件的尺寸一致，这样开发拿到你的设计稿时，它们看到的也都是一个个规则化的矩块，布局效率就会大大提升。

作图规范还包括图层分组、栅格间距等规范，它和设计规范的不同在于一个是你需要养成规范的作图习惯，一个是你在设计中建立和遵循的一致性准则。用Sketch作图的话也要善用它的“Symbol”、“Layer Style”和“Text Style”功能，这对于创建设计规范提高作图效率都是有帮助的。

【命名规范】

在作图的时候一般只需要对切图元素做好规范的命名，其它非切图的元素是不需要严格命名的。规范的切图命名有时候会让我们觉得很麻烦，增加自身的工作量，但这的确也是一个UI设计师份内该做好的事情，一份规范的切图命名也可以帮助开发提升效率，让我们与开发之间的协作变得更加默契。关于UI的命名规范很多文章都有介绍过，方法也很简单，我在这里只提及一些命名时需要注意的问题，详细的命名方法可以直接搜索可得。

1. 1.iOS的切图命名可以使用大写字母，而Android的则不支持大写字母，所以有些时候我们可以在iOS中看到“navBtnBack@2x.png”这样的命名格式，它是用首字母大写来分割不同的区域，而相同的切图在Android中则可能是“nav_btn_back.png”这样的格式，因为方便起见一般我们在两端都会使用同一套命名规则，所以在这个地方都可以用小写字母加下划线的方式来命名，这也是目前主流的命名方式。（我不知道在国外是不是iOS的命名规则会用到首字母大写的方式多一些，因为以前在用zeplin的时候，它在iOS端默认命名会出现首字母大写的情况）

2. 2.iOS切图命名后缀是在末尾直接加@2x、@3x，而Androind切图是存放到不同倍率图片的文件夹中，所以命名后不需要加后缀，

3. 3.不同于iOS和Android，遇到web切图时，只需要提供一套视网膜屏下的切图就好，即iOS的@2x图尺寸。

开发协作

开发阶段UI设计师就需要紧密的去配合开发工程师，我们需要把设计方案准确的传达给工程师，所以在这一阶段，我们要使用一些工具来帮助设计与开发更好的对接，目前主流的协作方式已经升级为设计稿云端共享，这对于设计师而言主要是省去了动手标注和输出切图资源的麻烦，对于工程师而言，查看设计稿标注时也不会再有冗余的信息干扰，以及本地也不需要存储标注稿，相比于两三年前的协作方式，算得上是一次效率升级。

在这里插播一段回忆，记得几年前在大学的时候，我最早接触UI相关的工作方法，在切图标注这一部分，还没有那么多好用的插件，我第一次用PS去切图，需要把切图元素先转化成“智能对象”（为了让画布调整为切图的尺寸），再到“智能对象”图层中去把这个切图导出，还有标注时需要先测量，测量好了再画线，再将信息写到标注稿上去。要想把一张界面处理完，前前后后还是得花不少时间。再到后来，出现了一批优秀的标注切图工具，例如“像素大厨”、“Measure”，这极大的省去了我们在PS上纯手工的画线标注跟切图的时间。再到现在，那些曾经赞不绝口的第三方切图标注工具也逐渐的淡出了我们的工作，转而被新的一站式协同工具而取代。

在使用新的协作工具时，我们之前所强调的作图规范跟命名规范就突显出了它们的重要性，只有当你规范地作图跟命名的时候，你的设计稿才可以准确的被这些协同工具识别和正确的输出。目前主流的三款UI协作工具分别是“zeplin”、“蓝湖”和“iDoc”，它们的核心功能其实都大同小异，主要都是设计稿自动标注，智能切图，代码生成，添加交互，产品文档共享，生成设计规范等，也具有一些各自的特点，下面我分别介绍一下三款工具的使用体验。

【Zeplin】

它是我已知的最早的一款同类型设计及前端的协作工具，我是在16年第一次接触到这个工具，一上手便爱上它以及这种工作方式。

使用Zeplin时，设计稿都是上传在一个个画板当中，而所有的画板都归纳在一个项目里。但每一个免费账户，只能创建一个项目，在创建项目时就需要事先设置是iOS、Android还是web项目，因为项目的类型不同，则画板当中设计稿的标注属性也会不同，这一点跟国内的另外两款工具差别还是挺大的，其它两款都是上传之后，可以随时切换为不同的项目类型再查看。

我最早在使用zeplin时都是创建了两个账号，用两个账号分别管理iOS跟Android项目，这种做法其实挺鸡贼的，而且跟不同端的开发沟通时也需要切换不同的账号，再因为工作中一般都是只做一套设计稿，但又得同时上传两遍，会很麻烦，建议有条件的团队还是尽量使用付费服务。

我最后弃用zeplin的一个最大原因，是它查看设计稿的加载速度有时候巨慢，经常会打开画板显示一片空白，我猜大概是因为它的服务器在国外的缘故吧，我想这种基础体验上的问题肯定有解决的办法，可一直也没找到。目前使用zeplin的团队主要还是在国外的用户。

【蓝湖】

蓝湖是我目前在用的工具，首先它不会存在像zeplin那么致命的加载速度的问题，其次它的设计稿上传，团队成员分组，还有添加交互流程，这些功能都更适合我们当前的工作模式。

还有一点就是目前蓝湖的所有基础服务都是免费，只有需要做企业级本地部署才会有付费产生，这对于国内绝大部分创业型的小团队而言，还是挺友好的。

我用蓝湖的时间相对更长一些，之前还在跟我们产品经理讨论在做H5的时候对于一些稍大点的切图都需要压缩一遍图片，为什么蓝湖不能提供一个切图压缩的功能呢，每次还要我把蓝湖上下载的切图再用其它工具压缩一遍再交付开发，这样就有些浪费时间，可过了大概没多久吧，我就看到了它们加上了这个小功能，有点小惊喜！

蓝湖还有一个特点就是支持移动端App下载，我们可以直接在手机上管理自己的设计稿。

【iDoc】

iDoc是我近期才刚刚接触到的一款工具，大致体验了一下，在交互流程和切图标注这些核心功能上跟蓝湖相似，但它很多细节功能的确要比蓝湖丰富，很多功能的设计是符合实际工作场景需要的，比如设计稿的不同状态切换、图层的百分比标注、不同平台的切图尺寸换算，通过这些细节的体验能够感受到iDoc团队的诚意。

可能目前在功能方面我唯一觉得不足的就是我个人比较喜欢的切图压缩功能，这个目前我也只有在蓝湖上使用过。还有就是跟蓝湖相比，它的免费账号最多只能创建10个项目，蓝湖则没有限制，团队人数多的时候，可以考虑购买付费服务，支持一下我们国内团队做的这些优秀的产品，跟zeplin相比其实一点也不差。

最后再强调两点，一是不管大家是使用哪款工具，在上传设计稿的时候务必保证作图的规范性以及命名的规范问题，这会直接影响到你设计资源的正确输出；二是有些时候我们在做设计效果时难免会用到色彩模式，而目前这些协同工具都是无法读取图层色彩模式的，比如你在设计稿中给切图加了一个正片叠底而在导出切图的时候会发现切图元素则是没有加色彩模式的效果。

还原度走查

最后我们再聊聊设计稿的还原度问题，在工作中我们经常会遇到设计稿很精致可为什么开发出来的界面却总是有种说不出的粗糙，到底是设计的问题还是开发的问题，这时候我们就需要拿出自己的设计稿跟开发结果进行对比验证，找出造成开发效果差的问题来。

依据我的个人经验，其实还原度效果差，大部分原因还是开发没有准确的表达你设计稿的样式规则，或者说在你设计的时候都是以静态页面的形式输出，没有考虑到一些界面的适配规则所造成的。这个时候就需要我们端上小板凳，温和的坐在开发旁边一点点跟它们去梳理问题。

UI的还原度走查一般都是在测试阶段，这个时候测试工程师也在忙着测各种功能Bug，UI视觉跟细节体验上的问题还是得靠设计师自己去测，毕竟设计稿不是测试做的，设计稿的很多细节跟“精髓”，测试工程师也是发现不了的。

我一般在设计还原度走查上会列一个问题清单出来，这需要我同时持两部手机（最好是相同屏幕的机型），一部显示设计稿，一部显示开发结果，两部手机放在一起去比对，这样能更精确快速的找到UI问题的所在，当我把所有的问题List都列出来以后，我会把它们打印出来，再拿去给开发一条条的解释。跟他们明确了问题所在，他们就按照打印的这张清单一条条的去解决问题就好。有些团队可能会用“禅道”等在线协同工具去跟踪UI bug，但我更喜欢用自己的这种方式，更加扁平快一些。

那么等开发改过一轮轮之后，等达到了设计师的效果预期，那就可以申请发布版本了。当然这中间也要平衡时间成本，在大部分测试阶段都是功能优先，UI还原度则放在优先级的最后，因为产品最注重的还是首先功能流程得走通，不存在使用问题以后再来解决美观度问题。

总结

上述就是一段基础的UI工作流程的内容，其实就UI设计师而言，这一段基础并不能代表一个UI设计师的完整工作路径，它只能是最共通的一段核心工作内容。其实再往上到用研到数据，往下再到上线反馈、用户跟踪，UI设计师能够参与的范围还可以再扩大。随着行业的日渐成熟和更迭，以后设计师的职能还会发生哪些变化这些都还不得而知，但能确定的是我们身处在一个快速迭代更新的行业里，变化一定是会有的，我们工作中用到的工具，我们积累的经验方法，以及一个产品的生命周期，这些注定都会成为一个变量。

关于UI设计师工作当中的一些技巧方法以及工具的选择，希望能够通过这篇文章与同行设计师们继续交流，谢谢大家～