Design handover involves communicating the visual styles and behaviours of your design so they can be translated into code.

设计移交涉及传达设计的视觉样式和行为，以便可以将它们转换为代码。

Back in the Dark Ages of digital design, the only way to clearly define styles and spacings was through a process called redlining. This involved painstakingly adding markup on top of designs to show colours, fonts, widths, heights, spacings and more.

早在数字设计的黑暗时代，清楚定义样式和间距的唯一方法就是通过称为“涂红色”的过程。 这涉及在设计之上刻苦地添加标记以显示颜色，字体，宽度，高度，间距等。

The creation of the Sketch Measure plugin helped to somewhat streamline this process, but it still remains low on most designers’ lists of ‘Things I Enjoy Doing’, just below ‘watching paint dry’.

Sketch Measure插件的创建有助于在某种程度上简化此过程，但在大多数设计师的“我喜欢做的事情”列表中，仍在“观看油漆变干”之下，仍然很少。

Recently, a whole range of tools have been introduced promising to fully automate visual specs and free designers forever from the horrors of redlining. Tools like Zeplin, Invision Inspect, Google Gallery and many more allow you to upload your design files and share them with developers, who can inspect and extract the styles of every element.

最近，已经引入了一系列工具，有望完全自动化视觉规格，并永远使设计师摆脱繁琐的设计工作。 Zeplin ， Invision Inspect ， Google Gallery等工具可让您上载设计文件并与开发人员共享，开发人员可以检查和提取每个元素的样式。

Designers everywhere rejoiced as they waved goodbye to ever having to produce redlines again. But is it really that simple?

各地的设计师欢呼雀跃，告别曾经不得不再次制作红线。 但是真的那么简单吗？

Just like other forms of automation that are taking place, there are pros and cons to this new method.

就像正在发生的其他形式的自动化一样，这种新方法也有其优缺点。

✅正面：节省时间+显示所有信息 (✅ Positives: Saving time + showing all information)

The most obvious advantage to automatic speccing tools is the time saved by not having to create redlines.

自动定位工具最明显的优势是无需创建红线就可以节省时间。

All the styles and spacing information is already there. Developers can come in and easily find exactly the information that they need. What could possibly go wrong?

所有样式和间距信息已经存在。 开发人员可以进入并轻松准确地找到他们所需的信息。 可能出什么问题了？

❌负面：信息过多 (❌ Negative: Too much information)

By showing all styles we remove the ability to show which ones matter. For example, an element could be shown to be 50px wide — but is this a set width or does it take the width based on its contents? Does it have a maximum width?

通过展示各种款式我们会删除显示哪些重要的能力。 例如，一个元素可能显示为50像素宽-但这是一个设置的宽度还是它根据其内容取宽度？ 它有最大宽度吗？

Creating manual specs allows us to specify this, while purely automated specs leave it up to interpretation.

创建手动规格可以让我们指定这一点，而完全自动化的规格则需要解释。

Additionally, designs have to be consistently pixel perfect, or you could be asked questions like “Why is this line 50px on this screen, but 51px on the next?” 🤦‍♀️.

此外，设计必须始终如一地完美像素，否则您可能会被问到“为什么这条线在此屏幕上为50px，而下一行为51px？”这样的问题。 ♀‍♀️

Making every single screen pixel-perfect can be more time-consuming than just doing the visual specs manually.

与仅手动执行视觉规格相比，使每个屏幕的像素都完美无暇。

✅正面：风格指南和组件采用 (✅ Positive: Style guide and component adoption)

One area that these tools are really starting to shine in is documenting design tokens and components.

这些工具真正开始发挥作用的领域之一是记录设计标记和组件。

Instead of just displaying static styles and components in the code view, you can link them to your style guide or component library to encourage adoption.

您不仅可以在代码视图中显示静态样式和组件，还可以将它们链接到样式指南或组件库，以鼓励采用。

With design systems and atomic design becoming more commonplace, being able to integrate these into handover tools is a very powerful development in the design workflow.

随着设计系统和原子设计变得越来越普遍，能够将它们集成到切换工具中是设计工作流程中非常强大的开发。

Check out my earlier blog post for why using style guides and component libraries are so important for great handover:

查阅我以前的博客文章，了解为什么使用样式指南和组件库对于进行良好的切换如此重要：

❌负面：显示回应行为 (❌ Negative: Displaying responsive behaviour)

However, there are some things that automated handover tools can’t show. Most will display designs as static images on a fixed screen size, but this is rarely the reality. Communicating responsive behaviour is not widely supported across these tools, although some have made steps towards it.

