In the last issue, we introduced one of the most important concepts in the Design System — Principles. As the core of the Design System, Principles guide our entire product Design and development process and decisions. It is also reflected in the infrastructure of our entire System.

Today’s third issue of the weekly will introduce Components and Patterns in System. As the “bricks, tiles and mud” in our entire product construction, the “soul” of System needs to be directly reflected in their design.

Components and Patterns are a very confusing set of concepts in the discussion of Design systems. Some systems have only Components, others have only Patterns, and some have both.

Since we are not in their business context, it is not easy to understand their ideas and intentions, so in today’s issue we put Components and Patterns together to see how they differ. How do we create and use them?

What are Components?

In the first installment of this series, there was a basic definition of Components. It is the foundation of the entire product design, the most basic element that makes up an interface and provides support for performing a basic operation.

Components have been around since the Web age, with input boxes, buttons, text, links, drop-down menus… These elements have been known and remembered for as long as the web has existed. No matter how the design of the page changes, it is basically made up of these components.

Of course, in the early days of the web we didn’t have many components available, and the occasional new form was based on the combination or transformation of existing components.

Therefore, it is not too difficult for users to remember and understand their purpose, which provides an identifiable and cognitive basis for the continuous development of future designs.

With the advent of mobile Internet era, users’ Internet environment has gradually migrated to mobile phones. As a result, designers and users began to contact iOS, Android, Microsoft and other new platforms, and began to deal with these new components.

In fact, these elements haven’t changed much, and many of them have simply evolved based on new features such as screen size and touchability. The differences we see between components on different platforms are more due to the platform itself and their design philosophy.

This situation has brought more troubles to designers. When designing products, we also need to pay more attention to the component differences of different operating platforms, so as to adapt to the use habits of different users.

Of course, as the industry continues to evolve, we will have more trouble, and Components will continue to evolve and become more complex with all the VR devices we see now, offline entities, and new forms we haven’t seen yet.

What is Patterns?

Compared to Components, Patterns deals with a little more complexity. It aims to provide basic operations to complete a task and is a global solution to a set of problems.

For a direct case, there is a Pattern called Confirmation & Acknowledgement in Material Design (see the picture above).

To put it simply, when a user performs an operation in the App, we need to give feedback and inform the user, and the problem of this Pattern is to provide a design solution for this series of scenes.

In fact, both Components and Pattern aim to provide practical and reusable solutions for specific problems, provide consistency guarantee for the whole product development process, provide decision-making basis, improve efficiency and reduce development costs.

What are the differences between Components and Patterns?

Based on the above description, you should have a basic understanding of Components and Patterns, but the specific differences between the two are still a little vague, so let’s continue talking about the differences from a functional perspective.

In fact, most Design systems don’t have a very clear definition of both. Some just give Components and others just Patterns, like Salesforce, Carbon, and MailChimp below. This actually has a lot to do with the corresponding business areas and the concepts of these systems, which will be mentioned later.

In contrast, Material Design makes a clear distinction between Components and Patterns. From the definition of these keywords, we can basically see that Components focuses on a certain point in the product, which is relatively simple; However, Pattern focuses more on one thing and is relatively more complicated.

Back to the Confirmation & Acknowledgement case above, Pattern abstracts the possibility of business and provides a universal solution.

Actions trigger and give feedback, which involves more context and complexity than a menu displaying a list of information. Material Design roughly divides it into two main scenarios:

  1. An important operation must be confirmed by the user
  2. Users need to be notified of non-critical operations

Material Design uses two Design forms of Dialogs (heavy) and Snackbar (light) respectively to respond to the two scenarios and provide a more appropriate solution.

This Pattern can be used to process not only information lists, but also shopping carts, wishlists, contacts… These business scenarios are different, but the same design pattern can be used. And these Design patterns are just the combination of Components mentioned above.

Going back to the details, Components as “brick, tile and mud” has clear usage guidance, and the size specification of each component has clear documentation to support the details.

Patterns, as a general-purpose solution, is more flexible and loose, serving the needs of a product (user) rather than a specific interface.

Let’s look at a more intuitive example – the player. Below is YouTube’s online player, which will be used in many scenarios of the platform from a System perspective.

We can define it as a general Pattern for video playback. If we take it (left in the picture below) as the most complex and complete solution for the player under this business, it will also be degraded step by step according to the scene demands (right in the picture below) to provide an overall design solution for the player.

Below is the function operation area of YouTube Player, which hides many powerful functions of YouTube, from subtitles, external links to image quality Settings, all can be integrated into this small area.

If we try to do some decomposition of these functions, we can roughly restore the whole framework of the Pattern. In order to make this Pattern consistent and reusable at both design and engineering levels, designers need to remove their focus from a specific business and look at how to create a player frame suitable for more scenarios from a higher perspective. The conception and definition of the framework can also facilitate all relevant people to think and judge the problem in the same way of thinking.

Of course, Pattern does not exist only in this general form, and its purpose is to solve a class of problems. It can be a set of interfaces, a flow of tasks (such as a purchase process), or even a set of gestures.

As mentioned above, there is another big difference between Pattern and Components — the difference in field. For the System at the bottom of the System like Material Design, it can serve any field and business type, so their Pattern is very “neutral”. However, for most of us designers, we mainly focus on products in a certain field. Therefore, we should pay more attention to the domain differences of Pattern.

Firefox also released their own Design System – Photon a few months ago. As a browser, Firefox clearly has different concerns than most of us.

The content in the browser (shell) is provided by the website, and Photon is more concerned with the parts it serves. They clearly define browser services such as Warnings, have two different levels of Warnings (normal and major), and provide design presentations.

For MailChimp, they don’t even provide Components, just a set of patterns (such as the Feedback shown below). Because of the nature of MailChimp, their packaging is complete enough and the business characteristics are very distinct (and not too complex), providing Patterns directly is more conducive to overall consistency and efficiency.

Of course, just because MailChimp doesn’t provide Components doesn’t mean they don’t exist, it’s just that they’re taken care of by users.

With that said, let’s think about the differences between Components and Patterns, and try to boil them down to the following:

  1. Components are relatively stable, basic materials (brick, tile, mud) in the whole System, and basic elements to solve single point problems. You have basic knowledge of it; Patterns are holistic solutions to a class of problems that have multiple possibilities;
  2. Components are also relatively stable from an engineering perspective, and Patterns are based on these relatively stable Components;
  3. Pattern has the differentiation of fields, and there are differences in the points it pays attention to and the processing forms of design in different fields.
  4. Patterns are more complex, not just interfaces, but also flows, gestures, and even a temperament conveyed through vision, motion, and writing.

Having covered the differences between these two concepts, I want to focus on Patterns for the rest of the article (paid) and talk to you about why we need Patterns and how we should think about summarizing and creating Patterns.

Design System is a new series of PinDesign Weekly, based on book notes and lessons learned within the framework of the book “Design Systems”. I hope to share my feelings and experience with you to help you read.

Join PinDesign to receive the full text of this issue’s theme “What is Design Principle?” and the first two weekly issues as gifts.

Click to receive a 50 yuan coupon for PinDesign membership program

Design System review:

01. What is the Design System

02. What are Design Principles