Design specifications (specs) are guidelines that developers will use to implement a design. Think of an architect providing building blueprints to the construction team. Many designers think of specs as mindless zombie work. They may even recruit a spec monkey (or more junior designer) to do it for them so that they can get on with the ‘real’ design stuff.

設計規范(規格)是開發人員用來實施設計的指南。 想想一個為建筑團隊提供建筑藍圖的建筑師。 許多設計師認為規范是無意識的僵尸作品。 他們甚至可以招募專門的猴子(或更多的初級設計師)來為他們做，以便他們可以繼續“真正的”設計工作。

However, taking time and care to produce great specs can be fundamental to the success of your project.

但是，花一些時間和精力來制作出色的規格可能會 基本的 確保您的項目成功。

為什么好的規格很重要？ (Why are good specs important?)

Designs are implemented correctly ? 🤩If you fail to communicate your design properly, what gets built could have crucial differences from what you intended. A great design poorly communicated can easily turn into a clunky and frustrating user experience.

正確實施設計?🤩如果您無法正確傳達設計，則構建的內容可能與您的預期有重大差異。 溝通不暢的出色設計很容易變成笨拙而令人沮喪的用戶體驗。

Helps you to spot holes in your design 🔍 😬Going over your designs with a fine-toothed comb will inevitably help you spot errors and edge cases you would otherwise have missed.

幫助您發現設計中的Kong🔍with用細齒梳子梳理您的設計將不可避免地幫助您發現本來會錯過的錯誤和邊緣情況。

Saves time for everyone ? 🥳With good specs the development team have fewer unknowns, fewer bugs and fewer questions, because your specs will answer the questions for you.

節省每個人的時間🥳🥳憑借良好的規范，開發團隊的未知數，錯誤和問題更少，因為您的規范將為您解答問題。

Overall, great specs mean designs can be implemented quicker and to a higher quality. This is better for the team, the business and, ultimately, the users!

總體而言，出色的規格意味著設計可以更快，更高質量地實施。 這對于團隊，企業乃至最終用戶來說都是更好的選擇！

創建規格就是設計 (Creating specs is design)

A good way to create better specs is to approach it like any other design task.

創建更好規格的一個好方法是像處理其他任何設計任務一樣進行處理。

When we design, we research our users. We uncover their goals, their pain points and their workflows.

在設計時，我們會研究用戶。 我們揭示了他們的目標，痛點和工作流程。

Our approach to specs should be no different — we are creating a product for a user so should design it to best suit their needs.

我們的規范方法應該沒有什么不同-我們正在為用戶創建產品，因此應該設計出最適合他們需求的產品。

Talk to your developers — find out what their process looks like, what frameworks they are using, what can make their lives easier and what can drive them crazy.!

與您的開發人員交談-了解他們的過程是什么樣的，正在使用的框架，哪些可以使他們的生活變得更輕松以及哪些會使他們發瘋。

When you begin to understand your team’s mindset and workflows, you can start to align your specs to them.

當您開始了解團隊的思維方式和工作流程時，就可以開始根據其規范進行調整了。

從樣式指南開始 (Start with a style guide)

Style guides document the colours, text styles and other basic elements in your design. This is useful not just for ensuring consistency in your designs, but also for speeding up development and future spec work.

樣式指南記錄了設計中的顏色，文本樣式和其他基本元素。 這不僅對確保設計的一致性很有用，而且對加快開發和將來的規范工作也很有用。

Now, instead of having to write out the styles for every element, you can just reference them in your style guide.

現在，您不必為每個元素寫出樣式，只需在樣式指南中引用它們即可。

組件庫 (Component libraries)

As your design progresses you can expand your style guide to include more complex UI components. Here you could include things like buttons, form elements and modals. Anything you find yourself reusing multiple times in your design should be defined here and referenced externally.

隨著設計的進行，您可以擴展樣式指南以包括更復雜的UI組件。 在這里，您可以包括按鈕，表單元素和模態之類的東西。 您發現自己在設計中多次重復使用的任何內容都應在此處定義并在外部引用。

Now, instead of having to specify the styles and behaviour of a component every time, you can do it once and refer back to it.

現在，您不必一次指定組件的樣式和行為，而是只需執行一次并返回引用即可。

為什么這些有用？ (Why are these useful?)

The advantages of style guides and component libraries for the design workflow have been heavily documented. But did you know they are also a dream come true for developers?

樣式指南和組件庫在設計工作流程中的優勢已得到大量記錄。 但是您是否知道對于開發人員來說，這也是夢想成真？

A basic principle of good development is D.R.Y — Don’t Repeat Yourself. It states that:

良好發展的基本原則是干-不要重復自己。 它指出：

every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

