作者│蒋琪

前言

UI设计师作为产品形态展示的执行层。视觉和交互还原是产品上线前的必要步骤。设计师可能遇到了一个问题。他们在绘制时多次为哪怕是一像素的分割线而苦苦挣扎，但开发后的结果并不理想，UI验收失败。然后前端就憋屈了，想拿出隐藏在键盘下面的40米长剑来和你战斗。 。 。

我们经常听到身边设计师和开发人员的对话，他们经常长时间讨论对齐、尺寸、间距等设计修复问题。有时候我什至觉得有必要这么纠结几个像素的间距？

1. 设计修复到底是什么？

“恢复”是指将事物恢复到原来的状态或形状。网络上的“设计修复”是指如果开发后的实际界面与设计稿有偏差，就必须对设计进行校对。

2、设计修复现状

长期以来，设计验收并未受到太多关注。首先，设计师习惯于把时间花在设计稿上，而忽略了后期的设计验收。二是对自己和一起工作的程序员要有极大的信心，相信对方能够理解你的所有观点，并且会完全遵循设计稿。

不同的项目类型，还原程度不同：用户产品>B端产品>后端。对于用户产品来说，最好能够实现像素级的还原。

三、设计修复的意义

在这个快速发展、迭代、更新的时代，互联网产品的用户体验变得越来越重要，产品设计还原成为工作流程的重要组成部分。

相信每个UI设计师心里都应该有一个梦想，就是前端能够100%还原设计稿。毕竟，这是我们努力的结果。

视觉修复的水平直接取决于设计-开发-测试的协作质量。它不仅影响线上产品的用户体验，也影响作为产品设计最后一步的工作质量。

经过采访UI/UX设计师、前端工程师、测试工程师还原设计图的工作场景，并深入探究原因，我们发现线上效果失真率其实涉及到设计、前端开发三个环节和测试。我们分析了造成这种现象的原因。原因大概有以下几个：

了解使用开发来恢复设计草案的规则。前期准备工作是重中之重。设置好每一个细节规则，后期修复时页面的畸变率会降到最低。

1.外观规格

在UI设计中，设计规范是设计还原的关键一步。一个好的规范应该是高效、简单且易于理解的。设计规范通常可以制定颜色、字体、组件等规范，不仅保证了视觉上的一致性，也极大的方便了样式和组件的复用，以及后期的维护和开发。借助规范，开发人员在构建全局共享控件时有更清晰的规则，例如按钮、行距、字体大小、颜色值等。

1.1 颜色规格

颜色是设计中最重要的元素。色彩的运用和搭配决定了设计的质量。在UI设计中，颜色使用的主要规范包括：主品牌颜色、文字颜色、界面颜色（背景颜色、线框颜色）等。

1.2 字体规范

文字是APP主要信息的表达，尤其是新闻阅读、社区APP等，建立标准的设计规范和良好的排版方法非常重要。让用户在使用APP时不感到疲劳很重要。不同的字体有不同的气质，在不同的场景下给人不同的感觉。因此，设计时需要考虑字体的设计效果，然后在设计规范中注明。主要规范标准字符的大小。标准字符应与上述标准颜色相结合，突出APP的重要信息，弱化次要信息。

1.3 图标规范

在UI界面中，具有标识属性的图形就是图标。图标作为UI设计中的一个重要的设计模块，可能存在于产品的每个页面上。

在设计规范中，图标根据用途一般分为两类：应用程序图标和功能图标。

图标还应该根据不同的功能需求设计不同的状态：比如正常状态、选中状态、点击状态等。

应用程序图标：各种应用程序的识别标志，是在应用商店下载的一些应用程序的标识。

功能图标：最好在规范中注明图标格式和用途。例如，在网页设计中，可以管理图像，可以生成代码并交付给前端开发；如果是原生APP，需要标注图标导出格式和大小。

1.4 图片规格

图片作为界面设计的重要组成部分，需要标注尺寸规格，并针对不同用途划分类型。

1.5 控制规范

控件是指产品界面中可操作的部分，与组件有些不同。控件被转换为 ，组件被转换为 .

流行的解释是组件由多个元素组成，而控件由单个元素组成。

常用的UI控件（）：按钮、输入框、下拉列表、下拉菜单、单选按钮、复选框、选项卡、搜索框、分页、切换按钮、步进器、进度条、角标记等。

1.5.1 按钮

按钮有 5 种状态：正常、单击、悬停、加载和禁用。这五种状态需要在规范中单独列出，并标注对应的按钮填充颜色、边框颜色、圆角值、按钮宽度和高度、按钮文字大小、颜色值。如果是图标按钮，除了上面的参数值外，还需要标注图标与按钮文字的间距，以及图标的大小。

1.5.2 输入框

用于在单行信息的上下显示文本，支持键盘输入和剪贴板输入，对特定格式的文本进行处理：密码隐藏显示、身份证和卡号分段显示、宽度标记和身高。

1.5.3 选择

选择可分为单选和多选，有五种不同的状态：未选中、选中、未选中悬停、选中无效、未选中无效项。所有效果状态都需要在规范中显示。

1.5.4 进度条

