《Design Systems》系列翻译 21 模式库 part1
一本关于如何打造属于动态设计语言指导手册
写在前面------
因为工作内容的因素，最近这3年一直在探索如何打造一个高度灵活性的设计规范体系，在能够维持自身设计积累的基础之上，也能够配合项目需要快速的产出高质量的定制化交付件，偶然之间看到了这本书，看过之后感觉很有启发，就利用业余的时间翻译成中文，水平有限，还请大家多多指教。
***********************************
Chapter 10
Pattern Libraries
模式库。
In this chapter we’ll look at some practical techniques to set up foundations for a long-lasting and multidisciplinary pattern library.
在本章中，我们将研究一些实用方法，以建立一个持久和多学科模式库的基础。
For some teams, a systematic approach to designing and building digital products is almost unthinkable without a pattern library. But as we’ve discussed throughout the book, a pattern library is not the system itself, it is a tool for documenting and sharing design patterns. To be effective, it needs a system foundation at its root. In chapter 7 we looked at some of the general strategies for establishing such foundation:
对于一些团队来说，在没有模式库的情况下，系统的设计和构建数字产品几乎是不可想象的。但是正如我们在整本书中所讨论的那样，模式库不是系统本身，它是记录和共享设计模式的工具。为了发挥作用，它的根源需要一个系统的基础。在第7章中，我们研究了建立这种基础的常用战略：
•Agree on the main goals and objectives, related to both the interfaces and how the teams operate, such as “Define and standardize reusable design patterns,” “Define guiding design principles,” “Establish a pattern library.”
·产品界面和团队如何运作的方式都与达成一致共识的主要目标和目的有关系，例如“定义和标准化可复用的设计模式”、“定义指导设计原则”、“建立模式库”。
•Break up objectives into manageable stories and create a simple roadmap for your system.
·将目标分解成可管理的故事，并为您的系统创建一个简单的路线图。
•Make your progress transparent by documenting and sharing it. For many teams, making their pattern library public made a huge difference to their progress and the team’s confidence in the work they were doing.
·通过记录和分享清晰的展示你的进展。对于许多团队来说，将他们的模式库公诸于众，对与团队的工作进展以及工作信心都产生了巨大的影响。
•Create a culture of knowledge sharing by making the design language visible and accessible to the whole team.
·创造一种分享知识的文化，使设计语言为整个团队所了解和使用。
•Practice thinking in systems through experiments, workshops and group exercises.
·通过实验、讲习班和小组练习的形式，锻炼系统化思考的能力。
In the experience of every team I spoke to, multidisciplinary pattern libraries are more resilient and enduring. They facilitate a shared language across the organization and bring value to everyone. Conversely, a pattern library built to serve the needs of one discipline is more fragile.1
根据与我每个交谈过的团队的经验，多学科模式库更有弹性，更持久。它们促进了整个组织的共享语言，并为每个人带来了价值。相反，为满足某一学科的需要而构建的模式库则更加脆弱。
The technical complexity of Sipgate’s first pattern library prevented designers being fully involved. Without the knowledge of what patterns existed in the system, they would sometimes create a page from scratch in Photoshop, where existing patterns could be used.
SIPGATE的第一个模式库的技术复杂性使得设计者无法充分参与其中。在不知道系统中都有什么模式的情况下，他们有时会通过在Photoshop将现有的页面修改的方式创建新页面。
“It was often left to developers to fit the design with the existing patterns, who had to tweak them until they fit. This led to numerous if-statements, exceptions and duplicate patterns.” — Mathias Wegener, front-end developer, Sipgate
“通常由开发人员将设计与现有的模式相匹配，开发人员必须对它们进行调整，直到它们适合为止。这导致了大量的if-语句、特例和分支的模式。“
-matias wegener，前端开发人员，sipgate。
Even though developers were determined to make a pattern library comprehensive and up to date, it was impossible without designers’ active involvement.
即使开发人员决心将模式库完善和更新，但没有设计师的积极参与是不可能实现的。
Similarly, patterns designed without the content discipline’s perspective can fall apart in everyday use. We end up designing patterns that are too closely tied to specific content, such as a module where an extra line of copy would push an important call to action below the visible area. Or we force content into patterns that aren’t designed for it, compromising both content and design.
同样，没有考虑以内容规则视角设计模式会在后续日常使用中崩溃掉。我们最终设计的模式与特定的内容太紧密地联系在一起，比如一个模块，其中额外的一行内容会将一个重要的操作推到可见区域之外。或者，我们将内容强制到不是为它设计的模式中，从而对内容和设计的模式都造成了影响。
In this chapter we’ll focus on establishing foundations for a pattern library that can support the goals of multiple disciplines.
在本章中，我们将着重于为能够支持多学科目标的模式库打造基础。
Content
内容
Looking back, at FutureLearn we spent far too much time researching tools and working out what the pattern library should look like. There wasn’t full agreement on how it should be designed and built, and the work progressed slowly. Switching our focus to the content of the library made a big difference — both to our progress, and the team’s morale.
回顾过去，在Futrurelearn，我们花了太多的时间研究工具，并想出模式库应该是什么样子。关于如何设计和建造它，没有达成充分的一致共识，并且工程进展缓慢。当我们把注意力转移到模式库的内容上的时候，团队的进步和士气都有很大的变化。
Going through the process described in the previous two chapters will give you a good grasp of what can go into your pattern library. It can be documented simply, using Google Docs2 or another collaborative writing app. There are two main benefits of this:
通过前面两章中描述的过程，可以帮助你很好地理解模式库中的内容。使用GoogleDocs 2或其他协作编写程序对其进行简单的文档记录。这有两个主要好处：
•First, everyone on the team can access the content to review, make edits and provide their feedback. By using a tool that’s familiar and easily accessible, you give more people an opportunity to be involved.
·首先，团队中的每个人都可以访问内容并进行审查、编辑和提供反馈。通过使用熟悉且易于访问的工具，您可以让更多的人参与进来。
•Second, a folder in Google Docs is like an MVP pattern library — the team can start using at as a reference right away. Once you have the content, it will be easier to figure out how the website for it should be designed and built.
·其次，GoogleDocs中的文件夹就像一个最小可行性的模式库--团队可以立即开始使用它作为参考。一旦你有了内容，它将更容易弄清楚如何基于它来设计和建设的网站。
Here’s how Andrew Couldwell at WeWork3 captured some of the patterns for the Plasma design system4 using Google Docs:
以下是WeWorks 3的AndrewCoulwell在做等离子设计系统4时如何使用Google Docs整理的模式截图：
Documenting patterns in Google Docs for the Plasma design system.
在GoogleDocs中记录的等离子设计系统中使用的模式。
The team was able to get down all the core patterns and their definitions quickly, instead of being held back by build and design constraints.
团队能够快速地获得所有核心模式及其定义，而不是被构建和设计约束所阻碍。
Organization Of Patterns
模式的组织方式
When documenting the content, the question will likely arise of how the patterns should be organized. The navigational structure is one of the things teams tend to struggle to agree on. Should buttons be separate or grouped with form elements? Where does the footer go? Should pagination be part of the navigation section?
在记录内容时，可能会出现模式应该如何组织的问题。目录结构往往是团队难以达成一致的事情之一。按钮应该独立出来还是应该和表单元素组合在一起？页脚应该放到哪里？分页应该是导航的一部分吗？
The structure doesn’t have to be perfect at the start — you can (and probably will) change it later. What’s important is that the team are on the same page. Having a common methodology to organizing patterns will make it easier to add and find things as your pattern library grows. The same thinking can apply not only to the pattern library, but front-end architecture and the design files.
结构不一定要在一开始就完美无缺--你可以(而且很可能)以后会改变它。重要的是，团队是在同一战线上的。有了组织模式的共识，随着模式库的增长，可以更容易地添加和查找东西。同样的思想不仅适用于模式库，也适用于前端架构和设计文件。
Let’s take a look at some of the common approaches.
让我们来看看一些常见的方法。
Abstracting Perceptual Patterns
抽离感知模式。
The simplest way to think about the structure is in terms of components and styles (functional and perceptual patterns). As we saw in the previous chapter, perceptual patterns are connected and work together. Abstracting them makes it easier to be aware of their role in the system. Here are a few examples of how perceptual and functional patterns are referred to.
最简单的方式结构是在组成和风格(功能和知觉模式)。正如我们在前一章中所看到的，感知模式是相互联系和共同作用的。对它们进行抽象使人们更容易意识到它们在系统中的作用。这里有几个例子，说明感知模式和功能模式如何关联的。
Pattern library |
Functional patterns |
Perceptual patterns |
Airbnb DLS |
Components |
Foundation |
Components |
Foundations |
Design Patterns |
Foundations |
|
Components |
Style |
|
UI components |
Design Elements |
|
Components |
Design |
|
Components |
Styles |
|
Components |
Design tokens |
|
Components |
Visuals |
There seems to be a general consensus to refer to functional patterns as “components,” but more diversity in terminology used for perceptual patterns.
人们似乎普遍认为，功能模式是“组成部分”，但用于感知模式的术语更加多样化。
Organizing Functional Patterns
功能模式的组织形式
While the number of styles is limited, the list of functional patterns can keep growing. The findability of modules is one of the greatest barriers to pattern library adoption. If team members don’t know that a pattern exists or can’t find what they need, they are likely to create a new one or go outside the pattern system.
虽然样式的数量是有限的，但功能模式的清单会继续增长。模块的可查找性是模式库能否被采用的最大障碍之一。如果团队成员不知道一个模式存在或者找不到他们需要的东西，他们很可能会创建一个新的模式或者跳出模式系统。
Teams organize modules alphabetically, hierarchically, by type (navigation, form elements, and so on), by purpose, or in entirely different ways.
团队按字母表、分级、类型(导航、表单元素等)、目的或完全不同的方式组织模块。
Alphabetical
字母顺序。
In IBM’s Carbon design system, Sky Toolkit13 and Lonely Planet’s Rizzo (among others) components are kept in one list and arranged alphabetically.
在IBM的碳设计系统中，SkyToolkit 13和LonelyPlanet的Rizzo(以及其他)组件都保存在一个列表中，并按字母顺序排列。
Most components are arranged alphabetically in Lonely Planet’s Rizzo (although navigation and form elements are in separate groups).
在Lonely Planet的Rizzo中，大多数组件按字母顺序排列 (尽管导航和表单元素在不同的组中)。
A single list makes decision-making easier — it avoids the debates about how things should be categorized. If the list grows and becomes unmanageable, teams start experimenting with other options to make components more discoverable.
单一的列表使决策变得更容易，它避免了应该如何分类的争论。如果列表增长并且变得无法管理，团队就开始尝试其他选项，以使组件更易于发现。
Hierarchical
分级。
Another way to classify functional patterns is in terms of their complexity. Some teams separate granular elements from more complex ones. The levels of granularity vary in number and perceived complexity.
另一种分类功能模式的方法是根据它们的复杂性进行分类。一些团队将单一元素与复杂的元素分开。并以数量和感知的复杂性划分颗粒度的级别。
Atomic design, pioneered by Brad Frost, is a popular example of hierarchical categorization. Atoms are the basic building blocks, which combine to create more complex standalone elements: molecules. For example, a form label, input and button combine into a search form. Molecules join together into organisms (such as a site header), and organisms into templates and pages.
由布拉德·弗罗斯特(BradFrost)开创的原子设计是分级目录的一个流行例子。原子是基本的构件，它们结合在一起形成更复杂的独立元素：分子。例如，表单标签、输入和按钮组合到搜索表单中。分子连接成生物体(如站点头)，生物连接到模板和页面中。
Components arranged hierarchically in Eurostar’s GLU14.
Eurostar的GLU 14中组件按分级排列。
As a methodology, atomic design can bring many benefits. Thinking of patterns as nested matryoshka dolls can help to reuse the elements, since you’re conscious of how the levels build on each other. Defining the rules for combining and encapsulating the patterns can promote consistency across the system. For the team at FutureLearn, the analogy with chemistry provided a shared point of reference when we were new to modular design thinking.
原子设计方法带来很多好处。将模式看作嵌套的俄罗斯套娃可以帮助复用这些元素，因为您明白了这些级别是如何相互构建的。定义组合和封装模式的规则可以促进整个系统的一致性。对于FutureLearn的团队来说，当我们刚接触到模块化设计思想时，用化学类比为我们提供了一个参照思路。
But it’s important to remember that atomic design (or any other methodology) might not be right for you right out of the box. At FutureLearn we struggled to find a use for “templates” and “pages.” The team preferred to work with smaller elements, so we could have greater flexibility over how they were combined.
但一定要记得，原子设计(或任何其他方法)可能不能完全套用到您的设计系统中。在“FutureLearn”中，我们很难找到“模板”和“页面”的用途。团队倾向于使用较小的元素，这样我们就可以在如何组合它们方面有更大的灵活性。
What’s more, we spent far too much time debating whether something was a molecule or an organism. Since the team didn’t see enough distinction between the two types, they were merged together. We ended up with two levels of hierarchy: atoms and molecules.
更重要的是，我们花了太多的时间来讨论某物是一个分子还是一个有机体。由于团队没有看到这两种类型之间的足够区别，因而他们被合并在一起。我们最终得到了两个层次：原子和分子。
More than two types of functional patterns can get confusing but separating granular elements from more complex ones makes sense — both in the pattern library and in the code. Teams do it to varying degrees, with or without following atomic design nomenclature.
两种以上的功能模式可能会产生混淆，但是将单一元素从更复杂的元素中分离出来是有意义的--无论是在模式库中还是在代码中。无论有无遵循原子设计的术语，团队都会或多或少的在做这方面的尝试。
Atoms |
Molecules |
Organisms |
Templates |
|
Elements |
Components |
- |
- |
|
Units |
Groups |
- |
- |
|
Basics |
Components |
Templates |
Features |
|
Elements |
Components |
Compositions |
- |
|
Components |
Patterns |
- |
- |
What I find interesting is that the strictness of a system (discussed in chapter 6) may be reflected in how the pattern library is structured. The more granular the patterns are, the more loose and flexible is the system. In a strict system, like Airbnb’s or GE’s Predix, the larger patterns are documented: user flows, templates and pages. In a system like TED’s or FutureLearn’s, you would document smaller parts and leave it up to the individual designers to combine them as they see fit.
我发现有趣的一个现象是，系统的严谨性(在第6章中讨论)可能反映在模式库的结构上。模式的颗粒度越高，系统就越松散和灵活。在像Airbnb或GE的Predix这样严谨的系统中，记录了更大的模式：用户流程，模板和页面。在像TED或FutureLearn这样的系统中，则记录较小的部分，并将由各个设计人员按照他们认为合适的方式进行后续组合。
By Purpose or Structure
按目的或结构。
At FutureLearn we never stopped experimenting with ways to organize modules: in one long list, hierarchically (following atomic design methodology), by compositional role on the page (“intros,” “outros,” “heroes,” and “bridges”). But everything was either too restricting, or too complex to work with.
在FutureLearn，我们从未停止尝试组织模块的方法：单级的长列表、分级 (遵循原子设计方法)、按页面上的扮演的角色(“开场”、“首场”、“英雄”和“桥梁”)。但是，每个方法要么太局限，要么过于复杂而无法协同。
After two years of trial and error we settled on classifying elements by purpose — promotional modules, modules focused on encouraging learner progress, modules around communication with the user, social modules, and so on.
经过两年的反复试验，我们确定了按目的对要素进行分类--推广模块、聚焦于鼓励学习者进步的模块、围绕与用户沟通的模块、社交模块等等。
Modules arranged by purpose in FutureLearn’s pattern library21.
在FutureLearn模式库21中按目的排列的模块。
Organizing patterns by purpose gives the team some guidance and inspiration for where to use a specific module. This structure also fit with our purpose-directed approach for defining patterns.
按目的组织模式给团队提供了一些指导和灵感，让他们知道在哪里使用特定的模块。这个结构也符合我们以目标为导向定义模式的方法。
In Shopify Polaris, components are also categorized based on the team’s mental models. The initial grouping was the outcome of an open card sort and usability testing. Even though there isn’t perfect alignment among different disciplines, the internal user research is continuously shaping how patterns are organized:
在Shopify Polaris ，组件也会根据团队的心理模型进行分类。最初的分组是卡片归类和可用性测试的结果。尽管不同学科之间没有完美的一致性，但内部用户研究正在不断地影响模式的组织方式：
“Designers tended to think in terms of structure. Developers tended to default to functionality. Content strategists tended to combine both. We’re conducting a range of usability studies to understand how well the grouping of components is working for people.”22 — Selene Hinkley, content strategist, Shopify Polaris
“设计师倾向于从结构的角度考虑问题。开发人员倾向于按照功能性划分。内容策略师倾向于将两者结合起来。我们正在进行一系列的可用性研究，以了解组件的分组是如何为人们工作的。“22
-SelenneHinkley，ShopifyPolaris内容策略师。
Components in Shopify Polaris are arranged by structure and function.
“北极星”中的组件是按结构和功能排列的。
These are just some of the ways teams organize patterns. What’s important is that the choice is grounded in how people who use it think. Find a structure that’s right for your team. If it doesn’t work, if people struggle to find what they’re looking for, continue experimenting with different approaches. This can take time. The phrase I hear the most from all the teams with effective patterns libraries is that their “work is never done.”
这些只是团队组织模式的一些方法。重要的是，选择是基于使用它的人的想法。找一个适合你团队的模式结构。如果它不起作用，如果人们正努力寻找他们想要的东西，继续尝试不同的方法。这可能需要时间。我从所有拥有有效模式库的团队中听到最多的一句话是，他们的“工作永无尽头”。
Pattern Documentation
模式说明文档。
Although many things can be documented alongside each pattern, trying to cover everything right away is not feasible, especially for smaller teams.
虽然在每个模式中都可以记录很多内容，但是一次性就将所有内容补充完整是不现实的，特别是对于较小的团队。
To see tangible benefits sooner, start with a lightweight overview of the main patterns. Once you have a simple foundation, you can improve the pattern library over time, by adding features and information the team needs. Here are some of the points to consider when documenting functional and perceptual patterns.
为了更快地看到实际的好处，首先要对主要模式进行轻量级的概述。一旦您有了一个简单的基础，您就可以通过添加团队所需的特性和信息来随时改进模式库。下面是在记录功能和感知模式时需要考虑的一些要点。
Documenting Functional Patterns
记录功能模式。
To make documentation focused and easily scannable, start with the basics:
要使文档明确且易于扫描，请从基本内容开始：
•name
名字
•purpose
目的
•example (visual and code)
案例（视觉样式和代码）
•variants
·变体
Name
名字
Throughout the book I’ve tried to emphasize the importance of a well-chosen name. A good name is focused and memorable, and embodies the purpose of the pattern. Ideally, someone should be able to glean the purpose from the name, without needing to read the description. To help make the page more scannable, names should be prominent and stand out from the rest of the content.
在整本书中，我一直试图强调一个精心挑选的名字的重要性。一个好的名字是有聚焦和易记忆，并体现了模式的目的。理想情况下，某人应该不需要阅读描述酒能够从名字中明白其目的。为了使页面更具有可扫描性，名称应该是突出的，并且从其他内容中脱颖而出。
Each pattern’s name is prominently displayed in IBM’s Carbon.
每个模式的名称都显着地显示在IBM的碳设计系统中。
Purpose
目的
When browsing a pattern library, most people skip descriptions, especially long ones. That’s why they should be focused and to the point: typically, one or two sentences explaining what a pattern is and what it’s for is enough. Although this seems like a simple task, in practice capturing the purpose of a pattern concisely and accurately is not easy. Too often we come up with vague descriptions that don’t have a lot of practical value.
当浏览模式库时，大多数人跳过描述，特别是长描述。这就是为什么他们应该集中精力和重点：通常，一两句话解释一个模式是什么，它是什么就足够了。虽然这看起来是一项简单的任务，但在实践中简洁而准确地捕获模式的目的并不容易。我们经常提出模糊的描述，没有太多的实用价值。
Take a look at how the team at Sipgate initially described a component called “Showcase”:
看看Sipgate团队最初如何描述一个名为“Showcase”的组件：
“Use Showcase to present multiple types of information with a media file.”
“使用Showcase展示带有媒体文件的多类型信息。”
Even though factually correct, it doesn’t communicate the purpose of “Showcase”, which makes it more likely to be misused or duplicated. Later, the team adopted a new practice for defining a pattern’s purpose, and writing descriptions. Here’s how it was applied to another example:
尽管事实是正确的，它并没有传达“展示”的目的，这使得它更有可能被误用或重复。后来，团队采用了一种新的尝试来定义模式的目的，并编写描述。下面是如何将其应用于另一个示例：
“Fact Grid is a shortlist of facts or bits of interesting information. Use Fact Grid to give the reader an immediate impression about the upcoming content.”
“真相网格是真相或有趣信息的短列表。使用真相网格让读者对即将到来的内容有一个直接的印象。“。
This second description is much more effective at communicating what the pattern is for. You might even be able visualize the “Fact Grid” just by reading these two sentences.
第二个描述在传达模式的目的方面要有效得多。您甚至可以通过阅读这两个句子来可视化“真相网格”。
Additionally, there are design and content recommendations for making the pattern achieve its purpose in the most effective ways, such as “Maximum of 3 lines per fact” or “Maximum of 12 facts.” Collaborating with a content discipline can be invaluable for defining these rules.
此外，还有一些设计和内容建议，以使模式以最有效的方式实现其目的，例如“每个真相最多3行”或“最多12个真相”。定义规则的同时定义内容的原则是非常有价值的。
Fact Grid in Sipgate’s pattern library23.
在Sipgate的模式库中的真相网格23。
![Amazon亚马逊 I 主图A+ [合集]](https://img.zcool.cn/community/6a38dcce3687ayo427oj4f8979.png?k=3e3252ae8478be33fb4a58c54147c367&t=6a662f00&x-oss-process=image/resize,m_fill,w_520,h_390,limit_1/auto-orient,1/sharpen,100/quality,q_80)
