相信每个UI设计师都遇到过这样的情况：设计稿精美高端，但是开发还原效果直接从卖家秀变成买家秀。为什么总是遇到这样的情况，又该如何解决开发还原度低的问题呢？

接下来我将根据我多年的设计演练经验跟大家分享一套可以提高设计师与开发人员协作效率的方法。

第 01 部分___简介

为什么设计这么高端？

但修复了却认不出来？

首先我们来看一下，为什么每个UI设计师在成长过程中，都会遇到设计稿宏大，但还原后的设计却面目全非的情况。

作为UI设计师，我们的工作包括界面设计和后续修复两部分。对于大多数项目来说，后续修复其实占用的时间和设计差不多，但这部分时间并不包含在我们的时间估算中，这导致很多设计师没有足够的时间和精力去检查自己的设计。

另一方面，很多新晋设计师没有接受过系统、规范的设计评审培训，设计完成后直接将批注交给开发商，没有整理设计稿，也不知道如何验收，最终导致上线效果与设计稿相差巨大。

除了设计师个人原因（时间不够、经验不足）外，还有一些外部原因导致修复指标没有受到足够的重视。

一个产品验收项目组，一般由以下四种身份的人组成：其中，开发人员会专注于功能构建，因为他们的职责是避免出现 Bug；而说到还原，基本都是靠直觉，很多时候无法识别视觉稿的细节，而使用连接器、简化样式等简化的开发方式。

测试和产品也存在同样的问题，他们注重整体功能和流程，没有太多的精力和很高的视觉敏感度，所以修复的责任就默认落在了设计师的肩上。

视觉设计师作为产品最终形态的执行层，需要了解开发人员还原设计稿的规则，并在每一次设计稿交付时设定详细的规则，以保证上线的每一个产品都能100%还原。

举一个很常见的例子，当设计师在验收时发现新设计的模块看起来比视觉稿要小，他向开发人员询问原因，于是发生了以下对话：

显然，这种问题是可以避免的，只要我们提前向开发人员讲解适配规则，在设计稿中注明要采用的适配方式，开发人员在开发初期就可以考虑到适配问题。

提高修复效果的四个关键点

因此，了解在什么阶段、用什么方法去提高视觉还原就显得尤为重要。从产品需求确定到每个项目上线，有四个环节与高还原息息相关，分别是评审阶段、交付阶段、开发阶段、验收阶段。这四个阶段都有设计师需要关注和把握的重点。

首先，在阶段，我们需要向开发人员讲解设计重点、适配规则等，即使没有全部的设计稿，也需要向开发人员和测试人员表达思路。在交付阶段，设计稿必须仔细梳理，避免出现任何细节上的错误，直接导致开发人员按照错误的注解去创建样式，所以，整理注解是至关重要的一步。

到了开发阶段，即使我们做好了前期的所有准备工作，也很难避免开发人员不与我们沟通的情况，这时候就要积极响应他们，与他们一起解决问题。在最后的验收阶段，要与测试人员协作做好设计走查。

接下来对这四个阶段分别进行解释。

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

我们的项目大致可以分为展示型、工艺型、动效型、风格升级型，这四类项目在评审时各有侧重点，下面我们来分别进行了解一下。

展示

前端展示项目注重视觉表现，需要带着视觉稿来评审。除了准备整页效果图外，最好标注出设计重点，比如页面上滑时页头样式的变化，模块的不同状态等。如果评审阶段只提供默认的页面效果，会影响开发预估时间，导致这些效果和状态无法按时完成。

Web端相较于App端来说更加复杂sketch安卓图标模版，涉及到各种屏幕尺寸，因此布局方式、适配规则等需要设计师和开发人员在阶段共同商讨。

比如网站页眉图片的适配有很多种方式，是选择固定页眉高度，然后在指定高度内按比例拉伸图片，还是选择固定图片宽高，然后指定背景颜色，这些都需要在的时候和开发人员商量好，避免开发人员按照自己的习惯去适配，或者在验收的时候才发现不符合预期效果。

过程

