写在前面------

因为工作内容的因素，最近这2年一直在探索如何打造一个高度灵活性的设计规范体系，在能够维持自身设计积累的基础之上，也能够配合项目需要快速的产出高质量的定制化交付件，偶然之间看到了这本书，看过之后感觉很有启发，就利用业余的时间翻译成中文，水平有限，还请大家多多指教。 

***********************************

Conduct an Interface Inventory

管理页面清单。

The interface inventory process⁴, described by Brad Frost, has become a popular way to start modularizing an interface. The idea is simple. You print out the screens of your interface on paper, or collect them in Keynote or PowerPoint. You then separate out various components either by cutting them out or pasting them in Keynote.

布拉德·弗罗斯特(BradFrost)描述的界面清单流程4已成为界面模块化的流行做法。这个想法很简单。将屏幕里的界面打印到纸上，或者将页面规整到keynote或者powerpoint里。然后，通过剪切或粘贴，将不同的组件分离出来。

An interface inventory showing some of the interactive elements.

展示了一些交互元素的界面清单。

You end up with a collection of parts which can be grouped into categories: navigation, forms, tabs, buttons, lists, and so on. Going through this process allows you to see duplicated patterns, and identify problem areas that need attention. This is when you discover that you have dozens of headers or pop-over menus, and start thinking about how to bring some order to all that.
您最终得到了一个部件集合，这些部件可以被分组到类别中：导航、表单、选项卡、按钮、列表等等。通过这个过程，您可以看到重复的模式，并确定需要注意的问题区域。当你发现你有一大堆标题或弹出菜单时，你将开始考虑如何让这些部件制定规则。

An inventory doesn’t have to encompass everything (although the very first one you do should be comprehensive). It can focus on one pattern group at a time, such as promotional modules, headers, or all the product display modules. You can do an inventory focused specifically on typography, or color, or animations.
一份清单不一定要包括所有的东西(尽管你做的第一份清单应该是全面的)。它可以一次聚焦在一个模式群组上，例如促销模块、标题或所有产品展示模块。你也可以特别为排版，或颜色，或动画整理一份清单。

To be most effective, interface inventories should be done regularly. Even if your team maintains a pattern library, new patterns will emerge that need to be folded into the system. If you get into a habit of running inventories every few months, each time shouldn’t take more than a couple of hours. And every time you do it, you understand your system better and can improve it.⁵
为了最有效，应定期进行界面盘点。即使您的团队在维护一个模式库，新的模式也会出现，并且需要归档到系统中。如果你养成了每隔几个月清点一次清单的习惯，每次都花不了几个小时。你这样做一次清单，都能更好地加深你对系统的理解，并能改进它。

View Patterns as Actions
将模式视为操作。

To understand the purpose of a pattern, try focusing on what it does rather than what you think it is. In other words, try to find an action that best describes the behavior a pattern is designed for. Describing a pattern with a verb rather than a noun can help you to broaden potential use cases for a pattern and define its purpose more accurately.
要理解模式的目的，试着关注它有什么作用，而不是你认为它是什么作用。换句话说，试着找到一个能最好地描述模式设计的行为的动作。使用动词而不是名词来描述模式可以帮助您扩展模式的潜在用例，并更准确地定义其用途。

Say you’ve introduced a simple module to promote an online course. If you try to describe what it is, you might refer to it as “Image header” or “Course banner.”
假设你已经引入了一个简单的模块来推广在线课程。如果您试图描述它是什么，您可以将其称为“图像标题”或“课程横幅”。

UI component promoting an online course on FutureLearn.

FutureLearn上的一个推广在线课程用户界面组件。

But by describing a pattern in this way, you could be making it too specific to its presentation or content. You might end up limiting its use to a particular context. On the other hand, if you define it in terms of actions — from your user’s perspective as well as your own — you can uncover its purpose: “Promote a course” and “Discover a course”; and “Get inspired to join a course” and “Encourage people to join.” By focusing on the action, you connect pattern with behavior and keep it open for various use cases. What else can this pattern promote? An online discussion? A new event? The name you give it should also reflect this. In the example above, we named the module “Billboard” to reflect its action-focused, promotional function.
但是，通过这种方式描述模式，您可能会使它过于特定于它的展现形式或内容。最后，您可能会将其使用限制在特定的环境中。另一方面，如果你从你的用户和你自己的角度来定义它，你可以发现它的目的：“推广一门课程”和“发现一门课程”；“被鼓舞着参加一门课”和“鼓励人们参加”。通过专注于操作，您可以将模式与行为联系起来，并将该模式应用到更多的用户案例之中。这种模式还能促进什么？在线讨论？新事件？你给它起的名字也应该体现这一点。在上面的示例中，我们将模块命名为“Billboard”，以反映其以行动为中心的促销功能。

