相信每一位UI设计师都遇到过设计稿精美、高大上，但开发还原出的效果直接从卖家秀变为了买家秀。为什么总会遇到这样的情况，我们如何解决开发还原度低的难题？

接下来我将结合自己多年设计走查的经验，分享一套能提升设计师与开发之间协作效率的方法带给大家。

PART 01

___

前言

为什么设计稿高大上，
还原出来却面目全非？

首先我们来看一下为什么在每一位UI设计师的成长过程中，一定会经历设计稿高大上，但还原出来却面目全非的情况。

作为UI设计师，我们的工作由两部分构成：界面设计和跟进还原。对于绝大部分项目来说，跟进还原实际占用了和设计差不多的时间，但这部分时间不包含在我们的工时估期内，这就导致许多设计师没有足够的时间和精力去验收自己的设计。另一方面，许多新人设计师没有接触过系统和规范的设计走查培训，他们做完设计后就直接导个标注给到开发，不整理设计稿也不懂如何进行验收，最终导致上线效果和设计稿差异巨大。       

除了设计师的个人原因（没时间、缺乏经验）外，也有外部原因造成还原度这个指标不够被重视。

一个产品验收的项目组一般由下图这四个身份的人组成：其中，开发会把重点放在功能搭建上，因为他们承担的职责是不可出现Bug；对待还原度，则基本全凭直觉，很多时候他们无法识别视觉稿的细节，使用接插件、简化样式等简化开发方法。对于测试和产品来说，也是同样的问题，他们的重点在于整体功能和流程的review上，没有太多精力同时也对视觉没有那么高的敏锐度。因此，还原度的重任就默认落在了设计师的肩膀上。

视觉设计师作为展示产品最终形态的执行层，为了每一次上线的产品都能够得到百分百还原，这就需要我们去了解开发到底是根据哪些规则还原我们的设计稿，以及在每一次交付设计稿的时候，都设定好细节规则。

举一个非常普遍的例子，设计师在验收时发现新设计的模块看上去比视觉稿要小，问开发原因，就发生了如下对话：

显然，这类问题本来是可以避免的，只要我们提前向开发阐述适配规则并且在设计稿中标明需要使用的适配方式，开发就可以在开发初期将适配考虑进去。

提高还原度的4大切入点

因此，了解在什么阶段、通过什么方法来提高视觉还原度尤为重要。每一个项目从产品需求的确定到产品上线，中间有四个环节是和高还原度息息相关的，分别是评审阶段、交付阶段、开发阶段和验收阶段。这四个阶段中都有关键点，需要设计师注意和把握。首先，评审阶段我们需要和开发宣讲设计重点、适配规则等，这些即便没有全部的设计稿，但思路需要表达给开发和测试。到了交付阶段，设计稿一定要经过仔细的整理，不要出现细节错误的地方，这会直接导致开发按照错误的标注去建立样式，因此整理标注这个环节很关键。到了开发阶段，即使我们前面所有工作都准备好了，也很难避免开发不找我们沟通，这时候我们要积极回应他们，并且和他们一起处理问题。到最后一步验收环节，我们要和测试同学协同合作，做好设计走查。 

接下来，对这四个阶段分别进行阐述。

PART 02

___

开发评审阶段需要注意什么？

我们的项目一般可分为展示型、流程型、动效型和样式升级型。这四类项目在评审时的侧重点是不同的。接下来分别来具体看一下。  

         

展示型

前台展示型项目侧重视觉表现，在评审时，需要用视觉稿评审。除了准备好全页面的效果图外，最好能够将设计重点标注出来，比如页面上滑时头部样式的变换，模块的不同状态等。如果在评审阶段只提供一个默认的页面效果，那会影响开发的估时，从而导致这些效果和状态无法按时完成。

相比App端，Web端涉及到各种屏幕尺寸就更为复杂，因此布局方式、适配规则这些需要设计师在评审阶段就和开发商议好。举例来说，网站头图就有多种适配方式，是选择头部定高并在指定高度内图片等比拉伸还是选择图片固定宽高，再指定一个背景颜色，这些都需要在评审时和开发确定好。从而避免开发按照自己习惯去适配或者验收时发现和预期效果不符的问题。

 

流程型

