by Colm Tuite

通過Colm Tuite

如何構建設計系統 (How to construct a design system)

設計和構建一致的設計系統的技巧。 (Tips for designing and building a consistent design system.)

Without doubt, I get asked about design systems more than anything else. So, having spent the majority of the past few years thinking about how to design, build and present design systems for products like Marvel, Bantam and Modulz, I figured I’d share some of what I’ve learned along the way.

毫無疑問，我比其他任何人都被問到有關設計系統的問題。因此，在過去幾年的大部分時間里，我一直在思考如何為Marvel ， Bantam和Modulz等產品設計，構建和展示設計系統，我認為我會分享自己在此過程中學到的一些知識。

什么是設計系統？ (What is a design system?)

It’s no secret that designers love a good UI kit. However, beyond just putting together toolkits and style guides, it seems that recently there’s been increasing focus placed on designing systems intended to tie whole products together. Companies like Shopify and Intercom are building in-house teams focused specifically on designing systems. People are starting to realise the importance of systemic design. This is encouraging. Who knows, maybe some day we’ll have a design tool that doesn’t assume we’re starting from scratch every time we open a new document…?

設計師喜歡一個好的UI套件已經不是什么秘密。但是，除了將工具箱和樣式指南放在一起之外，最近似乎越來越關注設計用于將整個產品結合在一起的系統。 Shopify和Intercom等公司正在建立內部團隊，專門致力于設計系統。人們開始意識到系統設計的重要性。這是令人鼓舞的。誰知道，也許有一天我們會擁有一個設計工具，但它不認為每次打開新文檔都從頭開始……？

A design system (as it pertains to tech products) is more than a framework, UI toolkit or component library. It’s more than a style guide or set of code guidelines. It’s even more than the sum of those parts. A design system is an evolving ruleset governing the composition of a product.

設計系統(與技術產品有關)不僅僅是框架，UI工具包或組件庫。它不只是樣式指南或一組代碼指南。它甚至超過了這些部分的總和。設計系統是控制產品組成的不斷發展的規則集。

There are many facets to any good design system — starting with company culture/mission and trickling all the way down to branding, copywriting, component libraries and other design language. The higher level points are arguably the most important aspects of any design system but for the purposes of this article, I’m going to assume that as a company — you know who you are, what your mission is and how your products should look, feel and function.

好的設計系統有很多方面-從公司文化/使命開始，一直到商標，文案寫作，組件庫和其他設計語言。更高級別的點可以說是任何設計系統中最重要的方面，但是出于本文的目的，我將假設一家公司-您知道自己是誰，您的任務是什么以及產品的外觀，感覺和功能。

Once you have those critical factors in place, you can convert that knowledge into a cohesive design language.

一旦具備了這些關鍵因素，就可以將這些知識轉換為一種具有凝聚力的設計語言。

設計樣式調色板 (Designing a style palette)

Before we can start designing shiny components, we need to lay the foundations for those components. We need to break the product down into its most bare-bones form.

在開始設計有光澤的組件之前，我們需要為這些組件奠定基礎。我們需要將產品分解為最簡陋的形式。

Even the simplest heading component is a collection of multiple reusable styles…

甚至最簡單的標題組件也是多種可重復使用樣式的集合……

We need to break things down until we reach the irreducible minimum; the most essential styles. A good place to start is the full list of CSS style properties. Most of these properties only accept fixed values and therefore can be reused on every website on the internet. The properties which accept custom values are ultimately what will differentiate our product from other products. These custom values are what will define our global style palette. Our global style palette is what we will use to design and build every single aspect of all of our products.

我們需要分解事物，直到達到不可減少的最小值。最基本的風格。一個很好的起點是CSS樣式屬性的完整列表。這些屬性大多數僅接受固定值，因此可以在Internet上的每個網站上重復使用。接受自定義值的屬性最終將使我們的產品與其他產品區分開。這些自定義值將定義我們的全局樣式調色板。我們將使用全球樣式調色板來設計和構建所有產品的每個方面。

When we’re finished, not a single style should exist in our product that has not been predefined in our global style palette.

完成后，我們的產品中不應存在尚未在全局樣式面板中預定義的樣式。

顏色 (Colour)

Let’s start with the most obvious style property — the only style property it seems modern design tools understand can be named, stored and reused: colour.

讓我們從最明顯的樣式屬性入手-現代設計工具似乎可以理解的唯一樣式屬性可以命名，存儲和重用：顏色。

For our primary brand colour, let’s choose blue. For our secondary brand colour, let’s go with its complementary counterpart: orange.

對于我們的主要品牌顏色，讓我們選擇藍色。對于我們的次要品牌顏色，讓我們選擇其互補色：橙色。

Utilising colour to communicate success and failure is a common design pattern, so let’s add green and red to our colour palette for that purpose. Colours like black and yellow might work well too.

