苹果设计组件库_建立设计系统和组件库

苹果设计组件库

This post is based on the series of posts: Modernizing a jQuery frontend with React. If you want to get a better overview of the motivation for this post we recommend you first read our initial post.

这篇文章基于以下系列文章： 使用React使jQuery前端现代化 。 如果您想更好地了解本文的动机，建议您先阅读我们的初始文章 。

When we started rebuilding our frontend in React it wasn’t yet part of our design and development workflow to think about reusable UI components. Our jQuery frontend was built mainly out of Twitter bootstrap components, which were adapted for specific use cases or extended with additional functionality. New designs were created for each new feature by copying some design elements from older designs and improving or adapting them there. As the team and the application kept growing, our components evolved in multiple directions. This resulted in multiple variants of text sizes, colors, buttons and links which led to a disjointed user experience across our application.

当我们开始在React中重建前端时，考虑可重用的UI组件还不是我们设计和开发工作流程的一部分。 我们的jQuery前端主要由Twitter引导程序组件构建而成，这些组件适用于特定的用例或具有其他功能进行了扩展。 通过复制旧设计中的某些设计元素并在那里进行改进或修改，为每个新功能创建了新设计。 随着团队和应用程序的不断发展，我们的组件向多个方向发展。 这导致了文本大小，颜色，按钮和链接的多种变体，从而导致整个应用程序的用户体验脱节。

Rebuilding our frontend in React was an opportunity for us to rethink our design and development workflow and focus on a more cohesive experience for the user. This was especially important since we knew we needed to make our app more accessible and responsive. This led to the creation of a component library which motivated the need for a design system. That process was difficult and slow at first but became exciting and useful over time.

在React中重建前端是我们重新思考我们的设计和开发工作流程并专注于为用户提供更具凝聚力的体验的机会。 这一点特别重要，因为我们知道我们需要使我们的应用程序更易于访问和响应。 这导致了组件库的创建，从而激发了对设计系统的需求。 这个过程起初既困难又缓慢，但随着时间的流逝变得令人兴奋和有用。

什么是设计系统？ (What is a design system?)

A design system is a comprehensive guide on how to create, document and use UI components. It defines a collection of rules, constraints, principles and best practices that apply to all designs. The core element of a design system is a collection of UI components, such as buttons, links and tables. For each designed component you can have usage guidelines that document choices made during design, the rules that define the component, behavior and constraints, use cases and any other details that are easy to communicate through words.

设计系统是有关如何创建，记录和使用UI组件的综合指南。 它定义了适用于所有设计的规则，约束，原则和最佳实践的集合。 设计系统的核心元素是UI组件的集合，例如按钮，链接和表格。 对于每个设计的组件，您都可以使用使用指南来记录设计期间的选择，定义组件的规则，行为和约束，用例以及易于通过文字进行交流的任何其他详细信息。

什么是组件库？ (What is a component library?)

A component library is a collection of reusable UI components implemented in a programming language. When supported by a design system it can also be seen as an interactive implementation of the designs and their guidelines.

组件库是用编程语言实现的可重用UI组件的集合。 当得到设计系统的支持时，它也可以看作是设计及其指导的交互式实现。

你为什么要在乎呢？ (Why should you care?)

As Airbnb’s Karri Saarinen stated: “A unified design system is essential to building better and faster; better because a cohesive experience is more easily understood by our users, and faster because it gives us a common language to work with”.

正如Airbnb的Karri Saarinen所说：“统一的设计系统对于更好，更快地建造至关重要。 更好，因为凝聚力的体验更容易为我们的用户所理解，而更快，因为它为我们提供了共同的语言来使用。”

At Karify, it helps us to create and follow our own constraints. It helps us to create a cohesive user experience on a multitude of platforms and devices. And finally, it helps our team work smarter, faster and closer together. These are some of the advantages we found in more detail:

在Karify，它可以帮助我们创建并遵循自己的约束。 它有助于我们在众多平台和设备上创造凝聚力的用户体验。 最后，它可以帮助我们的团队更聪明，更快，更紧密地合作。 这些是我们更详细地发现的一些优点：