展示型需要用视觉稿进行评审，流程型则侧重于流程和逻辑。评审时，开发人员最关注的是产品的主要流程。因此交互或产品需要先描述任务流程，一般以流程图的形式进行可视化讲解。在讲解产品流程后，交互同学需要讲解交互原型，具体讲解各个页面的功能和逻辑。

根据产品功能复杂程度不同，交互稿的呈现方式也有所不同，例如下图中的操作流程就采用了交互稿结合流程图的方式，让开发者更加直观的理解。

动画片

对于动效项目，开发者最关心的是动画的具体变化过程，例如动作之间的毫秒数。因此，在审核时最好提供动效demo以及动效说明。demo可以让开发者一眼看出动画过程，帮助开发者确定动效的开发形式。例如，简单的动效由开发代码实现，复杂的动效由设计师以Gif文件提供。

风格升级

除了以上三类项目，我们经常会遇到视觉升级项目。由于开发人员对视觉效果的敏感度较低，如果我们只提供新的设计稿，他们无法知道需要优化什么。有时一个看似简单的改动，可能需要改很多代码。

所以这类项目不能只是展示新的设计稿，而是需要将新旧版本放在一起对比，标注出新版本的具体变化，这样更容易评估开发时间。

第 03 部分___交付阶段

前面讲了开发评审阶段需要把握的重点，评审结束后就到了交付阶段，交付阶段需要以开发的思维去设计，整理、注释文档，才能更好的还原设计。

功能，

非常接近开发人员构建 UI 的方式

这个功能大家或多或少都用过，不仅提高了我们的设计效率，也非常贴近开发人员构建UI的方式。这里我们以信息流组件为例，介绍如何构建开发视图。

信息流组件服务于各个业务线的各种场景，不同的BU需要展现不同的卡片信息，因此信息流模板其实是由多个元素构成的，不同的场景由不同的元素进行组合组装。

下图左侧是信息流模板最完整的状态，也是中的设计视图。模板中每一行模块都是一个。你可以把它看成是一个外部容器，它决定了每个模块的高度，元素在模块中的位置由间距决定。例如标题文字的行高和底部间距构成了标题模块。

通过定义各个模块中元素及间距的值，可以确保信息流模板无论采用哪种组合，都会有良好的视觉效果。

对于开发者来说，这种设计方式也符合他们搭建 UI 的方式：即在真实的文本容器外面嵌套一个外部容器。实际的开发视图就是下图右侧的例子，还原出来的 UI 几乎和设计稿一模一样。

除了可以提高开发的还原度，用它来设计对于我们快速输出效果图也很有帮助。通过编辑叠加，可以生成不同的模块组合效果，如果需要修改样式，只需要调整一下，即可完成所有卡片的更新。最后通过一个模板，就可以在设计开发中适配各种业务类型和场景。

组织和注释文档

上面介绍的功能是引导设计师以开发的思维去设计，接下来我们来介绍一下如何组织我们的标注文档，首先是图标部分。

1. 图标

设计稿中同一套图标容器的尺寸一定要统一，这样方便开发者统一控件尺寸，设计师规范设计。由于每个图标的体积感不一样，所以图标与容器四周要留有间距。

在交付图标时，如果是单色图标，需要让开发人员使用字体文件，这样图标就可以以字体的形式存在，不会出现不清楚的问题。设计好的图标可以上传到公司网站，选择对应BU的图标库。

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

带阴影或者渐变的图标无法使用，需要提供给开发者进行裁剪，一般提交3倍裁剪即可覆盖主流机型，由于我们设计时使用的是750px（2倍画布），所以需要在裁剪选项中选择1.5倍。

对于一些小于 40px 的图标或者操作，可以在注释草稿中标记两个区域，告诉开发人员写两个视图，一个用于抠图或者样式，一个用于处理点击。

2. 文本

在完成图标之后，设计师需要对设计稿中的所有文字进行整理。这一步往往被很多设计师忽略。千万不要小看文字整理的重要性，它直接决定了开发的还原度。

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