每條知識都必須在系統中具有單一，明確，權威的表示形式。

This means that instead of repeating code in several places, you should write it once and refer back to it. Sound familiar?

這意味著您不必在多個位置重復代碼，而應編寫一次并返回參考。 聽起來有點熟？

This is exactly the mindset we are using when creating style guides and component libraries. By mirroring this workflow in your specs, you make it much more efficient to translate designs into DRY code — and your developers will love you.

這正是我們在創建樣式指南和組件庫時所使用的心態。 通過在您的規范中反映此工作流程，可以使將設計轉換為DRY代碼的效率大大提高-開發人員會愛上您。

視覺規格 (Visual Specs)

Visual specs document all the styles and spacings on your designs, to ensure that your beautiful designs actually look good when they’re translated into code.

視覺規格記錄了設計中的所有樣式和間距，以確保將漂亮的設計轉換為代碼后實際上看起來不錯。

手動與自動規格 (Manual vs. Automated Specs)

Recently, a whole range of tools have been introduced promising to fully automate visual specs.

最近，引入了一系列工具，有望完全自動化視覺規格。

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等工具可讓您上載設計文件并與開發人員共享，開發人員可以檢查和提取每個元素的樣式。

Just like other forms of automation, there are pros and cons to this method. Although they are a great way to save time, they only capture a static version of a screen. It’s likely that you will still need to do some kind of annotation to communicate interactive states and responsive behaviours.

就像其他形式的自動化一樣，此方法也有其優缺點。 盡管它們是節省時間的好方法，但它們只能捕獲屏幕的靜態版本。 您可能仍需要做某種注釋來傳達交互狀態和響應行為。

That’s why my preferred method of creating visual specs is a hybrid approach — use the automated tools as a back up to communicate simple styles, but add your own annotations to demonstrate behaviours and point out the more important visual elements.

這就是為什么我首選的創建視覺規格的方法是混合方法的原因-使用自動化工具作為備份來傳達簡單的樣式，但是添加自己的注釋來演示行為并指出更重要的視覺元素。

Find out more about the pros and cons of automated specs here:

在此處了解有關自動規范的優缺點的更多信息：

視覺規格：重要提示 (Visual Specs: Top Tips)

簡化，簡化，簡化 (Simplify, simplify, simplify)

When creating your visual specs, don’t try to display all information about a screen in one go. Chances are it will be completely overwhelming and difficult to read.

創建視覺規格時，請勿嘗試一次性顯示有關屏幕的所有信息。 很有可能會完全壓倒性且難以閱讀。

As designers, we’d never subject our users to a screen of cluttered, unorganised information, so why do we do it to developers?

作為設計師，我們永遠不會讓用戶看到混亂，雜亂無章的信息，那么為什么我們要對開發人員呢？

Instead, break the spec down into sections.

而是將規范分為幾部分。

For example, you could start by speccing the outer area of a screen:

例如，您可以先指定屏幕的外部區域：

And then move on to how the different components fit within that screen:

然后繼續介紹不同組件在該屏幕中的放置方式：

And finally, the inner styles of the component.

最后是組件的內部樣式。

If a component is particularly complex, break down the specs into several parts, for example:

如果組件特別復雜，則將規格分為幾部分，例如：

This will make the spec more digestable and there are less likely to be errors in implementation.

這將使規范更易于理解，并且在實施中不會出現錯誤。

Always ask yourself, “is this clear and easy to read?” If not, you probably need to simplify!

總是問自己：“這清晰易讀嗎？” 如果沒有，您可能需要簡化！

行為規范 (Behavioural Specs)

Behavioural specs are where you define the rules around how your design actually works.

行為規范是您定義設計實際工作方式的規則。

Sometimes we assume that a simple image is enough to communicate behaviour, but that’s rarely the case. Developers are not mind readers, and we should never assume that a user’s thought process is going to match our own.

有時我們假設一個簡單的圖像就足以傳達行為，但這種情況很少發生。 開發人員不是介意的讀者，我們永遠不應假定用戶的思維過程將與我們的思維過程相匹配。

Clearly defining your behavioural rules is the best way to ensure that your design actually works like you want it to.

明確定義行為規則是確保您的設計按預期實際工作的最佳方法。

Here are some ways to make sure your behavioural specs are clear to the person reading them:

以下是確保您的行為規范對閱讀它們的人清楚的一些方法：

設置上下文 (Set context)

Imagine picking up a book halfway through and trying to understand what’s going on. No one likes to be thrown into the details without understanding the wider context. It’s important to communicate the background and surrounding context of a design before getting too specific.

想象一下，半途拿起一本書，試圖了解正在發生的事情。 如果不了解更廣泛的背景，沒有人喜歡將其投入細節。 在變得過于具體之前，交流設計的背景和周圍環境非常重要。