• Communication: designers understand developers and vice-versa. Concepts that were previously difficult to understand for both sides are now much clearer. Talking about components and using the rules we defined in communication make the process of designing and developing much easier.

  交流 ：设计师了解开发人员，反之亦然。 双方以前难以理解的概念现在变得更加清晰。 谈论组件并使用我们在交流中定义的规则会使设计和开发过程变得更加容易。

• Consistency: the look and feel of the application’s pages became the same. We know exactly what text size we should use for a heading or for normal text, what type of button we should use for a primary action, what colors to use to communicate the type of a certain action or piece of information, and how much spacing there should be between each type of element. If we decide to change any of those, then they can easily be changed across the entire design system, component library and application.

  一致性 ：应用程序页面的外观相同。 我们确切知道标题或普通文本应使用的文本大小，主要操作应使用的按钮类型，用于传达特定操作或信息的类型的颜色以及多少间距每种类型的元素之间都应该有一个。 如果我们决定更改其中的任何一个，则可以在整个设计系统，组件库和应用程序中轻松更改它们。

• Collaboration: designers and developers work closer together and are able to share ideas and insights more easily. Since it is easier to communicate it becomes easier to talk about functional constraints and to incorporate those in designs at an earlier phase. The use of a tool like Zeplin makes this process especially faster because it allows you to start a discussion in the context of any kind of detail in a design.

  协作 ：设计师和开发人员紧密合作，能够更轻松地分享想法和见解。 由于易于沟通，因此更容易谈论功能约束并将这些约束纳入早期设计中。 使用诸如Zeplin之类的工具可使此过程特别快，因为它使您可以在设计中任何细节的上下文中开始讨论。

• Documentation: component guidelines provide clear information on how a component should look, be used, behave and why that is. If in the future a component design or implementation raises questions, it becomes easier to find the reasoning behind it and to prevent rethinking what has already been thought through before (unless it no longer makes sense).

  文档 ：组件准则提供了有关组件外观，使用方式，行为方式以及原因的清晰信息。 如果将来某个组件设计或实现提出了问题，则更容易找到其背后的原因并防止重新思考以前已经考虑过的内容(除非它不再有意义)。

• Modularity: all components represent small pieces of design and code with their limited set of rules and concerns. This enforces separation of concerns in both design and code.

  模块化 ：所有组件都代表着设计和代码的小片段，它们的规则和关注点有限。 这将设计和代码中的关注点分离开来。

• Maintainability: it becomes easier to keep designs and code up to date because when a component is touched all other components that use it are updated. This can also lead to extra work on older components but gives you visibility of the impact of your change.

  可维护性 ：使设计和代码保持最新状态变得容易，因为触摸某个组件时，所有其他使用该组件的组件都会更新。 这也可能导致对较旧的组件进行额外的工作，但使您可以了解更改的影响。

As with any other approach we also found some disadvantages to the process of working with a design system:

与任何其他方法一样，我们还发现了使用设计系统的过程中存在一些缺点：

• Time consuming: this was especially true in the beginning. Defining all the rules, constraints and base components like text, color and spacing can take quite a lot of discussion. Over time it becomes faster. It depends on how many new components you need to create before designing a new feature. But once you have a few it becomes super fast to reuse them in existing or new designs. The same applies to the development of the application.

  耗时 ：一开始尤其如此。 定义所有规则，约束和基本组件(如文本，颜色和间距)可能需要进行大量讨论。 随着时间的流逝，它变得更快。 这取决于设计新功能之前需要创建多少个新组件。 但是一旦您拥有了一些，在现有或新设计中重用它们就会变得非常快。 这同样适用于应用程序的开发。

• Less creativity: due to all the rules and constraints there is less space to be creative. However, this could also be seen as an advantage since that often leads to consistency.

  更少的创造力 ：由于所有规则和约束，所以创造力的空间更少。 但是，这也可以视为一种优势，因为这通常会导致一致性。

• Steep learning curve: this applies mainly to new people joining the team because they will need to get acquainted with a lot of rules before being able to apply them consistently. On the other hand, it also makes it easier for them since the design system communicates the rules.

  陡峭的学习曲线 ：这主要适用于加入团队的新人，因为他们需要先熟悉很多规则，然后才能一致地应用它们。 另一方面，由于设计系统可以传达规则，因此对他们来说也更容易。