为什么要定义线宽？一方面是为了让文字可以在限制宽度处换行或者截断，另一方面是定义文字与其他元素之间的间距。我们在交付时，标注稿中的文字应该设置限制线宽，避免开发自定义线宽。

我曾经遇到过这样的情况：因为没有标注最大线宽，开发人员直接把文字线宽拉伸到极限，导致验收时开发人员不得不重写。

接下来我们来看对界面还原影响比较大的行高，文字的行高会影响开发者对间距的测量，一般开发者不会特意写出行高，而是采用系统默认的行高。

如果视觉稿中标注的行高与默认行高相差较大，会给开发还原带来问题。由于字体型号较多，很难有一个统一的对比值，所以一般以iOS为基准。

图中是iOS系统字体大小对应的行高值，我们在写行高的时候一定要按照表格中的数值来。

为了让大家更直观的了解定义正确的行高对还原度的影响，这里给出了三组相同字体大小，不同行高值的对比，三组文字大小均为32px。

第一行是当我们不设置行高的时候，默认行高值为45，此时开发人员按照我们的标注写了两行间距11，还原出来的效果就是第二行文字比视觉稿高了。第二行是当我们设置字体行高为32的时候，此时两行文字间距为24，开发人员按照24写间距，还原出来的效果就变成了第二行文字明显低了。

第三行的效果是当我们设置了正确的行高也就是40的时候，实际的还原效果和视觉稿是一模一样的。

这里给大家推荐一款非常好用的插件，可以自动调整iOS系统中字体行高值，使用这款插件之后iOS开发中的字体行高可以100%恢复，具体下载安装及使用方法如下：

插件名称

自动修复 iOS 文本行

下载链接

安装

打开网页，点击code，选择zip，下载之后解压，找到后缀名为.的文件，双击安装，即可使用。

如何使用

选中需要调整的文本，点击插件即可自动改变行高。

3. 多行文本

单行文本使用 iOS 系统行距可以实现 100% 还原开发，但阅读用的多行文本如果使用默认行距，则很可能因为间距过小而造成阅读困难。这时候我们在设计好行高保证阅读舒适度之后，需要跟开发者强调这里的行高是需要额外设置的，否则开发者还是会使用系统行高，这样会影响显示效果。

iOS常见适配原则

前面已经介绍了交付阶段正确注解的重要性，现在说一下适配，很多设计师认为适配是开发人员的工作，不会在交付时特意提醒开发人员应该采用什么样的适配方式。

比较细心的开发者会问设计师不同屏幕的适配问题，而有些开发者会直接设置高度，这就会导致设计师在验收的时候发现大屏幕上的元素很小，这时候开发者就没有时间去写适配逻辑了，也就是我在开头提到的例子。有适配不同屏幕的能力，但是iOS却要求开发者自己写适配逻辑。

一般来说最常见的适配方式有两种：一种是固定高度自适应宽度，一种是等比宽高。比较常见的判断方式是，当页面没有图片，文字居多，比如表格时，可以使用固定高度的方式。当页面有图片时，需要使用等比宽高适配的方式，这样才能在大屏幕上协调图片和文字的比例。

举个例子，下面左图，开发者只是把图片放大了，所以在大屏幕上，文字会显得很小，与视觉效果不一致，所以在交付页面的时候需要告知开发者，让整个页面适配到一样的宽高。

有同学会问，是不是所有的设计都可以采用等宽等高呢？其实这要看具体的页面结构和功能，就拿下图右侧的整个站点首页为例，首页头部搜索和底部Tab Bar采用固定高度，其他模块采用等宽高自适应。

一方面是为了符合iOS的系统规范，iOS系统规范定义了Title Bar和Tab Bar在所有机型上都是固定高度的。另一方面，和固定高度后，大屏幕显示更多内容的优势也得以发挥。因此，设计师除了要符合系统规范外，还可以根据页面模块的具体功能来选择使用哪种适配方式。

等宽等高适配参数

