博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
如何构建设计系统
阅读量:2525 次
发布时间:2019-05-11

本文共 15701 字,大约阅读时间需要 52 分钟。

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 , and , I figured I’d share some of what I’ve learned along the way.

毫无疑问,我比其他任何人都被问到有关设计系统的问题。 因此,在过去几年的大部分时间里,我一直在思考如何为 , 和等产品设计,构建和展示设计系统,我认为我会分享自己在此过程中学到的一些知识。

什么是设计系统? (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 and 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套件已经不是什么秘密。 但是,除了将工具箱和样式指南放在一起之外,最近似乎越来越关注设计用于将整个产品结合在一起的系统。 和等正在建立内部团队,专门致力于设计系统。 人们开始意识到系统设计的重要性。 这是令人鼓舞的。 谁知道,也许有一天我们会拥有一个设计工具,但它不认为每次打开新文档都从头开始……?

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

我们需要分解事物,直到达到不可减少的最小值。 最基本的风格。 一个很好的起点是的完整列表。 这些属性大多数仅接受固定值,因此可以在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. to display various type scales. has open-sourced his implementation of the . I generally find the “Major Third” scale works well for most web products.

就像音乐中的音符一样,我们的类型应遵循音阶。 这有助于维持平稳的垂直节奏。 起初这听起来有些令人生畏,但幸运的是,多年来,一些非常聪明的人已经为我们弄清楚了这一切。 来显示各种类型的音阶。 已将他的实现开源。 我通常会发现“主要三等”量表对大多数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 . Elliot Dahl has written a and its benefits.

与类型一样,通过遵循间距比例尺,我们可以确保我们每个组件和布局都是统一的。 我最喜欢的间距标尺是 。 Elliot Dahl写了及其优点。

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 in his own article. After that, Jonathan Snook . 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.

让我们从一个简单的按钮组件开始,以说明如何仅使用样式调色板中预定义的样式来构造组件。

更多组件 (More components)

Again, these colours, font sizes, shadows and padding values are all plucked directly from the style palette we predefined above.

同样,这些颜色,字体大小,阴影和填充值都直接从我们上面预定义的样式调色板中提取。

让我们尝试一些更奇特的东西... (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 .

    让组件做自己的事。 不要试图在按钮,输入,标题或其他组件上添加边距。 在组件级别,您应该只定义在该组件的每个单个实例中看起来统一的样式。 由于页边距因情况而异,因此最好使用wrapper div来应用它们。 哈里•罗伯茨(Harry Roberts)写 。

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

我正在开发一个基于 CSS工具包,其中将包括本文中显示的所有组件以及更多其他组件。 该项目适用于我正在开发的产品 ,但是如果您有兴趣自己使用此UI工具包,请在告诉我。 如果我有足够的兴趣,我将其开源。

翻译自:

转载地址:http://gpgwd.baihongyu.com/

你可能感兴趣的文章
C#——winform
查看>>
CSS3 transform制作的漂亮的滚动式导航
查看>>
《小强升职记——时间管理故事书》读书笔记
查看>>
Alpha 冲刺(3/10)
查看>>
Kaldi中的Chain模型
查看>>
spring中的ResourceBundleMessageSource使用和测试示例
查看>>
css规范 - bem
查看>>
电梯调度程序的UI设计
查看>>
转自 zera php中extends和implements的区别
查看>>
Array.of使用实例
查看>>
【Luogu】P2498拯救小云公主(spfa)
查看>>
如何获取网站icon
查看>>
几种排序写法
查看>>
java 多线程的应用场景
查看>>
dell support
查看>>
转:Maven项目编译后classes文件中没有dao的xml文件以及没有resources中的配置文件的问题解决...
查看>>
MTK android 设置里 "关于手机" 信息参数修改
查看>>
单变量微积分笔记6——线性近似和二阶近似
查看>>
补几天前的读书笔记
查看>>
HDU 1829/POJ 2492 A Bug's Life
查看>>