• Complexity: if there are components with too many dependencies on other components it can also become complex to maintain and reuse them.

  复杂性 ：如果某些组件对其他组件的依赖过多，那么维护和重用它们也会变得很复杂。

Don’t let these disadvantages scare you, though. It is part of the process to learn to minimize them. Over time, the advantages become more apparent than the disadvantages.

但是，不要让这些弊端吓到您。 学习最小化它们是过程的一部分。 随着时间的流逝，优点变得比缺点更加明显。

您如何开始？ (How can you get started?)

First of all, we recommend you get acquainted with the concept of Atomic Design alongside with design system best practices and examples of design systems like the one of Airbnb. Additionally, you should also choose a tool where to build your design system. We chose Sketch but there are other alternatives like Figma.

首先，我们建议您熟悉Atomic Design的概念以及设计系统的最佳实践和Airbnb等设计系统的示例。 此外，您还应该选择一种用于构建设计系统的工具。 我们选择了Sketch，但还有其他替代品，例如Figma 。

From there you can start defining your set of colors, typography styles and spacing sizes which will be your first atoms. This will allow you to start defining your first molecules like buttons, links, surfaces and so on. It’s likely that you will miss some use cases in this first iteration which will lead to a few more iterations until it all feels right and future proof.

从那里，您可以开始定义颜色，版式样式和间距大小的集合，这将是您的第一个要素。 这将允许您开始定义您的第一个分子，例如按钮，链接，表面等。 在第一次迭代中，您可能会错过一些用例，这将导致更多的迭代，直到一切都感觉正确并得到了未来的证明。

If you already have an application in place and can’t change it all at once then we recommend you base your design system on what you have. For each component, analyze what you have, pick the parts you like and work on improving the ones you don’t. When even this is too much work, split the future components from the legacy components. This way, you can stop yourself from using the legacy components in new components. Slowly, this will allow you to reach your goals.

如果您已经拥有一个应用程序并且无法一次更改所有应用程序，那么我们建议您基于已有的设计系统。 对于每个组件，分析您所拥有的，选择您喜欢的部分，并努力改进您不需要的部分。 即使工作量太大，也可以将将来的组件与遗留组件分开。 这样，您可以阻止自己在新组件中使用旧组件。 慢慢地，这将使您达到目标。

我们是怎么做的？ (How did we do it?)

Our team was composed of two designers and one frontend developer. Later on, one more developer joined the team. This team size was and still is enough to get things done with enough time to care about details. However, we would say the team size depends on the size of the project and the pace of the company.

我们的团队由两名设计师和一名前端开发人员组成。 后来，又有一名开发人员加入了该团队。 这个团队的规模过去而且现在足以让事情完成并有足够的时间来关注细节。 但是，我们可以说团队规模取决于项目规模和公司发展速度。

The opportunity to rebuild our frontend from scratch also had the benefit that we could learn from past mistakes. Therefore, we based the design of our new components on the feedback from our users, who frequently mentioned accessibility and responsiveness issues. To tackle those issues we concluded that we needed to redesign our navigation system first and then redesign every page in the application.

从头开始重建前端的机会也使我们可以从过去的错误中学习。 因此，我们基于用户的反馈(经常提到可访问性和响应性问题)来设计新组件。 为了解决这些问题，我们得出结论，我们需要先重新设计导航系统，然后再重新设计应用程序中的每个页面。

We started by designing our new navigation system as a whole and as it became more solid we started breaking it down into smaller components. This resulted in the intended Atomic Design division between atoms, molecules and organisms. Ideally you should start with the atoms but that was difficult without first knowing exactly which direction we wanted to take. Nowadays, since we already defined several atoms and molecules, it is easier to start composing them into new organisms or pages.

我们从整体上设计新的导航系统开始，随着它变得更加牢固，我们开始将其分解为更小的组件。 这导致了原子，分子和生物之间的预期原子设计划分。 理想情况下，您应该从原子开始，但是如果不先确切地知道我们要朝哪个方向前进，那就很难了。 如今，由于我们已经定义了几个原子和分子，因此更容易开始将它们组成新的生物或页面。

While creating components, we define them as symbols and split them in Sketch library files for Atoms, Molecules and Organisms. Sketch facilitates the reuse of our Atom components as a symbol in other Molecule or Organism components. In Sketch they are then called nested symbols. We make sure we use our components in a cascading order, so updates are propagated in one direction only.