展示型需要用视觉稿评审，流程型偏重流程与逻辑，评审时，开发最关心的是产品主流程是什么。因此，交互或者产品需要首先描述任务流程，一般以流程说明图的形式来做可视化的阐述。阐述完产品流程后，交互同学需要讲解交互原型，具体到每一页的功能和逻辑。根据产品功能的复杂程度，交互稿的呈现方式也有所不同。比如下图中的某运营活动流程，采用了交互稿结合流程图的展示形式，让开发理解起来更直观。

         

动效型

对于动效类项目，开发最关心的点在于动画具体的变化流程，比如动作与动作之间间隔多少毫秒。因此在评审时最好提供动效Demo和动效说明，Demo能让开发对动画过程一目了然，同时便于开发确定动效的开发形式，比如简单动效由开发代码实现，复杂动效由设计师提供Gif文件等。

         

样式升级型

除了上述三种项目类型外，我们也经常会碰到视觉升级的项目。由于开发对于视觉敏感度低，只提供新的设计稿他们无法知晓具体需要优化哪里，有的时候我们看似很简单的一个改动，对于他们而言可能要动多处代码。因此，这类项目不能只展示新的设计稿，而是需要将新版和旧版放在一起比对，并标出新版的具体改动点，这样便于开发评估工时。

         

PART 03

___

交付阶段

前面部分讲述了在开发评审阶段我们需要把握的关键点，评审完后，就到了交付阶段。在交付阶段，为了提高设计还原度，我们需要以开发的思维做设计，整理标注文档。

Sketch的Symbol功能，
很接近开发人员构建UI的方式

大家或多或少都使用过Sketch的Symbol功能，Symbol除了能提高我们的设计效率外，它还很接近开发人员构建UI的方式。这里以信息流组件为例，向大家介绍通过Symbol来构建开发视图的方式。

信息流组件服务于各个业务线多种场景，不同BU需要展示的卡片信息都不同，因此信息流模版实际由多个元素组合而成，不同场景由不同的元素进行组合拼搭。

下图左侧展示的是信息流模版最全的状态，也是在Sketch中的设计视图，模版中的每一行模块都是一个Symbol。大家可以把Symbol看作是一个外部容器，外部容器决定了每个模块的高度，而元素在模块内的位置则由间距决定。比如标题文字自带的行高和下间距组成了标题模块。通过定义每一个模块中元素和间距的数值，可以确保无论信息流模版使用哪种组合方式都可以具备良好的视觉效果。

对于开发而言，这样的设计方式也符合他们构建UI的方式：即在真实的文本容器外再嵌套一个外部容器。实际的开发视图则是下图右侧示例。这样还原出的UI和设计稿几乎完全一致。

使用Symbol来设计除了能提升开发还原度外，它也非常利于我们快速进行效果图输出。通过编辑覆盖层，可以生成不同模块组合效果，如果需要修改样式，只需要调整Symbol就可以完成所有卡片的更新。最终通过一个模版，在设计上和开发上适配各种业务类型和场景。

         

整理标注文档

前面介绍的symbol功能是指导设计师以开发的思维做设计。接下来介绍如何整理我们的标注文档。首先是图标部分。

1. 图标
设计稿中的同一套图标容器尺寸必须统一，这样开发可以统一控件大小，同时设计师也可以规范设计。由于每个图标体量感不同，所以图标和容器的四周要留有间距。 

在交付图标时，如果是单色图标，需要让开发使用iconfont，iconfont是字体文件，它让图标以字体形式存在，不会有不清晰的问题。设计好的图标可以上传至公司iconfont网站，选择对应BU的图标库。

有的项目会使用到很多图标，这个时候就需要建立图标项目，把需要用到的图标都添加至项目中，然后选择管理项目成员这个选项，把相关前端开发加入进去，这样就不用每次通知开发新加的图标代码了，开发也可以一次性导入所有字体文件。

有阴影或渐变的图标无法使用iconfont，就需要提供给开发切图。一般提交3倍切图覆盖主流机型，由于我们是用750px（2倍画布）进行设计的，因此在Sketch中的切图选项要选1.5倍。

对于一些小于40px图标或操作，可以在标注稿里标示两个区域，告知开发写两个view，一个放切图或样式，一个处理点击。

2. 文本
整理完图标后，设计师需要对设计稿中的所有文本进行梳理。这个环节是很多设计师都容易忽略的部分。大家不要轻视整理文本的重要性，它直接决定了开发的还原度。