用于向用户显示步数和当前进度。

1.6 默认页面

2. 元件规格

常用的UI组件()：表格、对话框、提示栏、气泡提示、日期选择器、多级选择器、标签输入框、组合框、上传等。

如果 UI 忽略规范，前端很可能每次都必须手动编写代码，而不知道有可重用的组件。编写的代码越多，就越有可能错过细节并犯错误，从而导致效率降低。最关键的是，以后的迭代，前端还得逐页修改。

2.1 组件的好处

统一：

1）整个产品不同模块的业务按照统一规范使用，提高了整个产品视觉交互的统一性，减少了开发风格，提高了开发效率。

2）阻止设计者随意使用新的组件控制样式。

3）统一交互设计规则，减少用户困惑，提升产品体验。

效率：

1）一组组件可以帮助设计者简单地处理产品经理的初始需求。设计人员可以拖动组件搭建一个界面与产品经理讨论需求，确认并完善需求后，再进一步推进需求。节省时间，提高工作效率。

2）减少制作组件控件所花费的时间。无需重新定义组件，提高了设计效率，让更多的时间花在工艺体验和设计推广上。

连续性：

1）通过设计规范，可以在以后的更新中不断迭代，避免出现空白。

2）即使团队成员离开或加入，也可以通过设计规范和组件库快速接手并开展正常工作。

2.2 组件化的特点

多功能性：

说明它足够基础、足够通用，没有业务属性。参与设计的每个人都应该每时每刻都知道该组件的功能和用途，并且它必须是可扩展的。

灵活性：

要求组件的组合需要灵活，能够在不同场景下相互组合，快速构建交互框架原型，并根据不同页面结构的变化适应新的业务需求。

选修的：

这意味着它适用于多种业务或产品，并且在设计过程和研发过程中可以频繁转换。

2.3 元件分类

我们根据当前的业务场景以及对未来一段时间业务发展方向的规划，将组件库的组件类型分为通用组件和业务组件。通用业务组件库不对外开放，所以只能在Ant官网上看到通用组件部分。

2.3.1 常用组件

意味着应用范围广、扩展频率高、可复用于多种业务、不包含业务逻辑。某些导航栏、按钮、、弹窗等。我们将常用组件细分为五个小类：基本组件、导航、数据录入、数据显示、操作反馈。

2.3.2 业务组件

这类组件相比一般组件最大的特点是包含一系列的业务属性，这些属性与产品功能有重叠的关联性。因此，应用范围可能仅限于1到2个业务系统或者特殊场景，并进行复用。频率不高。毕竟使用场景特殊且有限，发布出来供参考意义不大。

2.3.3 基于组件的构建流程场景

组件化构建分两种场景进行：

1）组件化在产品项目建立之前就开始了。在产品达到0到1之前，它已经有一套组件和设计规范。设计人员可以直接应用和修改以前项目的组件库和设计规范，使项目的早期设计更加方便，省时、省力、挖坑。

2）产品经历了0到1之后，产品变得成熟，此时开始组件化。组件构建最多有六个步骤，分别是：类别梳理、场景评审、问题分析、方案设计、生成插件库、验证开发。

具体的组件化设计升级流程我总结如下：

团队构建成组件后，下一步就是在成员之间使用。这个流程包括业务需求生成组件模板、组件模板形成页面、页面形成页面流程、页面形成用户体验的流程。组件库在重构之初并不能完全全面，需要后续设计者不断维护和迭代。

3.详细注释

在设计输出方面，现在Blue Lake、Blue Lake等很多标注软件让设计师免去了手动标注的麻烦。他们通常只是将视觉草稿扔进蓝湖就完成了。前端开发后，界面的视觉还原度仍然不高。

因为标注软件只能负责生成元素的大小和样式，即使遇到复杂样式时重复测量一些像素，开发仍然会漏掉它们。这很可能会导致视觉灾难。

因此，我建议一些复杂、关键的页面可以手工仔细标记，并主动告知开发重要性和注意点。

我们当前的工作中有两种标注场景：

3.1.操作注释

因为从后台传输到前端的数据很多，包括图片、文字等，所以每个内容都需要设定一个上传标准来进行操作。

3.2 开发注解

开发注释是从设计稿到代码的主要参考。除了Blue Lake提供的注解之外，我们还需要编写一些重要的设计指令，比如模块差异化、局部特殊设计（这个内容根据自己的产品来确定）。

3.2.1 常规手工标注

3.2.2 特殊模块/页面划分说明

复杂表单设计是非常具有代表性的复杂页面。基于页面布局的原型示例可以帮助前端构建更好的代码框架。

4. 同步切图逻辑

关于切割图像，您应该在切割图像之前与开发人员确认输出格式和尺寸。确保使用 SVG、双倍图像或双倍图像。 SVG体积小，渲染质量好。使用单色时可以替换颜色。 PNG 通常用于现实生活中的图像，根据实际需要输出双倍图像。

如果我们要做分层动画，那么就会涉及到分层剪切。如果桌面端和移动端的风格差异较大，那么我们需要和开发者沟通如何实现，是否需要特殊裁剪，所有特殊裁剪都一致。对于特殊款式，要提前与开发团队沟通。