在创建组件时，我们将它们定义为symbols ，并在Sketch库文件中将它们拆分为Atoms ， Molecules和Organisms 。 Sketch有助于将我们的Atom组件重新用作其他Molecule或Organism组件中的符号。 在Sketch中，它们被称为nested symbols 。 我们确保以级联的顺序使用组件，因此更新仅在一个方向上传播。

Our Sketch Molecules library: the icon component inside the button component is reused from the Atoms Sketch library.

我们的Sketch Molecules 库：按钮组件内的图标组件可从 Atoms Sketch库中 重复使用 。

To document our choices we create guidelines for each component (regardless of whether it’s an atom, molecule or organism) inspired in the Material UI component guidelines. Next to the component guidelines, we also have some generic guidelines which apply to all components because some guidelines are transcending, like accessibility and tone of voice. These guidelines work as our single source of truth. They ensure that nothing can be left to the imagination. To give an impression, they are a simple document with the following sections:

为了记录我们的选择，我们为“材料UI”组件指南中启发的每个组件(无论是原子，分子还是生物)创建了指南。 在组件准则旁边，我们还有一些适用于所有组件的通用准则，因为某些准则正在超越，例如可访问性和语气。 这些准则是我们唯一的真理来源。 他们确保没有任何东西可以留给想象。 为了给人留下深刻的印象，它们是一个包含以下部分的简单文档：

• Usage
  用法
• Anatomy
  解剖学
• Placement on different viewports
  放置在不同的视口中
• Behavior
  行为
• Accessibility
  辅助功能

We use our components in Template or Page files which we create per feature/project we work on. When a component or a page is ready, we share its designs with developers and other stakeholders via Zeplin. This tool allows them to extract information from designs like colors, sizes and assets. It also allows for communication per component, which can drastically improve collaboration since it becomes very easy to discuss details for which normally a meeting would be necessary.

我们在Template或Page文件中使用我们的组件，这些文件或Template文件是针对每个功能/项目创建的。 当组件或页面准备就绪时，我们将通过Zeplin与开发人员和其他利益相关者共享其设计。 该工具使他们可以从颜色，尺寸和资产等设计中提取信息。 它还允许每个组件进行通信，这可以大大改善协作，因为讨论通常需要开会的细节变得非常容易。

Collaborating on developing button components in Zeplin

在Zeplin中合作开发按钮组件

From this point onwards, developers can use the information in Zeplin to start building the corresponding React components. Ideally there should be one React component per design component so that the relation between design and code is as close as possible. For inspiration we often look at how other component libraries did it like Material-UI, for instance.

从那时起，开发人员可以使用Zeplin中的信息来开始构建相应的React组件。 理想情况下，每个设计组件应有一个React组件，以使设计和代码之间的关系尽可能接近。 为了获得启发，我们经常看看其他组件库是如何做到的，例如Material-UI 。

To ease in this process we use Storybook, which facilitates the development of components in isolation. It also offers a way of visualizing and interacting with all components in our library which can then be used by designers to validate the final implementations.

为了简化此过程，我们使用Storybook ，它可以促进隔离组件的开发。 它还提供了一种可视化方式并与我们库中的所有组件进行交互的方式，设计人员可以使用该方式来验证最终实现。

The same buttons in Storybook: ready to be reviewed

故事书中的相同按钮：准备进行审查

In both our design system and our component library we group components by categories like buttons, color, form elements, layout, links, typography and so on. This helps with grouping different atoms, molecules and organisms but also helps, once more, with the communication between designers and developers.

在我们的设计系统和组件库中，我们都按按钮，颜色，表单元素，布局，链接，版式等类别对组件进行分组。 这有助于将不同的原子，分子和生物进行分组，但又有助于设计人员和开发人员之间的交流。

In essence these tools helped us develop feedback loops in our work process, which improved communication and collaboration: designers can easily give feedback on the component library through looking at Storybook and developers can easily comment on designs or download assets from Zeplin.

从本质上讲，这些工具帮助我们在工作过程中开发了反馈循环，从而改善了沟通与协作：设计人员可以通过查看Storybook轻松地向组件库提供反馈，而开发人员可以轻松地对设计发表评论或从Zeplin下载资产。