Draw a Pattern’s Structure
绘出模块的结构。

To get a shared understanding of how a pattern works, draw its structure: the core types of content a module needs to be effective.
要对模式的工作方式有一个共同的理解，可以画出它的结构：模块需要有效的核心内容类型。

Designers, developers and content strategists can do it together when working on a new module, or when refactoring an existing one. Start by listing the core content elements a module needs to be effective. For example, you might agree that in your interface a promotional module like “Billboard” needs:
设计师、开发人员和内容策略师可以一起做开发新模块或重构现有模块。首先列出模块有效所需的核心内容元素。例如，您可能同意在您的界面中，类似于 “Billboard”这样的促销模块需要：

•a heading

标题

•a strong call to action

一个醒目的 CTA 按钮

•an eye-catching background (solid color or image)

吸引眼球的背景(纯色或图像)。

Next, try to determine the hierarchy of elements and decide how they should be grouped; for example: is the image part of the content? Is a label always necessary? While doing that, make a few sketches to visualize the structure. To give you an idea of what it might look like, here’s an example of the content structure for a course list item module on FutureLearn.
接下来，尝试确定元素的层次结构，并决定如何对它们进行分组；例如：图像是内容的一部分吗？标签总是必要的吗？在做这些事情的时候，可以画几张草图使结构更加一目了然。为了让你了解它可能是什么样子，这里有一个例子，FutureLearn中课程列表项目模块的内容结构。

Example of the content structure for a course list item on FutureLearn.
FutureLearn中课程列表项目模块的内容结构的示例。

At this point you might be thinking: “It’s just a sketch or a wireframe. I do that all the time anyway.” But it’s a bit different. This is a sketch focused specifically on the content structure of a module, and the hierarchy and grouping of the elements.
在这一点上，你可能会想：“这只是一个草图或线框图。反正我一直都是这么做的。“。但这有点不一样。这张草图重点在于关注模块的内容结构，以及元素的层次结构和分组。

Once you have a shared understanding of a pattern’s structure, it’s easier to make sure that the way  of  the module is designed is reflected in the markup. A designer can work on the visual explorations, while a developer can start putting together a prototype (or both can prototype, depending on how you work). Designers understand how much they can push a pattern visually before it becomes something different. Developers know the reasons for the design choices and don’t get unexpected designs thrown to them over the wall. Everyone is aware of how the pattern is constructed and how changing it will affect other places.

一旦你们对模式的结构有了共同的理解，就更容易确保模块的设计方式反映在标记中。设计师可以进行视觉探索，而开发人员可以开始构建原型(或者双方都可以产出原型，这取决于您的工作方式)。设计师们明白，在一个模式变得不同之前，他们可以在视觉上多大程度的调整。开发人员知道决定这么设计的原因并且不会再接到稀奇古怪的设计方案。每个人都知道模式是如何构建的，以及改变它将如何影响其他地方。

Here’s another example. On FutureLearn we used to have four different versions of a social feed in different areas of the site — two versions of “Comment,” a “Reply” and a “Notification.”
这是另一个例子。在FutureLearn上，我们曾经在网站中出现了四个不同版本的social feed --两个版本命名为 “评论”、一个“回复”和一个“通知”。

Four different versions of social feed modules on FutureLearn.
FutrueLearn中出现了四个不同版本的social feed

While at first glance they looked similar, they didn’t share the same styles; that is, if you changed one of them, the changes wouldn’t apply to others, there were visual inconsistencies in spacing and typography, and so on.
乍一看过去，它们都很相似，但它们没有相同的样式；也就是说，如果你改变其中一个样式，这些改变就不适用于其他样式，在间距和版式等方面存在视觉上的不一致。

Breaking them down and drawing their structures allowed us to see if they could be unified into one pattern, and to design that pattern in a way that works in all four use cases.⁶
将它们进行分解并绘制其结构使我们能够看到它们是否可以统一为一个模式，并且设计出能够适应于在四种场景中的模式。