5.了解开发思维

设计和开发之间的协作质量对视觉修复起着决定性的重要影响。但由于我们的工作性质，我们和开发者之间的沟通是历史遗留下来的一个棘手而麻烦的问题。设计师和开发人员意见不合，导致视觉还原度低的情况几乎每天都在发生。

俗话说：“知己知彼，百战百胜”。如果设计师能够了解一些基本的开发术语和开发流程，就能更好地打破沟通鸿沟。

那么网页设计稿的实施具体是如何进行的呢？

步骤可概括如下：

5.1 设计师需要了解“盒子模型”的哪些内容

5.1.1 什么是盒模型

盒子模型在开发流程中被反复提及。虽然你不需要完全理解前端是如何通过代码实现你的设计稿的，但是你必须知道什么是“盒子模型”。

“盒子模型”是前端的基础知识。在“盒子模型”理论中，页面上的所有元素都可以被视为一个盒子，并占据一定的页面空间。

一个页面是由很多这样的盒子组成的，这些盒子会互相影响。因此，掌握盒子模型需要从两个方面进行理解：一是了解单个盒子的内部结构，二是了解多个盒子之间的关系。 。

5.1.2 盒模型的组成

每个元素被视为一个盒子，盒子模型由四个属性组成：（）、（）、（）和（）。另外，在盒模型中，还有两个辅助属性：宽度和高度。

举一个真实的界面例子，如果我们在浏览器中打开“开发者模式”，我们就可以通过“盒子模型”看到网页的样​​式代码以及当前界面是如何布局的。

前端不能像绘制UI那样简单地将可见元素拖放到某个位置。他们必须将每个元素放入一个“盒子”中，然后在界面中找到它的位置。

5.1.3 了解盒模型对于 UI 的好处

当你了解了前端是如何布局来实现你的设计稿之后，你就会开始明白在绘图过程中如何从实际的角度思考问题，善用“”，“box-ify”界面每个部分的布局。 ”。

让我举个例子。如果我们不使用“盒子”，当我们制作卡片时，前端并不知道UI是如何定义每个元素的间距的。例如，他然后将此间距应用于一个他不知道它应该有多高的“盒子”。

因此，UI在发布草稿时引入了“盒子模型”的思维，合理构思各个元素的布局。一方面可以帮助你在输出页面时有更合理的布局；另一方面可以辅助前端实现时准确还原。 。

优秀的设计离不开开发者的实现支持。作为设计师，与开发人员协作完成设计实现也是工作的重要组成部分。如果做好以下几件事，站在开发者的角度为它们“多想一步”，高质量的设计还原指日可待。

1. 设计呈现

在做设计修复的时候，希望大家多关注一下设计评审过程。之前我也详细讲过“如何进行设计评审”。因为我觉得评审对于设计修复的意义就是把问题摆到别人面前。通过设计审查，可以清楚地解释最大的视觉变化和修订的进展。这些布局框架的改变会增加开发工作量。如果掌握了这个环节，基本上是可以实现的，除非有特殊情况，比如一些前期被忽略的后台数据出现问题。

有一些细微的地方需要我们特别关注开发说明，加深印象，从而减少实施过程中的错误。例如，在开发审核时，我们只将关键的核心点和规则解释清楚。我们前面迈出的每一步都是为了未来。我们在检查修复程度的时候，应该放松一些，发展也应该放松一些。比如前期基础打不好，后期就很难深入。设计师做好会议记录（记录问题和解决方案，以及达成的共识），会议结束后通过邮件发送给前端团队，复制产品和运营，确保会议内容得到传达就位。让设计师和前端工程师就相关问题达成一致，提高工作效率。

在开发的紧张阶段，即使我们把前期的工作都准备好了，也很难避免开发人员不跟我沟通。这个时候我们就要积极的回应他们，和他们一起处理问题，比如一些比较困难的页面。开发实现的效果和设计稿的差别不小，所以这个时候开发者就会把他们的实现截图给大家看。这时候你就得仔细找问题了。不要坚持认为这是发展的原因。先沟通具体原因，再寻找解决方案。如果标注出现问题，比如标注被标记为死，页面不灵活，适配有很大的局限性。

2.视觉演练

在目视检查的过程中，我们可以将测试环境中的页面与设计稿进行比较。检查头部、尾部等位置是否完整统一，按钮样式、反馈状态、报错等样式是否统一；是否有缺失的场景和状态，根据任务流程检查场景和状态，保证设计的完整性。

这里向您推荐两种视觉演练方法：

1）我们来找出差异

验收时，我们需要对开发和实施效果进行截图，然后与设计稿进行对比。

我们可以直接把截图放在设计图上面，降低透明度，粗略对比一下就知道哪里出了问题，然后专门标记出需要修改的参数。

2）页面重构演练

检查恢复时，在浏览器空白处右键查看，找到里面的窗口。我们可以找到具体的文字、间距、投影等属性。有时为了一些更细微的调整，我们可以双击具体的值进行调整。调整到我们满意后，我们会给出具体的发展价值，这样我们在动摇的时候就不用给双方带来麻烦了。