等宽等高的具体适配参数是什么？有两种方式，一种是间距和元素都缩放，一种是固定间距，元素缩放。我推荐后者，即所有屏幕间距都固定，只缩放元素。这样做的好处是在大屏幕上，内容元素可以显示得更大。如果你的开发人员对适配参数不清楚，你可以给他发下面的规则参数。

原则：保持间距固定，仅缩放元素

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

另外，设计人员还需要注意的是，适配需要在项目开始的时候就告知开发人员，特别是流程项目，否则如果开发完成后再添加适配，开发人员就需要判断所有文字和图片的边界，这会大大增加工作量。

第 04 部分___响应阶段

完成交付之后，就到了开发阶段，在这个阶段我们需要积极回应开发人员提出的问题。

在开发过程中，即使我们把前期的工作都准备好了，也很难避免开发人员不和我们沟通，这时候我们要积极响应他们，和他们一起解决问题。对于一些比较难的页面，开发人员会把模拟器截图给我们看效果，这时候我们要细心找问题，不要一味的认为是开发人员的错。先沟通具体原因，再找解决方案。如果注释有问题，及时修改注释，并提醒开发人员刷新。

积极回应每一个发展问题

有时候我们会遇到一个问题，设计方案看似简单，其实开发起来非常困难，成本也很高。比如下图的商品卡片，设计方案是当价格和降价提示太长时，将直播按钮包裹起来。但开发人员很难判断两个字段总宽度和直播按钮的关系。这时候开发人员就会和设计师沟通，更改设计方案。

面对如此高的开发成本和风险，我们需要积极应对开发，共同探索替代方案，在开发成本和视觉效果之间找到平衡点。最终我们调整了方案，只要出现降价提示，直播按钮就会被包裹起来。

准备一个妥协方案

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

1.案例1

以“我谢”头像用户名为例，最初的设计方案是制定一个判断逻辑：当用户昵称小于9个字符时，昵称字体大小为40；而当用户昵称大于9个字符时，昵称字体大小为32。

虽然在交付时我们已经和开发人员沟通了设计思路，但由于时间关系还是没能做到这一点。所以我们提供了一个折中的方案：使用统一的36号字号，在保证大部分用户的视觉效果的同时，也兼顾了昵称较长用户的情况。在下个版本中，开发人员会将其优化为我们的最佳方案。

2. 案例 2

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

我们来看这个案例：《我心》新版本对表头做了换肤功能，我们的设计是，默认不换肤时，表头操作图标为黑色，当用户更换背景时，图标为白色，并在背景图片上叠加黑色蒙版，保证图标识别度。

但在实际开发过程中，这个判断非常困难，无论是iOS还是开发都无法在一个版本中完成这个功能。所以我们设计了一个折中的方案，即换肤后依然显示黑色图标，但背景用白色遮罩覆盖，以兼容所有颜色的换肤。虽然这不是最好的设计，但兼顾了视觉效果和开发成本。我们会在下一个版本开发中实现我们最好的方案。

第 05 部分___验收阶段

响应阶段结束后，就到了最终验收阶段，这个阶段我们需要和测试同事协作，进行设计走查。

什么时候开始接受？

在验收阶段，需要明确什么时候开始验收，怎么开始验收，按照两周一个版本，周四发布这个版本，周五做下一个版本的需求评审。

所以开发时间一般是周一到下周周五，测试的话前两三天写测试用例，周四周五测试，这是第一轮测试，如果测试结果没有大问题的话就会进行视觉验收，所以一般视觉验收时间是周一。

设计师接受第一波，提出视觉问题。周二、周三开始第二轮测试。与此同时，开发人员一边测试一边修改。周二、周三设计师进行第二次视觉验证。对于剩余的问题，需要根据实际情况评估是否需要修改。周三测试会再进行一轮常规功能验证。理论上不能留下任何 Bug。周四发布日，最终包验证正常。

如何接受？

检查和验收 Bug 的方法有很多种，取决于项目组的要求和开发人员的习惯。我一般会把问题点标注在截图上。有些开发人员要求把问题填写到 conf 中，这样项目组所有成员都能知道这个 Bug 是否已经修复。最原始最高效的方法是拿个小凳子坐在开发人员旁边，逐一调整。

