《Design Systems》系列翻译 16 计划性和可操作性 part2

 

写在前面------

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

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

 

Create A Culture of Knowledge Sharing
打造知识分享的文化。

 

As we saw in the example of Sipgate in the previous chapter, a team can have an up-to-date pattern library, but it won’t provide as much as value without effective cross-team collaboration. Getting your team to think in a more systematic way requires powerful knowledge-sharing practices. We discussed some of them in chapter 5, “Shared Language”:
正如我们在前一章的sipgate案例中所了解到的，一个团队可以拥有一个及时更新的模式库，但是如果没有有效的跨团队协作，则不能发挥全部的价值。让团队成员以更为系统化的方式思考需要强大的知识共享方面的实践。我们在第5章“共享语言”中讨论了其中一些问题：

 

•Set up a dedicated Slack channel to collaborate on defining and naming design patterns and to discuss system related questions.
·建立一个专门的Slack频道，用于共同定义和命名设计模式，并讨论与系统相关的问题。

 

•Create a pattern wall to make the process open and transparent to the rest of the company and encourage more people to join in.
·创建一个模式墙，使流程对公司其他部门开放和公开，并鼓励更多的人加入进来。

 

•Make introduction to the design system part of the induction process.
·将设计系统的介绍作为入门课程的一部分。

 

•Organize regular catch-ups to keep everyone on the same page as your system evolves.
·定期组织同步会，让每个人在随着设计系统的发展时仍保持在同一水平上。

 

•Encourage collaboration not only within individual teams but across teams and disciplines. In particular, encourage people who are more knowledgeable about the design system to work with everyone, so they have an opportunity to share their knowledge and enthusiasm with people who are less immersed in the system.
·不仅鼓励每个团队内部的相互协作，而且鼓励跨团队和学科之间的协作。特别是，鼓励更为了解设计系统的人与大家一起协作，这样他们就有机会给那些对于设计系统接触不多的人们分享他们的知识和热情。

 

•Organize workshops and tutorials to introduce the team to the changes as the system evolves. At FutureLearn, the most effective presentations had a “problem—solution” format. First, we talked people through current problems then explained how the changes we were proposing would help to solve the problem. For example: “Current typography means that text is too small on large screens and too large on small screens; reading experience is affected; it’s not clear which headings to use, and there are too many styles, which creates inconsistencies, and so on. Here’s how the new typography system solves these problems.”
·随着设计系统的不断演进，以组织讲习班和教程的形式介绍团队做出了哪些调整。在FutureLearn，最有效的演讲格式是 “问题点--解决方案”。首先，我们向人们讲述了当前的问题，然后解释了我们提出的改革将如何帮助解决问题。例如：“当前的文字版式意味着大屏幕上的文本太小，小屏幕上的文本太大；影响了阅读体验；不清楚应该使用哪种标题，样式太多，造成不一致的问题，等等。以下是新的文字版式是如何解决这些问题。“

•One of the guerilla tactics Vitaly Friedman and his team have been applying is dedicating each day to a component in the interface. They’d have a carousel day, a lightbox day, an accordion day, and so on. Everybody would receive a print-out highlighting the component and its variants, including front-end code and related styles.

·维塔利·弗里德曼(VitallyFriedman)和他的团队一直在采用的游击战术之一，就是每天针对于界面中的一个组件。他们会有旋转木马日，灯箱日，手风琴日等等。每个人都会收到一个打印文件，高亮标注组件及其变体，包括前端代码和相关样式。

 

 

“We put it next to the kitchen sink and in the bathroom. A month later, everybody remembers the naming of all the components, including the cleaning personnel!”
— Vitaly Friedman, editor-in-chief, Smashing Magazine

“我们把它放在厨房水槽旁边和浴室里。一个月后，每个人都记得所有组件的名称，包括清洁人员！“
-VitayFriedman，总编辑，Smashing杂志。

 

 

 

Keep Up the Team’s Morale
保持团队的士气。

Working on a design system is a long-term process. Your team might not see the rewards of what you’re doing for some time.
设计系统是一个长期的过程。你的团队可能某段时期内看不到正在做的事情的能够带来的回报。

 

“You don’t always get the personal satisfaction right away — the reward comes when you see other people using the module you created in their work, or when someone comments on how helpful the information was for them.”
— Jusna Begum, front-end developer, FutureLearn