我们能做得更好吗？ (What could we have done better?)

In general, we feel that we did quite well in this process but we know that there are some things we could have done differently. Below are some of the pain points we came across along the way:

总的来说，我们觉得我们在这个过程中做得很好，但是我们知道有些事情我们可以做得不同。 以下是我们在此过程中遇到的一些痛点：

• Accessibility guidelines: we completely underestimated accessibility. There are lots of WCAG guidelines and there’s no way you can implement them all with such a small team. We had to choose which ones were the most important for our users. However, we made this choice very late in the process because it had an impact in our atom components, mainly typography and color, which forced us to rethink several molecules and organisms.

  辅助功能指南 ：我们完全低估了辅助功能。 WCAG指南很多，因此无法用如此小的团队来实施它们。 我们必须选择对用户来说最重要的。 但是，我们在这个过程的最后阶段做出了选择，因为它会影响我们的原子成分，主要是版式和颜色，这迫使我们重新考虑几种分子和生物。

• Complex components: we tried too often to create components with too many responsibilities or too many dependencies on other components. It is better to break them down into smaller components than to try to make them too customizable. It might require some repetition both in design and code but it is easier to understand.

  复杂的组件 ：我们经常尝试创建职责过多或对其他组件有过多依赖性的组件。 最好将它们分解成较小的组件，而不是尝试使它们过于可定制。 它可能在设计和代码上都需要重复，但更容易理解。

• Lack of planning and limitless scope: for a while the scope of the project only kept on growing. Some things were very important but others not so much. It was difficult to draw a line since there was no end date for the project. Eventually, we started discussing these issues more often in order to prioritize what was really important.

  缺乏计划和无限的范围 ：一段时间以来，项目的范围一直在扩大。 有些事情非常重要，但其他事情却没有那么重要。 由于该项目没有结束日期，因此很难划清界线。 最终，我们开始更多地讨论这些问题，以便优先考虑真正重要的事情。

In the end, we managed to learn and improve upon these issues after finishing redesigning our navigation system. We still come across some complex components now and then but I think it is part of the process to make that mistake and identify it before it’s too late.

最后，在完成导航系统的重新设计之后，我们设法学习并改进了这些问题。 我们仍然时不时会遇到一些复杂的组件，但是我认为这是在发现错误之前为早发现错误的过程的一部分。

结论 (Conclusion)

In our opinion, building a design system and a component library was worth the effort. It brought the consistency in design that we were looking for from the beginning. This doesn’t mean we would recommend it for everyone. Before you get started we truly recommend you make sure this is the right solution for your project. We would say you only need to do it if you know or expect the product to require a lot of different pages with complex interactions that reuse the same components. This is especially relevant to evaluate when you are still a startup or small company and you expect to scale up in the coming years. However, if you expect your product to be a simple website that won’t change much over the years then this would probably be overkill.

我们认为，构建设计系统和组件库是值得的。 它带来了我们从一开始就一直在寻找的设计一致性。 这并不意味着我们会推荐给所有人。 在开始之前，我们强烈建议您确保这是适合您的项目的解决方案。 我们会说，只有在您知道或期望产品需要大量具有复杂交互并重复使用相同组件的页面时，才需要这样做。 这对于评估您还是一家初创公司或小型公司时的期望尤其重要，并且您希望在未来几年中扩大规模。 但是，如果您希望自己的产品是一个简单的网站，并且这些年来不会有太大变化，那么这可能是过大了。

I hope this article helps you in the process of making better design decisions. If you have questions, feedback, or suggestions regarding what you read here I would be happy to hear from you in the comment section below.

我希望本文有助于您做出更好的设计决策。 如果您对在此阅读的内容有任何疑问，反馈或建议，我将很高兴在下面的评论部分中与您联系。

普通英语JavaScript (JavaScript In Plain English)

Enjoyed this article? If so, get more similar content by subscribing to Decoded, our YouTube channel!

喜欢这篇文章吗？ 如果是这样，请订阅我们的YouTube频道解码，以获得更多类似的内容！

翻译自: https://medium.com/javascript-in-plain-english/building-a-design-system-and-a-component-library-3f4e01a7b0b4

苹果设计组件库