PART 06___那些年我遇到的陷阱...

接下来我会介绍这些年来我遇到的坑以及一些典型的修复案例。

如何处理分界线

我们经常会遇到需要1px分割线的场景，但有时开发实现的效果比1px要粗，过粗的分割线缺乏精致感。我们在设计的时候，1px很容易实现，但对于开发者来说，各种手机的众多分辨率和平台让这个1px变得异常复杂。

1. 常见的分割线写法

目前有三种写分割线的方法，第一种方法是所有机型都使用1pt，这种方法最通用，但是在2x屏幕上分割线会变成2px，3x屏幕上就是3px，看上去不精致。

第二种方法，就是计算1px在不同放大倍数的屏幕上显示的实际pt值，比如2x屏幕上分割线显示为1/2，0.5pt，3x屏幕上分割线显示为1/3，0.33pt，此方法理论上在任何放大倍数的屏幕上都会产生1px的效果。

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

我通常建议使用第二种方法，这种方法已经实施了，没有任何问题。如果第二种方法效果不好，可以换用第一种方法，但记得把分割线的颜色调浅。

2. H5分割线的常见写法

H5分割线的写法有很多种，第一种方法是我合作过的开发者比较常用的：利用背景渐变，将分割线分成两部分，一部分透明，一部分分割线颜色，达到1px分割线的目的，但是这种方法的缺点是无法适配圆角。

3.RN分割线的常见写法

RN 中分割线的写法有两种常见的方式，第一种是将视图设置为绝对布局，保证分割线作为视图使用时不会出现问题。第二种是使用封装好的组件，这个常量始终是一个整数像素值，会让线看起来细如发丝，尽量满足当前平台最细线的标准，如果模拟器缩放的话，可能就看不到这么细的线了。

如何应对中风

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

影子实施

阴影是让设计师和开发者很头疼的问题，我们经常会发现阴影还原和视觉稿差别太大sketch安卓图标模版，iOS、RN、H5对阴影的写法和支持方式也有所不同，会造成实现效果和视觉稿的差异。

iOS 和 H5 对漫反射投影的支持都很好，常规的漫反射投影虽然表现不错，但是对漫反射投影的支持并不是很好，单纯通过代码很难写出柔和平滑的投影，所以需要使用 dot9 图来实现。

通常不建议在开发过程中使用PS创建9个图像，因为它可以使用专门设计的软件在打开此工具后，将图像拖入绘图。

对于诸如标题栏或标签栏预测之类的脱衣舞预测，我们可以使用透明度梯度进行设计，并且还可以通过梯度实施开发，以便在所有平台上都可以实现统一的实现效果。

零件07___判断

上一节介绍了设计师需要在审查，交付，响应和接受的四个主要链接中掌握的关键点，并且如果这些链接做得很好，也可以通过大量案例来解释它们，高质量的设计恢复自然就会自然出现。

同时，出色的设计不能与开发同事的实施支持分开。

最后但并非最不重要的一点是，不要忘记将您的开发伙伴挤奶和星巴克牛奶。

⭕️⭕️如何要求此问题的读者资源？

【1】回复“ ” - 获取 Cloud King File 库（ + Axure） + B端后端设计模板 +移动终端组件库 + Cloud Cloud UX UX测量工具模板。

【2】如何获得大量选定的UXD学习材料和设计模板：

⭕️⭕️加入内部推荐组和大型公司的设计交换集团，我们将不时分享下面的QR码，以添加编辑器，并在进入设计交流小组时注明“内部转介”。

与78695读者一起成长

UXD注释中的温暖提醒：由于修订了公共帐户消息推送机制，如果您不向我们添加⭐️星，则可能不会收到UXD Notes的大量封面推送，从而导致信息流中令人兴奋的内容。

为了防止迷路，我们邀请您做一个小动作，并在UXD Notes Notes Note 公共帐户中添加⭐️星，以便您可以从大型公司获得及时的UX知识推动。

如有侵权请联系删除！