The content structure for a “Feed item” module on FutureLearn.

FutureLearn上的“Feed item”模块的内容结构。

Content structure is closely linked to the purpose of a pattern, as these examples have shown. Knowing how a module is structured helps us understand how it works.
正如这些示例所示，内容结构与模式的目的密切相关的。了解模块的结构有助于我们理解它是如何工作的。

Place Patterns on a Scale

模式体系

Try placing similar patterns on a scale, in relation to one another. For example, there could be a few promotional patterns in your system, with varying degrees of intensity. Similar to the visual loudness scale⁷ I mentioned in chapter 1, promotional modules can be compared with one another.

试着把相似并且相互有关联的模式形成一个体系。例如，在您的系统中可能有一些不同强度的宣传模式。与我在第一章中提到的视觉响度体系7相似，宣传模块可以相互比较。

Promotional modules can be placed on an imaginary visual loudness scale.

宣传模块按照虚构的视觉响度体系归组。

Placing patterns on a scale can help make sure they’re used appropriately and don’t compete for attention across the system. It also helps prevent modules being recreated needlessly, since you can see when you already have a module at the same “volume.”

将模式归组上可以帮助确保它们得到适当的使用，并且不会在整个系统中争夺注意力。它还有助于防止不必要地重新创建模块，因为您可以发现你已经有了一个相同的“音量”的模块。

Another way to think about it is to imagine that your interface is not visual, but that it’s being read out by a voice. When would that voice need to get louder and change intonation? Think about how that volume and intonation can be expressed visually, through the relationships between the elements within the modules, as well as their hierarchy in the overall design. Thinking of it this way, of course, also has an additional advantage of making it more accessible to screen readers.

另一种思考方式是想象你的界面不是可视的，而是通过声音读出来的。这个声音什么时候需要变大并改变语调？考虑如何通过模块内元素之间的关系以及它们在总体设计中的层次结构，可视化地表达音量和语调。当然，这样想也有另外一个好处，那就是让屏幕前的读者更容易访问它。

Treat Content as a Hypothesis
把内容当作假设。

Here’s a paradox. We’re expected to design content-first, but at the same time we’re expected to build modules in a way that can fit any kind of content. A way to do this is not necessarily by starting with content, but with the purpose. Then we can treat content not as a known asset but as a hypothesis. This allows us to test if we’ve defined the purpose of the module well, and if the design works for that purpose.
这是一个悖论。我们被要求首先设计内容，但同时我们期望打造一个能够适应任何类型内容的方式模块。做到这一点的方法不一定是从内容开始，而是从目的开始。然后，我们就可以把内容当作一种假设而不是已知的资产。这需要我们测试我们是否已经很好地定义了模块的用途，以及设计是否为此目的而工作。

Suppose we have a module, which was designed for displaying product features.

假设我们有一个模块，是用于展示产品特性而设计的。

An example of a module designed for presenting product features.

一个用于展示产品特性而设计的模块的示例。

We could define its purpose as “Supporting the main message with additional bits of easily scannable information.” The “bits” could be key features, short pieces of advice, or quick steps. We can build a pattern for content that fits this hypothesis (concise and scannable, supplementary rather than the main content on the page), and then test it.
我们可以将其定义为“通过增加便于扫视的简短文案用以支持主消息”。“BITS”可以是关键特性、简短的建议或快捷步骤。我们可以为符合这一假设(简洁并且可扫视，是页面中的补充元素而不是主要内容)的内容建立一个模式，然后测试它。

If content consistently ends up being unsuitable for this pattern, it’s typically caused by one (or more) of these three reasons:
如果内容始终不适合这种模式，那么它通常是由以下三个原因中的一个(或多个)造成的：

•We didn’t correctly define the purpose of the pattern. Go back to trying to understand the behaviors it’s been designed for.
·我们没有正确定义模式的目的。退回理解这样设计行为的目的是什么。

•We didn’t design the pattern in a way that achieves its purpose best. Try a different design for this pattern.

·我们没有设计出能够最能达成目标的模式。尝试该模式的其他设计方案。

•We’re trying to force the content into a pattern that’s not quite right for it. Consider revising the content, or try another pattern.

·我们在强制将内容转换成一种不太适合它的模式。考虑修改内容，或者尝试其他模式。