Start your spec document with an overview of the feature. This could include user needs, site maps, user flows - anything that is useful in explaining the overall goal of this piece of work. You could also link to a walkthrough document or prototype if these resources exist.

從功能概述開始您的規格文檔。 這可能包括用戶需求，站點地圖，用戶流-有助于解釋此工作總體目標的任何內容。 如果存在這些資源，也可以鏈接到演練文檔或原型。

When developers understand the background to a design, they can make more informed decisions and recognise why certain choices were made.

當開發人員了解設計的背景時，他們可以做出更明智的決策，并了解為什么要做出某些選擇。

顯示和講述 (Show & Tell)

Combine descriptions of behaviour with examples of how it will look. It can be very difficult to get an idea across with just pictures or just images, but together they can communicate almost anything.

將行為描述與行為外觀示例結合起來。 僅通過圖片或圖像來傳達想法可能是非常困難的，但它們可以一起傳達幾乎所有內容。

Use simple, concise language. Give examples of things that are hard to explain. Ask yourself if you’d understand the behaviour described if you weren’t the one who had designed it.

使用簡單明了的語言。 舉例說明一些難以解釋的事情。 問問自己，如果您不是設計它的人，您是否會理解所描述的行為。

表格和圖表 (Tables & diagrams)

You don’t need to stick with annotated hi-fidelity mockups to get your behaviours across. Sometimes using simple tables or diagrams can be a better way of communicating, especially if it involves complex logic or a lot of steps.

您無需堅持使用帶注釋的高保真模型即可了解自己的行為。 有時使用簡單的表格或圖表可能是更好的通信方式，尤其是在涉及復雜的邏輯或很多步驟的情況下。

Combining traditional diagrams with wireframe versions of your screens can help link the abstract concepts and flows to how the real thing will look.

將傳統的圖表與屏幕的線框版本結合起來可以幫助將抽象的概念和流程鏈接到真實外觀。

組織 (Organisation)

So you’ve written your visual and behavioural specs. But if you just throw a gigantic document to your developers, there’s little chance they are going to read it or find what they’re looking for.

因此，您已經編寫了視覺和行為規范。 但是，如果您只是向開發人員扔了一個巨大的文檔，他們幾乎沒有機會閱讀或找到他們想要的東西。

This circles back to understanding the context of use — how and why are people going to read this? What is the user’s workflow?

這回過頭來了解使用的上下文-人們將如何以及為什么要閱讀此內容？ 用戶的工作流程是什么？

Most development teams will follow some form of agile process. They will usually break features down into individual stories, small enough for a single developer to tackle in a couple of days to two weeks.

大多數開發團隊將遵循某種形式的敏捷過程。 他們通常會將功能分解為單個故事，對于單個開發人員來說，足夠小，可以在幾天到兩周內解決。

Breaking your specs down in a similar way can help make sure that people only get the information they need, without all the extra stuff.

以類似的方式分解您的規格可以幫助確保人們僅獲得所需的信息，而沒有所有多余的東西。

Try to imagine what stories might be written in order to build this feature, and break your specs down to cover this. This might take some time to get used to how your particular team breaks down features.

嘗試想象可能會寫些什么故事來構建此功能，然后分解規格以涵蓋此內容。 這可能需要一些時間來適應您的特定團隊如何分解功能。

I organise my specs in Figma similar to the layout above. Each frame/artboard describes a story-sized slice of functionality. I can link to this frame straight from the corresponding story in Jira. It’s obvious what part of the spec relates to each story, and developers can also see the context surrounding that story in the other frames.

我在Figma中組織我的規格，類似于上面的布局。 每個框架/畫板都描述了一個故事大小的功能。 我可以直接從Jira中的相應故事鏈接到此框架。 很明顯，規范的哪一部分與每個故事有關，開發人員還可以在其他框架中看到圍繞該故事的上下文。

迭代和改善 (Iterate and improve)

It can sometimes take several iterations to perfect a spec. This may seem like a waste of time, but we’d never dream of pushing out the first design that we come up with to our users.

有時可能需要幾次迭代才能完善規格。 這似乎是在浪費時間，但是我們從來沒有夢想向用戶推出我們想到的第一個設計。

如何創建完美的規格？ (How to create the perfect spec?)

The key to good specs is the key to any good design: understanding and empathy.

好的規格的關鍵是任何好的設計的關鍵：理解和同理心。

Understand development workflows, principles and mindsets.

了解開發工作流程，原理和心態。

Empathise with your end user: would you understand this in their shoes? Would you want to read it?

同情您的最終用戶：您會在他們的鞋子中明白嗎？ 你想讀嗎？

進一步閱讀 (Further reading)