你不一定总会立刻就能获得到个人认同感 – 回报时来自于当你看到其他人正在用你输出到组件应用到他的工作中，或者当有人评论说这些组件是如何的有帮助
-jusna begum，前端开发人员，FutureLearn。

 

There are a few things you can do to help keep up the team’s morale during the process.
在这个过程中，你可以做一些事情来保持团队的士气。

 

Rather than chipping away at an endless list of tasks, aim to complete the bulk of the work in one go, and then continue the rest as part of ongoing work. At Atlassian, initial progress was made through design spikes by two or three people. Matt Bond, a product designer who led the initial work on the Atlassian Design Guidelines (ADG), explained in one of his blog posts that having a two-phase approach allowed the team to get through the initial stages quickly and to then maintain momentum:

与其埋头完成没完没了的任务清单，不如一次完成大部分工作，然后把剩下的部分作为持续性工作的一部分。在亚特兰蒂斯，最初的进展是由两三个人的设计高手完成的。领导亚特兰蒂斯设计指南(Adg)初期工作的产品设计师马特邦德在他的一篇博客文章中解释说，采用两阶段的方法可以让团队快速通过初始阶段，然后保持动力：

 

 

“It was high output, getting many new patterns to 80% completion in a short amount of time. We’d then spend the next week or so dedicating small amounts of time to refine a pattern and get the guidelines and code up to scratch to include in the ADG.”⁶

他说：“这是在短时间内将许多新模式完成到80%的高产阶段。接下来的一周左右，我们将花费少量的时间来完善一个模式，并使指导规范和代码完善到可以加入在ADG中水平。

 

For some of the work, such as conducting an interface audit or setting up a pattern library, it’s useful to get the whole team (or representatives from multiple teams) involved, at least in the initial stages. Doing so provides a shared sense of ownership. If it’s not possible owing to other priorities, let a smaller group do the groundwork and involve others as needed. At FutureLearn, two of us (a designer and a front-end developer) spent a sprint fully focused on on the system, roping others in as required once we’d figured out how it should work.

对于像进行界面审计或设置模式库的工作，让整个团队(或来自多个团队的代表)参与进来是很有用的，至少在初始阶段是这样。这样做会产生一种集体的主人翁感。如果这件事优先级较低，那么可以让一小部分的人先做基础工作，并在必要时再让其他人参与进来。在FutureLearn，我们两个人(一个设计师和一个前端开发人员)针对系统做了一次迭代，一旦我们弄明白了应该如何执行时，就会立刻召集其他人员参与进来。

It also helps to plan the tasks in a way that affords the most benefit for the least effort. At FutureLearn, our goal was to make all the components living. This meant that the code for the modules on the website, and in the pattern library, would need to be the same. But achieving that involved refactoring every module. As we refactored them, we added them to the pattern library, one by one. It was a painfully slow process and the team started to lose motivation.
以一种以最少的努力提供最大的利益的方式来规划任务对团队来说也是有帮助的。在FutureLearn，我们的目标是使确保所有的组件保持最新状态。这意味着网站中构成组件的代码需要和模式库保持同步。但要实现这一点，就涉及到组件重构。当我们重构它们时，我们将它们逐一添加到模式库中。这是一个痛苦而缓慢的过程并且让团队开始丧失动力。

 

We then realized that we could provide value quicker by adding all the patterns in one go and displaying them as screenshots instead of code. This allowed the team to start using the pattern library for reference right away. In the following months we gradually replaced the screenshots with living modules, as we continued refactoring them. Had we not done that, it would probably have taken another year before all the patterns were documented.
然后我们意识到可以通过一次性添加所有模式并将它们显示为屏幕截图而不是代码的形式展示出来，会更快的体现价值。这需要团队立即开始使用模式库作为参考。在接下来的几个月中，随着我们继续对屏幕截图内容进行重构，我们逐渐用真实的模块替换截图。如果我们没有这样做，可能还需要一年的时间才能记录所有的模式。

 

Practice Thinking In Systems

 

练习系统性思考

One of our first experiments with modularity at FutureLearn was an attempt to redesign the home page. A visual designer created modular slices, and we then held a workshop where we tried to organize them into full comps. That’s what we thought (perhaps naively) a modular design process looked like.
我们在FutureLearn的第一个模块化实验是尝试重新设计主页。一名视觉设计师创建了模块切片，然后我们举办了一个研讨会，我们试图把它们组织成完整的页面。这就是我们认为(也许有些天真)模块化设计过程的样子。

 

                                             