When we don’t start with the purpose and the structure, we can end up with modules that are too closely tied to their content. For example, we had a case at FutureLearn where the copy was pushing important tabs below the visible area.
当我们不从目的和结构开始时，我们最终可能会得到与其内容太紧密相关的模块。例如，我们在FutureLearn的一个案例，其中一个方案是将重要的标签按钮放在可视区域的底部。

An example of a fragile module, which was too specific to its content.


一个脆弱模块的示例，该模块只能用在特定的内容场景。

The tabs were meant to stay visible. To get around the problem, we almost introduced a custom smaller size heading, simply to nudge the tabs up a bit. But had we done that, we would have ended up with a module that wasn’t robust. If the title got longer or if we added an extra line, we would have been stuck with the same problem. Had we started with the purpose of the module and its structure, the tabs would probably have been placed at the top, since they’re such an important element of design.
标签按钮是一致保持可见的。为了解决这个问题，我们引入了一个定制化的的较小规格的标题，只是为了把标签往上推一点。但是如果我们这样做了，我们就会得到一个不结实的模块。如果标题变得更长或如果我们新增一行文案，我们就会陷入同样的问题。如果我们从模块的用途和结构开始，标签可能会放在顶部，因为它们是设计的一个重要元素。

These are just some of the tools and techniques you can try to define functional patterns in your interface. The most important thing is to understand how patterns link to the behaviors they were originally designed for: their purpose.

你可以尝试通过一些工具和科技手段定义你所设计的页面中的功能模式。最重要的是要弄清楚连接功能模式与它们初始创造这个行为之间的纽带：它们的目的。

The purpose determines everything else that follows: the structure of the pattern, its content, its presentation. Knowing the purpose of the pattern (knowing which behaviors it’s designed to encourage or enable) can help us design and build more robust modules. It can help us know how much a pattern can be modified before it becomes something entirely different. And it can reduce duplication by giving the whole team a common point of reference, and connecting them with the original design intent. Being clear on the purpose also makes it easier to test the patterns to see how effective they really are.

目的决定了以下所有内容：功能模式的结构、内容、表现形式。了解功能模式的目的(知道设计它的初衷是旨在鼓励或启用哪些行为)可以帮助我们设计和构建更健壮的模块。它可以帮助我们在一个模式完全不同之前知道它可以被修改多少。它可以让整个团队一个共同的参照标准，并将他们与最初的设计意图联系起来，从而避免不必要的重复劳动。明确目标还可以更容易地测试功能模式，验证它们到底有多有效。

If functional patterns are objects in the interface, then perceptual patterns are more like styles — they describe what kind of objects they are and how they feel. Let’s take a closer look at them.

如果功能模式是界面中的对象，那么感知模式就更像样式--它们描述了它们是什么类型的对象以及它们传达出什么感觉。让我们进一步了解他们。

1.If we had to make a distinction between the two, I see functional patterns in a more generic way, as a kind of a Platonic ideal, and modules as the embodiment of functional patterns, which can be different in different interfaces.

1.如果要区分两者，我认为功能模式是一种像柏拉图式的通用方法，模块则是功能模式的具体体现，在不同的界面中，功能模式也会随之不同。

2.https://smashed.by/mappingxp

3.“Job to be done” (JTBD) is an exercise that helps you focus on the underlying motivation behind using a product or service, rather on the product itself. For example, even though customers say that they buy a lawnmower to “cut grass”, their higher purpose might be to “keep the grass low and beautiful at all times,” which might indicate that a lawnmower is not the right tool for the job in the first place.

3.“需要完成的任务”(JTBD)是一种练习，它帮助你专注于使用产品或服务背后的潜在动机，而不是产品本身。例如，即使顾客说他们买了一台割草机来“割草”，但他们更高的目的可能是“始终保持草的低和漂亮”，这可能表明割草机并不是最适合的工作工具。

4.https://smashed.by/uiinventory

5.In chapters 7 and 8 we will look at the interface inventory process in depth, starting from the purpose of the system and going down to the smallest patterns, such as icons and colors.

5.在第7章和第8章中，我们将深入研究界面清单的流程，从系统的目的开始，到最小的模式，例如图标和颜色。

6.In chapter 8 we’ll discuss in more detail when to unify patterns, when to split them up, and when to create variants.
6.在第8章中，我们将更详细地讨论何时统一模式、何时分割模式以及何时创建变体。

7.https://smashed.by/visualloudness