但是，有些事情是自动切换工具无法显示的。 大多数将固定大小的屏幕上的设计显示为静态图像，但这很少是现实。 尽管这些工具已采取了一些措施，但在这些工具中并未广泛支持交流响应行为。

For example, Zeplin can show percentage width instead of pixels, and also has the ability to show the underlying layout grid. This is amazing if the developers are using similar tools to code the responsive behaviour. But if they are using different techniques, then we are left having to specify it manually or leave it up to guesswork.

例如，Zeplin可以显示百分比宽度而不是像素，并且还可以显示基础布局网格。 如果开发人员使用类似的工具来编写响应行为，这将是惊人的。 但是，如果他们使用不同的技术，那么我们就不得不手动指定它，或者让它来猜测。

For example, two of the responsive techniques I use the most are maximum/minimum widths and setting constraints/pinning.

例如，我使用最多的两种响应技术是最大/最小宽度和设置约束/固定。

Responsive design and development is a huge area with many different techniques. While we can automate handover for some of these techniques, others still rely on manual specs and explanation to make them clear.

响应式设计和开发是一个使用许多不同技术的广阔领域。 尽管我们可以为其中一些技术实现自动切换，但其他技术仍然依靠手动规格和说明来使它们清晰明了。

✅积极的：单一的真理来源 (✅ Positive: A single source of truth)

Most (if not all) of these tools work by creating a shared link that allows others to view the design online. This makes specs easy to share and keep up-to-date. This means there is a single source of truth and you don’t have to worry about multiple versions of the same spec document floating around 🙌

这些工具中的大多数(如果不是全部)都可以通过创建一个共享链接来工作，其他人可以在线查看设计。 这使规格易于共享并保持最新。 这意味着只有一个事实来源，您不必担心同一规范文档的多个版本会floating

I have found this to be hugely beneficial as I often end up making changes to specs following refinement sessions with developers. The cloud-based approach allows me to attach links to stories on Jira so that the up-to-date specs are always available.

我发现这非常有益，因为在与开发人员进行优化会议后，我经常最终对规格进行更改。 基于云的方法使我可以将链接附加到Jira上的故事，以便始终可以获取最新的规范。

❌负面：云存储 (❌ Negative: Cloud storage)

Depending on the company you’re designing for, there could be tight security procedures prohibiting the upload of work onto 3rd-party cloud services. This makes manual specs the only option for some cases. However, as adoption of cloud services becomes more commonplace and secure, the number of companies enforcing these rules is becoming very small.

根据您要设计的公司，可能会有严格的安全程序，禁止将工作上传到第三方云服务。 这使得手动规格在某些情况下是唯一的选择。 但是，随着采用云服务变得越来越普遍和安全，执行这些规则的公司数量也越来越少。

简介：混合规格 (Introducing: Hybrid specs)

Neither method is perfect, and it depends entirely on your individual project and workflow. I have found a mixture of manual and automated specs works best, when possible. I call them ‘hybrid specs’.

这两种方法都不是完美的，它完全取决于您的个人项目和工作流程。 我发现，在可能的情况下，手动和自动规格的混合效果最佳。 我称它们为“混合规格”。

I create my visual and behavioural specs, documenting responsive behaviours and important sizes and spacing. These are then uploaded to an automatic speccing tool so that developers can check text sizes, colours, and any other information that I didn’t specify.

我创建了视觉和行为规范，记录了响应行为以及重要的大小和间距。 然后将这些内容上载到自动指定工具，以便开发人员可以检查文本大小，颜色和我未指定的任何其他信息。

取得平衡 (Getting the balance right)

Automated handover tools can’t solve all your redlining problems. But they can cut down dramatically on the amount of time it takes to create a visual spec. They can also be a powerful tool for encouraging the adoption of shared styles and reusable components.

自动化的移交工具无法解决您所有的重新规划问题。 但是，它们可以大大减少创建视觉规格所需的时间。 它们也可以成为鼓励采用共享样式和可重用组件的强大工具。

However, we should careful not to rely on them too much. The goal of specifications is to specify — we want to avoid leaving things unclear or open to interpretation. We still need to separate the important information from the noise and communicate the parts of the design that can’t be conveyed through static images alone.

但是，我们应注意不要过多地依赖它们。 规范的目标是指定-我们希望避免使事情不清楚或易于解释。 我们仍然需要从噪声中分离出重要信息，并传达无法仅通过静态图像传达的设计部分。

The best thing about these tools is that they automate the more monotonous tasks, leaving you free to spend more time effectively communicating the more complex parts — instead of spending hours documenting every single text style and colour. 🎉

这些工具的最好之处在于，它们可以自动执行更单调的任务，使您可以自由地花费更多时间有效地沟通更复杂的部分-而不是花费大量时间来记录每种文本样式和颜色。 🎉