One of our first experiments with modularity.
我们最早的模块化实验之一。

 

We ended up with three designs that eventually became fully functioning prototypes. But even though it was a useful exercise, the result wasn’t truly modular:

我们最终得到了三个功能齐全的原型设计方案。但是，即使这是一个有用的练习，其结果并不是真正模块化的：

 

•Modules didn’t have a clear purpose. The differences between them were mostly presentational.
·模块没有明确的目的。他们之间的差异主要是表象性的。

 

•We didn’t define and name them.
·我们没有给这些模块定义和命名。

•We didn’t put a lot of thought into how they would be reused.
·我们没有过多的考虑如何复用它们。

•Their role in the overall system was unclear.
·它们在整个系统中的作用尚不清楚。

 

The prototypes never made it into production. But it’s these type of experiments that helped make our design process more systematic. By trying different things we realized that modular design is much more than cutting up the interface and putting the pieces back together. If your team is new to this way thinking, it’s useful to first explore what modular means by experimenting on a side project or on a small area of your product first.

原型从未投入做成真实的产品。但这种尝试帮助我们的设计过程更加系统化。通过尝试不同的方式，我们意识到模块化设计不仅仅是界面分解再将各个部分重新组合在一起。如果您的团队刚刚开始这方面的探索，先通过在附属项目或产品的局部进行探索模块化的含义会更有帮助。

 

After trying out a few different approaches, we arrived at a more structured team exercise for systemizing an interface. The next two chapters describe this exercise in detail. In a nutshell, it will follow three steps:

在尝试了几种不同的方法之后，我们找到了一种以可操作的界面系统化团队练习方法，。接下来的两章详细描述了这个练习方法。简而言之，它将遵循三个步骤：

 

1.     Identify key behaviors or aesthetic qualities

1.识别关键行为或美学品质。

 

2.     Audit existing elements
2.评估现有要素。

 

3.     Define patterns

3.定义模式

 

The steps are slightly different for functional and perceptual patterns. With functional patterns, the focus will be on the user behaviors, on defining individual modules and naming them. We will look at perceptual patterns more as a whole, focusing on the feel and aesthetics, and on the general principles of how they work together. The order you do it is not critical. Some teams find it helpful to look first at the foundational styles, such as typography; others start with core functional modules. It is also possible to look at both simultaneously in parallel.这些步骤在功能模式和知觉模式上略有不同。功能模式重点将放在用户行为、定义单个模块并对其进行命名上。我们将更多地从整体上看知觉模式，重点是感觉和美学，以及它们如何协同工作的通用原则。你做这件事的顺序并不重要。一些团队认为首先查看基本样式(比如排版)是有帮助的；另一些团队则从核心功能模块开始。同时从这两种方向着手也是可行的。

 

In both cases, we consider the big picture first, and then deconstruct the interface into smaller parts. Approaching it this way helps us think not only of individual modules but also how they work together, and how they help to achieve the purpose of the product.
在这两者中，我们首先考虑全局，然后将界面解构成更小的部分。这样做不仅可以帮助我们思考单个模块，还可以帮助我们思考它们如何协同工作，以及它们如何帮助实现产品的目的。

 

—

1.From “And You Thought Buttons Were Easy?” by Nathan Curtis.
1.源自于内森·柯蒂斯(NathanCurtis)的“你认为扣子容易吗？”

 

2.http://smashed.by/designforgrowth
2.http：//smashed.by/Design for Growth。

 

 

3.See “Creating the Airbnb Design System” by Karri Saarinen.
3.参见Karri Saarinen的“创建Airbnb设计系统”。

 

4.See “Selling Design Systems” by Laura Elizabeth.
4.参见劳拉·伊丽莎白的“销售设计系统”。

 

 

5.For practical advice on creating design system roadmaps, see “Roadmaps for Design Systems” by Nathan Curtis.
5.有关创建设计系统路线图的实用建议，请参见NathanCurtis的“设计系统的路线图”。

 

 

6.See “How we made the Atlassian Design Guidelines” by Matt Bond.
6.参见马特·邦德的“我们如何制定亚特兰蒂斯设计准则”。