首先看下字体的结构。字体由字高、行高、行宽三部分组成。字高指的是我们肉眼所能看到的字体的实际高度，而行高指的是字高+上边距＋下边距，反过来说，行高减去字高除以 2 就能得到我们的上下边距。行宽指的就是整个文本的宽度。

为什么要定义行宽？一方面是为了让文本在极限宽度时进行换行或截断，另一方面是为了定义文本到其他元素的间距。我们在交付时，标注稿里的文本都应设置极限行宽，避免开发自定义行宽。我曾经就遇到过这样的情况：因为没有标注极限行宽，开发直接把文本行宽撑满于边界，导致验收时让开发再改写的情况。

接下来看下行高，行高对界面还原度的影响就更大了。文字的行高会影响开发对于间距的测量，一般Native开发不会专门去写行高，而是使用系统默认行高。如果视觉稿标注的行高与默认行高差距较大，就会导致开发还原度出现问题。安卓因为字体机型众多，比较难有个统一的对照值，所以一般以 iOS为基准。图中所示的就是iOS系统字体大小所对应的行高值，我们在写行高时一定要遵循表格中的数值。 

为了让大家更直观的了解定义正确行高对还原度的影响，这里通过三组同样字体大小，不同行高值来做对比。三组的文字大小都是32px。第一排是当我们未设置行高时，Sketch会默认显示45行高值，这时候开发按照我们标注写两行间距11，还原出的效果第二行文本会比视觉稿偏高。第二排是我们在Sketch中将字体的行高设置为字高32，这时候两行文本之间的间距为24，开发按照24写间距，还原出的效果就变成第二行文本明显偏低。第三排的效果是，当我们设置了正确的行高，也就是40时，实际还原效果就和视觉稿完全一致了。

这里推荐给大家一个非常好用的Sketch插件，它可以把Sketch中的字体行高自动调整为iOS系统值。使用该插件后，可以做到Sketch中字体行高与iOS开发中字体行高100%还原。具体的下载、安装及使用方式如下：

插件名
Auto Fix iOS Text Line Height

下载地址
https://github.com/youngxkk/AutoFixiOSTextLineHeight

安装方式
打开网页，点击code，选择download zip，下载完成后解压缩，找到.sketchplugin后缀名的文件，双击安装后就可在Sketch中使用。

使用方式
选中需要调整的文本，点选该插件就可以自动更改行高。

3. 多行文本
单行文本使用iOS系统行间距可实现开发的百分百还原，但阅读类多行文本如果使用默认行间距，很可能因为间距太小而造成阅读障碍。这时候我们设计保证阅读舒适性的行高后，需要跟开发重点强调此处行高需要进行额外设置，不然开发还是会使用系统的行高，这样就影响了展示效果。

         

iOS常见的适配原则

前面介绍了交付阶段正确标注的重要性，接下来说一下适配。很多设计师会觉得适配是开发的工作，交付时不会特意提醒开发要采用何种适配方式。比较细心的开发会问设计师关于不同屏幕的适配处理，还有些开发就全部按定高处理了，导致设计师在验收时发现大屏上元素很小的问题，这时候开发已经没有时间再写适配逻辑了，也就是我开头说的那个例子。安卓对于不同屏幕的适配是系统已有能力，但iOS就需要开发写适配逻辑。一般来说，最常见的适配方式是两种，一种是定高、自适应宽，另一种是等比宽高。比较通用的判断方法是，当页面无图片，多为文字，比如表单，那可以采用定高的方式。而当页面有图片时，就需要采用等比宽高的适配方式，这样在大屏上图文比例才能协调。

举例看一下。下图左侧这种图文版式布局，开发只对图片做了放大处理，因此在大屏上，文字会显得格外小，与视觉效果不符。所以需要在交付时就告知开发整个页面要做等比宽高的适配。

有的同学可能会问，是不是所有设计都可以采用等比宽高？其实是需要看具体页面结构和功能的。以下图右侧全站首页为例，首页头部搜索和底部Tab Bar是做定高处理，而其他模块使用了等比宽高适配。一方面原因是为了遵循iOS系统规范，规范中定义了Title Bar和Tab Bar在所有机型上定高处理，另一方面原因则是头部和底部定高后，大屏上露出更多内容的优势也被发挥出来。因此，除了遵循系统规范外，设计师也可以按照页面模块的具体功能来看选择哪种适配方式。

         

