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. 🎉

這些工具的最好之處在于，它們可以自動執行更單調的任務，使您可以自由地花費更多時間有效地溝通更復雜的部分-而不是花費大量時間來記錄每種文本樣式和顏色。 🎉