前言免费商业图片
产品视觉设计大致是由%产品界面和%运营设计组成。%的产品设计，属于理性，有规律的部分；而%运营设计，属于感性，表达创意的部分。本文想讨论的就是这%理性的产品设计。面对产品不断迭代，产品框架和结构不断复杂化，视觉设计师如何对工作流程反思和优化，从而实现干得更少，做得更多的目的，做一个「高效」但偷懒的设计师。
设计语言不统一，组件运用不规范等情况，大部分互联网产品都存在，原因种种。而作为产品视觉设计师，观其表更应审其内。了解产品逻辑，理解交互思维，将视觉相似功能相近（或其他可界定维度）模块整合，统一标准。如此既能保证产品功能的完整，又能保证控件统一，视觉可控。
借着起点读书改版的契机，我们重新梳理了全局控件，以及设计师之间，设计和开发之间的合作方式。通过几个月的实践，有了一些收获和心得，沉淀总结出来以供分享和交流。
关键词：组件化和功能。
所谓组件化是将产品设计中重复出现的控件整理归类，究其共性，以最小颗粒重组，通过整齐排布，并最终以准确易懂的语言来命名；使用过程中既可准确定位，又方便维护和修改，这就是组件化。而功能是中的多人协作的组件管理系统了解了这两个概念，开启本文正篇。因为产品视觉设计师工作性质问题，此流程优化涉及到两个角色，设计师与开发。
一设计师与设计师
以往设计稿维护
以往设计师各自独立维护设计稿，每个人的习惯各不相同，大致两类：
. 独立维护好几份设计文件(按版本或板块分割文件)，没有完整的组件库。
. 拥有一份文件，各个板块与不同版本堆积在此文件中，拥有独立的组件库。
以往合作流程
请随我们一起走一遍以往的合作流程：
. 设计师甲对视觉稿的某个共用元素进行改动
. 口头或源文件传播形式告知设计师乙
. 设计师乙根据最新改动手动刷一遍设计稿
. 设计改动是频繁的，设计师乙也有改动影响到设计师甲
. 按照的流程再走一遍，如此反反复复
这样的合作模式既浪费时间，也在消磨设计师追求完美的意识。我们也尝试过用很多流程工具来优化这个合作的工作流，包括一些插件，但结果不甚理想。而如果设计师在这种损耗中放弃抵抗，最后的结果就是每个人负责的板块视觉风格迥异，甚至连基本组件也不统一。
现在设计稿维护
的功能为这个问题带来了转机，这个功能，我们将设计稿与组件库分开，组件库单独存放在云端，设计稿存放云端或本地；设计稿的所有控件调用都从组件库抓取同步，也可以不断向下细分多稿并存并相互影响。
现在合作流程
.更改组件的操作
. 设计师甲更改了组件库中的某个组件
. 组件库保存改动，并实时将改动自动同步到云端
. 设计师乙的设计稿收到云端同步的提示，并根据提示点击同步，乙的文件即完成同步
.添加组件的操作
. 设计师甲在组件库中添加了部分组件
. 组件库保存改动，并实时将改动自动同步到云端
. 设计师乙需要用到甲新建的控件时去云端拉取即可，不产生重复劳动
.自动化规范的生成
因为个人习惯，通常项目都会维护一套规范文件，不过是在项目定稿阶段，但是随着项目周期的拉长，以及不断的调整变动，规范文件会版本过低失去其本身价值。组件库的应用对这一现状有了极大的改观。具体步骤如下：
. 项目空档期对组件库的文件进行排版规整，排布到组件库的一个子目录下，稍加命名排版即可形成初始规范文件
. 当设计师修改组件时，组件库会实时更新
. 添加组件时，在空档期把新建的组件再排版到规范中即可
如此，组件库可以始终保证同步。有时效性的规范，才体现出了规范的价值。
优化后的结果
.成本降低
举一个最简单时间的例子，做一张设计稿，若以前要消耗.小时；现在用新方法只需要小时，拆分一下.小时是制作组件库的时间，.小时是设计消耗时间。这样看来其实提高的效率也一般，但是如果把设计稿量放大到倍，以前的方案需要消耗小时；但是新方案只需要花费+小时，量大了，生产力其实会变的更加高效，因为这个个页面中公共元素不需要再设计，相似板块可以复用，所以时间减半。
而其实成本降低最高的体现是后期维护，因为运用了组件库，不需要以前那样一处一处的改正，初做设计时期，工具还没这么发达，在里面做设计稿，改一个顶部栏的样式可能就需要改动几十个页面，而现在维护起来，只需要改动一处，所有共用部分即可实时响应。大大降低了时间，提高了生产力。
.交叉同步
交叉同步，不占用各自时间，还可产生双倍暴击效果。举个例子：设计时花小时修改导航，设计师花小时修改工具栏。在以往的流程中，双方可能至少还要花小时，前期沟通，后期刷稿，而现在这个同步时间几乎可以忽略了。
.修改可见
借用的功能，所有的改动都有列表提示，让其他设计师可以二次确认，防止意外发生。
.文件变小
设计文件从开始的减小到 +， 是组件库的大小。设计文件的大小对设计师来说意义还是比较大的，会影响到运行效率和设计时的手感，当然用 的同行可以飘过。
二设计师与程序员
与程序员的合作主要是文件交接，以及线下交流，我们主要以文件的交接入手，进行优化。
以往提供
.视觉标注
以往提供的文件存在以下问题：
. 每份文件都是相对独立的，出自不同设计师之手
. 开发只看视觉标注来进行页面还原，没有其他文件做参考
. 相同板块因经手的人不一样开发出来的效果也可能不同，即产生了重复开发
.
以往提供的文件存在以下问题：
. 同一个会产生大量重复切图（颜色不同的都需要切图）
. 切图多， 文件过大
. 显示效果比较模糊，体验较差
.图形类切图
以往提供的文件存在以下问题：
. 文件不聚类，没有总览
. 尺寸凌乱，没有规章
. 设计风格不一，看上去不像同一个的配图
现在提供
可能你会疑问这不是提供的文件更多了吗？不着急，这些文件虽然多了，但其实这是必要的，虽然提供的多了，但是花费的时间是变少的，质量也是提高的，我们一个个分析。
.控件规范（半自动化生成）
刚才我已经简单介绍过控件规范是如何形成的了，现在我们来看，我们这样做会带来哪些具体好处：
.思维同步，我们提出的组件化思维跟有追求的程序员的组件化思维是基本一致的，所以在合作中，这两个角色间的理解程度会相应提高，并慢慢的互相理解，减少了很多不必要的时间浪费。
. 模块总览，起点改版的规范都是按照类型细分的，定位查找比较方便，既节省了程序员的时间，也能让每个组件的还原拥有规范依据。
. 节约资源，这里举例来说明，上图是同一个产品三个页面的截图，可以看出同样的组件，因为是不同的程序员开发，所以产生了三种不同的前台表现。这个在产品最终还原中算比较常见的，但也是不能容忍的。而现在通过我们整理的规范，很容易就可以定位到此控件，并解决问题。
. 走查定位，其实这个问题刚才的图也可以解释这一点，以前设计师都是对比单个设计稿来走查。现在通用组件的走查可以用控件规范来对比查找。这不仅帮助我们提高了效率，还可以一次性定位大部分页面的问题。毕竟再优秀的的设计结果，也依赖于开发的实现还原。设计师不能只关注视觉稿的交付，也必须要为最终在用户面前展现的结果负责。所以输出一份规范文档，还是非常有用的，良心建议。
.视觉标注（自动化）
. 直接推荐插件，可以快速生成整套的标注文件。
. 目录式表现，上图中间部分是视觉稿的组件摆放展示，开发者可以根据设计师输出的标注文件准确定位到组件命名，平时的开发只需要用到视觉标注文件，控件有疑问时，还可根据命名去规范文件中查找详细规则。
. 类 （手动但成本很小）
矢量图标的好处毋庸赘述，无论是从设计角度还是到产品还原角度，都应该安利给整个团队。
. 灵活多变，可以随便变化任意尺寸颜色，而且只需要切一次就解决以前一个切了几十个的现状。
. 体积小，一个格式的 ，比单个的 都要小很多。
. 高清显示，无论手机屏幕的分辨率是多少显示都不会失真，强迫症患者的福音。
.图形类切图（手动但成本很小）
. 归类排列，通过以上图片可以看到，将所有的标签类切图或者不需要切图的部分都已经整理到同一个文档中。不仅如此，其他类型切图也都有统一整理，这里不一一展示。
. 用色，尺寸都是在规范之中，导出也是一键式的。
优化后的结果
.所有流程可见
整个项目合作中，流程可见，我们的每一步都有迹可循，不会产生冗余工作。
.设计结果条理清晰
组件库规范文件，以及最终的视觉稿，每个文件的结构内容都保持整洁清晰，无论是交接，还是传播都比较容易理解。
.节省开发资源
所有组件均有总览，重复开发的问题减少。最终既节省了开发资源，也保证还原品质。
.问题快速定位
这一点主要是影响了后期的开发还原，前文也提到，视觉走查时，可根据还原结果对比规范，准确定位组件的还原问题，并迅速跟进。
总结
结合组件化和 功能对视觉设计流程的优化。可以发现设计师之间，降低了协作成本，提升了工作效率，变相改善了设计结果；设计师和开发之间，优化交接流程，更可控的交付物，以双赢的方式推动开发更好地设计还原。
后续我们将深入到组件化的细节，讨论如何构建组建化，敬请期待。