利用顏色傳達成功和失敗是一種常見的設計模式，因此，我們為此目的將綠色和紅色添加到調色板中。黑色和黃色之類的顏色也可能很好用。

Lastly, we need some grey colours. Most UIs will need at least the following grey colours:

最后，我們需要一些灰色。大多數用戶界面將至少需要以下灰色：

A very light grey for backgrounds
背景非常淺的灰色
A slightly darker grey for borders, lines, strokes or dividers.
邊框，線條，筆觸或分隔線的深灰色。
A medium grey for subheadings and supporting body copy.
副標題和輔助正文的中灰色。
A dark grey for main headings, body copy and backgrounds.
主標題，正文和背景為深灰色。

Of course, you may need more greys. You might need three different shades for body copy. You might prefer two different stroke shades. That’s up to you. The point here is that you predefine whatever styles you need upfront so they are reusable throughout your entire product at a later stage.

當然，您可能需要更多的灰色。您可能需要三種不同的陰影來進行正文復制。您可能希望使用兩種不同的筆觸陰影。隨你(由你決定。這里的要點是，您可以預先定義所需的任何樣式，以便以后在整個產品中重用它們。

As a final touch, we may also want to add tint or shade variations for each of our colours. These can be useful when it comes to designing components for adding light backgrounds or dark strokes.

最后，我們可能還想為每種顏色添加色調或陰影變化。在設計用于添加淺色背景或深色筆觸的組件時，這些功能很有用。

Undertow (Shadows)

Shadows are another commonly used style property in most UIs. From what I’ve seen, a lot of designers just come up with shadows off-the-cuff while designing components. The same goes for most style properties actually. Designing in isolation like this often leads to inconsistent UIs.

陰影是大多數UI中另一個常用的樣式屬性。據我所知，許多設計師在設計組件時都會想到陰影。實際上，大多數樣式屬性也是如此。如此孤立地設計通常會導致UI不一致。

Let’s take a step back and consider what we’re trying to achieve with our shadows. We’re obviously trying to add some perspective to the UI but it’s likely that many components can benefit from the same effect. So let’s abstract the styles away from the individual components and into our global style palette.

讓我們退后一步，考慮我們試圖用陰影實現的目標。顯然，我們正在嘗試向UI添加一些視角，但是很可能許多組件可以從相同的效果中受益。因此，讓我們將樣式從單個組件抽象到全局樣式調色板中。

These four shadows should be enough to style every component in our system:

這四個陰影應該足以為系統中的每個組件設置樣式：

A subtle shadow to raise interactive components and add affordance.
一個微妙的陰影，以提高交互式組件并增加負擔能力。
A more pronounced shadow for a hover effect on components.
陰影更明顯，對組件具有懸停效果。
A strong shadow to give perspective to dropdowns/popovers and other similar components.
一個強大的陰影，可以透視下拉菜單/彈出窗口和其他類似組件。
A distant shadow for modal components.
模態組件的遠處陰影。

類型規模 (Type scale)

In order to create an appropriate visual hierarchy on each screen, we will need to define a number of different font sizes.

為了在每個屏幕上創建適當的視覺層次結構，我們將需要定義許多不同的字體大小。

Just like with notes in a piece of music, our type should adhere to a scale. This helps to sustain a smooth vertical rhythm. This can sound a bit daunting at first, but luckily, some very smart people have already figured it all out for us over the years. Tim Brown has built a great website to display various type scales. Adam Morse has open-sourced his implementation of the diatonic type scale. I generally find the “Major Third” scale works well for most web products.

就像音樂中的音符一樣，我們的類型應遵循音階。這有助于維持平穩的垂直節奏。起初這聽起來有些令人生畏，但幸運的是，多年來，一些非常聰明的人已經為我們弄清楚了這一切。蒂姆·布朗(Tim Brown)建立了一個不錯的網站來顯示各種類型的音階。亞當·莫爾斯(Adam Morse)已將他的全音階類型音階的實現開源。我通常會發現“主要三等”量表對大多數Web產品都適用。

The next step is to decide roughly which font sizes we will need, then plot them on our “Major Third” type scale.

下一步是大致確定我們將需要的字體大小，然后在“主要第三”字體比例上繪制它們。

Default (1em) for standard text that will appear in many places throughout our marketing site, UI etc. 16px is the default browser font size so let’s run with that.
標準文字的默認值(1em)，它將出現在我們的營銷網站，UI等的許多地方。16px是默認的瀏覽器字體大小，因此讓我們開始吧。
A slightly larger size for large body copy in a blog for example.
例如，在博客中用于大型正文的尺寸稍大。
A couple of larger sizes for headings and sub-headings.
標題和子標題有幾個較大的尺寸。
A very large size for section titles.
部分標題的尺寸很大。
A ridiculously large size maybe for prices on a pricing page for example.
例如，對于定價頁面上的價格而言，一個大得離譜的大小。
We will also need some smaller sizes for smaller body copy, input hints and other secondary text.
對于較小的正文，輸入提示和其他輔助文本，我們還將需要一些較小的尺寸。

邊界半徑 (Border radii)

Now it’s just a matter of applying the same process to every single style property that accepts custom values. For rounding corners, we will need the following corner radius values:

現在，只需對接受自定義值的每個樣式屬性應用相同的過程即可。對于圓角，我們將需要以下角半徑值：

Small border radius for tiny components like checkboxes, tags and labels.
小邊界半徑，適用于復選框，標簽和標簽等微小組件。
Medium border radius for buttons and inputs and similar components.
按鈕和輸入以及類似組件的中等邊框半徑。
Large border radius for cards, modals and other large components.
卡，模態和其他大型組件的大邊框半徑。

Note: We will also need a 50% border radius for building circular components like avatars etc.

注意：我們還將需要50％的邊界半徑，用于構建化身等圓形組件。

間距比例 (Spacing scale)

The most commonly used style property in almost any design is whitespace. Whether we’re spacing apart links in a header, spacing apart items in a grid, adding some distance between an avatar and a link or padding out a dropdown component — no whitespace in our product should be arbitrary or unintentional.

幾乎所有設計中最常用的樣式屬性是空白。無論我們是分隔標題中的鏈接，分隔網格中的項目，在化身和鏈接之間增加一定距離還是填充一個下拉組件，我們產品中的空格都不應該是任意的或無意的。

Like with type, by adhering to a spacing scale, we can ensure that each of our components and layouts will be uniform. My favourite go-to spacing scale is Material design’s 8dp grid. Elliot Dahl has written a great article about the 8pt grid system and its benefits.

與類型一樣，通過遵循間距比例尺，我們可以確保我們每個組件和布局都是統一的。我最喜歡的間距標尺是Material design的8dp網格。 Elliot Dahl寫了一篇很棒的文章，介紹了8pt網格系統及其優點。

Sticking to 8dp increments, we can plot out a number of spacing values that we can use to design every single component and layout in our suite of products.

堅持8dp的增量，我們可以繪制出許多間距值，這些間距值可用于設計產品套件中的每個組件和布局。

We can also use these spacing values to define a set of widths, heights and line-heights that we can reuse for sizing buttons, form inputs, avatars and other similar components. Since these components often appear alongside each other throughout web products, it helps if they follow the same sizing scale to avoid any unwanted discrepancies.

我們還可以使用這些間距值來定義一組寬度，高度和行高，我們可以重復使用這些寬度，高度和行高來調整按鈕，表單輸入，化身和其他類似組件的大小。由于這些組件通常在整個Web產品中并排出現，因此，如果它們遵循相同的大小比例，則可以避免任何不必要的差異，這將很有幫助。

字母間距 (Letter spacing)

As I mentioned earlier, font size is not the only style property that we need to define text components. Letter spacing is another useful property which we can use to tighten up large headings or allow smaller headings to breathe.

如前所述，字體大小并不是定義文本組件所需的唯一樣式屬性。字母間距是另一個有用的屬性，我們可以用來收緊大標題或讓小標題呼吸。

3 or 4 letter spacing values should do the trick.

3或4個字母間距值應該可以解決問題。

建立元件庫 (Building a component library)

Now that we’ve defined our global style palette, we can take those building blocks and start building out a component library. For the most part, designing components is not a creative process — we’re simply mapping predefined styles to components.

現在，我們已經定義了全局樣式調色板，我們可以使用這些構建塊并開始構建組件庫。在大多數情況下，設計組件并不是一個創造性的過程，我們只是將預定義樣式映射到組件。

At this stage, we shouldn’t need a single style that hasn’t already been defined in our style palette. The creative process happened during the style palette design phase. From this point on, whether it’s a colour, font size, margin/padding value, width/height or otherwise, every style we use to design our components and layouts should be plucked from our style palette. Almost nothing new should need to be introduced. That might sound extreme or unreasonable, but on the contrary, this is where I think a lot of people go astray.

在這個階段，我們不需要在樣式面板中尚未定義的單一樣式。創作過程發生在樣式調色板設計階段。從現在開始，無論是顏色，字體大小，邊距/填充值，寬度/高度還是其他，我們用于設計組件和布局的每種樣式都應從樣式調色板中選擇。幾乎不需要引入任何新內容。這聽起來可能是極端的或不合理的，但相反，我認為這是很多人誤入歧途的地方。

Dave Rupert ran this Twitter poll recently asking where to put code that overrides the styling on a button component, if that button is inside a modal component, for example.

戴夫·魯珀特(Dave Rupert)最近在Twitter上進行了一次民意調查，詢問在按鈕組件上放置覆蓋樣式的代碼的位置，例如，該按鈕是否位于模式組件內。

Harry Roberts (check out this awesome work) then explained his thoughts on this in his own article. After that, Jonathan Snook expanded with his own thoughts. While I agree with the conclusions both Harry and Jonathan came to, ultimately, I think the whole debate is just unnecessary.

哈里·羅伯茨(Harry Roberts)(查看這項出色的工作)然后在自己的文章中解釋了他對此的想法。在那之后，喬納森·斯努克有了自己的想法。雖然我同意哈利和喬納森的結論，但最終，我認為整個辯論是沒有必要的。

It’s contradictory to design a component with the intention of reusing it globally, then modify that component in just one specific part of the product. This defeats the purpose of creating a global component library in the first place. Whenever I see styles that override other styles, it’s usually either a case of hacking away at a component in order to make it fit in a tight space or tacking on a variation of a component because not enough planning went in during the earlier design stages.

設計組件以在全球范圍內重復使用，然后僅在產品的一個特定部分中修改該組件是矛盾的。首先，這違反了創建全局組件庫的目的。每當我看到覆蓋其他樣式的樣式時，通常要么是為了使組件適合狹小的空間而亂砍組件，要么是因為在早期的設計階段沒有進行足夠的規劃，便采用了組件的變體。

Every time you override a global component in one area of a product, you also erode the consistency of your design system. When you make enough sporadic modifications to components scattered across your product, you no longer have a consistent design system. You just have a design system with an inconsistent mess hanging out the arse of it.

每次在產品的一個區域中覆蓋全局組件時，都會破壞設計系統的一致性。當對分散在產品中的組件進行足夠的零星修改時，您將不再具有一致的設計系統。您只是擁有一個混亂的設計系統而已。

Let’s take a few common components and walk through how we can build them out using only the styles we have defined in our palette above.

讓我們來看一些常見的組件，并逐步介紹如何僅使用我們在上面的調色板中定義的樣式來構建它們。

不起眼的按鈕 (The humble button)

Let’s start with a simple button component to illustrate how it’s possible to construct components using only the styles we pre-defined in our style palette.

讓我們從一個簡單的按鈕組件開始，以說明如何僅使用樣式調色板中預定義的樣式來構造組件。

讓我們嘗試一些更奇特的東西... (Let’s try something a bit fancier…)

When we have a few components designed and built out, we can then start combining multiple components to create more complex components like this dropdown component.

當我們設計并構建了一些組件時，便可以開始組合多個組件以創建更復雜的組件，例如此下拉組件。

This dropdown component doesn’t use a single style outside of the basic style palette we defined earlier. Using this method, we can design an entire component library, then move on to broader layouts and finally onto full screens.

在我們之前定義的基本樣式調色板之外，此下拉組件不使用任何樣式。使用這種方法，我們可以設計一個完整的組件庫，然后移至更寬的布局，最后移至全屏。

道路提示 (Tips for the road)

Certain components will require values that are not defined in our style palette, for example, the width of a sidebar. Sometimes these values will be just 1/3 the viewport width or something similar. Other times, these values will be arbitrary and non-reusable and that’s perfectly fine. The point is to think about which styles should be reusable (most) and which styles shouldn’t.
某些組件將需要在我們的樣式面板中未定義的值，例如，邊欄的寬度。有時，這些值將只是視口寬度的1/3或類似值。在其他時候，這些值將是任意的并且不可重用，這完全可以。重點是要考慮哪些樣式(大多數)應該可重用，哪些樣式不應。
Let components do their thing. Don’t attempt to add margins to buttons, inputs, headings or other components. At the component level, you should only define the styles which appear uniform in every single instance of that component. Since margins differ on a case-by-case basis, it’s better to apply them using a wrapper div. Harry Roberts wrote an excellent article touching on this point.
讓組件做自己的事。不要試圖在按鈕，輸入，標題或其他組件上添加邊距。在組件級別，您應該只定義在該組件的每個單個實例中看起來統一的樣式。由于頁邊距因情況而異，因此最好使用wrapper div來應用它們。哈里?羅伯茨(Harry Roberts)寫了一篇關于這一點的精彩文章。

I’m working on a full-blown CSS toolkit based on Bantam CSS framework that will include all the components shown in this article plus many more. The project is for Modulz, a product I’m working on but if you’re interested in using this UI toolkit yourself, let me know on Twitter. If I get enough interest, I’ll open-source it.

我正在開發一個基于Bantam CSS框架的功能完善的 CSS工具包，其中將包括本文中顯示的所有組件以及更多其他組件。 該項目適用于我正在開發的產品Modulz ，但是如果您有興趣自己使用此UI工具包，請在Twitter上告訴我。 如果我有足夠的興趣，我將其開源。