等比宽高的适配参数

等比宽高的适配参数具体是什么？有两种方式，一种是间距和元素都做缩放，另一种是间距固定，元素做缩放。我建议使用后者，也就是在所有屏幕上间距是固定的，只缩放元素。这样做的优点是在大屏上，内容元素可以更大的显示。如果你的开发对适配参数不是很清楚的话，你可以把下面这个规则参数发给他。

原则：间距固定，只缩放元素

参数：（实际屏幕宽度pt – 固定间距pt）/（视觉稿屏幕宽度pt – 固定间距pt）* 元素自身宽度pt

另外设计师们还需要注意，适配需要在项目一开始就告知开发，尤其是流程类项目，不然等开发完后再去增加适配，开发需要额外去判断所有文本、图片的边界，工作量会大大增加。

PART 04

___

响应阶段

当我们完成交付后，就到了开发环节。在这个环节，我们需要积极响应开发的提问。

在开发过程中，即使我们前面所有工作都准备好了，也很难避免开发不找我们沟通，这时候我们要积极回应他们，并且和他们一起处理问题。某些难度大一点的页面，开发会截模拟器的效果图给我们看，这时就要仔细去找问题，不要一口咬定就是开发的原因，先沟通具体原因，然后找出解决办法，如果是标注出现问题，那及时修改标注并提醒开发刷新。

积极响应开发的每一个问题

有时候我们会遇到设计方案看似简单但实际开发难度很大、开发成本很高的问题，比如下图这个商品卡片，设计方案是当价格和降价提示过长时，看直播的按钮换行，但实际对开发来说，他很难判断这两个字段的总宽度和直播按钮的关系，这时候开发会来和设计师沟通更改设计方案。 

面对这种开发成本很高且有风险的时候，我们需要积极响应开发，共同探讨备选方案，从而在开发成本和视觉效果中找平衡。最终我们将方案调整为只要出现降价提示，直播按钮就换行。

         

准备折中方案

有时我们会遇到开发时间紧迫，一些复杂设计来不及按期开发上线的情况，这时候我们可以先做个能兼容视觉效果和开发成本的折中方案，之后再迭代优化为最佳设计方案。

1. 案例1
以「我携」头部用户名的案例为例，最初的设计方案是希望开发做判断逻辑：当用户昵称小于9个字时，昵称字号使用40；而当用户昵称大于9个字符时，昵称字号使用32。虽然在交付时已和开发沟通了设计思路，但最后因为时间太紧开发还是没能来得及做这个处理，因此我们提供了折中方案：即统一使用36字号，从而保证大部分用户的视觉效果，同时兼顾长昵称用户的情况。再到下个版本，开发再优化为我们的最佳方案。

2. 案例2
有时我们会遇到开发时间紧迫，一些复杂设计来不及按期开发上线的情况，这时候我们可以先做个能兼容视觉效果和开发成本的折中方案，之后再迭代优化为最佳设计方案。

来看这个案例：新版「我携」头部有换肤功能，我们的设计是默认未换肤时，头部操作icon为黑色，当用户更换背景后，icon为白色，同时背景图叠加黑色蒙层保证icon识别度。但实际开发过程中，这个判断难度很大，iOS和安卓开发都无法在一个版本内完成这个功能，因此我们设计了折中方案，即换肤后依然显示黑色icon，但背景覆盖白色蒙层，以兼容所有颜色的换肤。虽然这不是最佳设计，但它兼容了视觉效果和开发成本。等下个版本开发再实现我们的最佳方案。

PART 05

___

验收阶段

响应阶段结束后就到了最后一步验收阶段，在这个阶段，我们要和测试同学协同合作，做好设计走查。

什么时候开始验收？

在验收阶段，我们要明确什么时候开始验收和如何验收。按照Native 两周一个版本来看，周四发版，周五是下个版本的需求评审。因此开发时间一般是下个周的周一到周五，对测试来说，前面两三天写测试用例，周四周五开始陆续提测，这个时候是第一轮测试，测试结果没有大问题后会让视觉验收，因此一般视觉验收时间是周一。设计师验收第一波，提出视觉问题，周二周三测试开始测第二轮，同时开发边改测试边测，设计师在周二和周三第二次视觉验证，针对遗留问题，需要根据实际情况评估是否修改，周三测试会再进行一轮常规功能验证，理论上不能遗留Bug，周四发布日，验证最终包常规。

       

如何验收？

具体如何验收，根据项目组的要求和开发的习惯是可以有多种方法的。我一般是在截图上标注出问题点，有的开发要求以conf的形式填写问题，这样便于所有项目组成员知晓这个bug是否已修正。还有最原始和效率最高的方法是拿着小板凳坐开发边上一个一个调。

PART 06

___

那些年我踩过的坑…

接下来介绍那些年我踩过的坑，一些典型的还原度案例。

分割线的处理方式

我们经常会遇到需要1px分割线的场景，但有时候开发实现出来的效果却比1px粗，过粗的分割线缺乏精致度。我们在设计的时候1px很容易做到，但对开发来说，各手机众多的分辨率、各平台，会使得这1px变得无比复杂。

1. Native分割线常见写法
Native分割线目前有3种写法。第一种方法是所有机型分割线使用1pt，这种方法的特点是普适性最好，但在2倍屏上，分割线会变成2px，3倍屏上会显示为3px，看上去不精致.

第二种方法是计算不同倍数屏幕上展示1px的实际pt值，比如2倍屏上分割线显示为1/2，0.5pt，3倍屏上分割线显示为1/3，0.33pt。这种方法理论上在任何倍数屏幕下都会呈现1px的效果。

第三种方法是在所有屏幕上高度都写为0.5pt，这是开发用得最多的方式，大多数情况下会有良好的表现，但偶尔可能出现同一页面分割线粗细不一致的情况。

我一般会建议开发使用第2种写法，实现下来基本没有出现过问题。如果遇上第2种效果不理想的情况，可以换成第1种，但记得要把分割线的颜色改浅。  

2. H5分割线常见写法
H5分割线的写法有很多，我对接过的开发比较常用的方法是第一种：通过背景渐变的方式把分割线分为上下两部分，一部分透明，一部分是分割线色，以得到1px分割线的目的。但这种方法的缺点是无法适应圆角。

3. RN分割线常见写法
RN分割线常见的也有两种写法。第一种是将view设置为绝对布局，以保证将分割线作为一个view的的时候不会出问题。第二种是使用已经封装好的组件，这一常量始终是一个整数的像素值，会使线看起来像头发丝一样细，并尽量符合当前平台最细线的标准，如果模拟器缩放过，可能看不到这么细的线。

         

描边的处理方式

以上是1px分割线的写法，如果你的开发不熟悉最细线的写法时候，你可以把这些方法拿给他参考。但是用在描边的时候（如按钮），1px边框有时候会出现粗细不均的情况，所以对于描边，还是按照1pt（2px）的方式来还原。

         

阴影的实现

阴影是另设计师和开发都比较头疼的问题。我们常常发现阴影的还原与视觉稿差异过大。

iOS、Andriod、RN、H5对投影的写法和支持程度不一样，会造成实现效果与视觉稿的差异。

iOS和H5对弥散投影支持度比较好，常规的弥散投影都有良好的表现，但Andriod对弥散投影的支持就不怎么好了，单纯靠代码很难写出柔和丝滑的投影，这就需要我们用点9图实现。一般不建议用PS制作点9图，在开发那里容易报错。建议使用专门生成点9的软件进行绘制，打开这个工具后，把图片拖进去，就可以进行绘制。左侧和顶部控制的是图像的可拉伸区域，右侧和底部控制的是内容的显示区域。

对于条状投影，比如Title Bar或者Tab Bar的投影，我们可以使用透明度渐变的方式去设计，开发也同样以渐变进行实现，这样可以得到各平台统一的实现效果。

         

PART 07

___

结语

前面介绍了设计师在评审、交付、响应、验收四大环节分别需要把握的关键点，同时结合大量的案例进行了说明。做好以上这些环节，高质量的设计还原自然水到渠成。

同时，优秀的设计离不开开发同事的落地支持，因此我们要多和开发同学沟通，让他们指导我们，学习他们的思维模式和开发方式，从而使我们感性的设计在交付时变得理性和可落地。

最后也是最重要的，不要忘记经常请你的开发小哥们奶茶和星爸爸，这是高还原度的奥秘之一！  

本篇文章来源于微信公众号: TripDesign