Alla — a UX and interaction designer. When the book was written, Alla was working at FutureLearn, and now, according to LinkedIn, she works at Apple.

In 2017 she wrote the book "Design Systems". This book is often referenced as a practical source of information on organizing work around a design system. Eight years have passed, but the book is still very relevant. Below, I provide a summary of the chapters, which I hope will help you form a general impression.

The book mainly targets small teams, though it often mentions Airbnb. At that time, Airbnb had more than 60 designers, which is hardly a small team. Still, the foundations described in the book are exactly what a small, starting team needs to lay the groundwork for a design system without making too many mistakes.

The book is divided into two parts. Foundations mostly cover the theory of design systems and their guiding principles. The process focuses on how to start creating the system and organize processes around it.

Chapter 1
Design systems

In this chapter, the author defines a design system as a collection of interconnected patterns and shared practices organized to serve a product. Patterns are the recurring elements that make up the interface. Practices are how we create, use those patterns, and organize teamwork.

A product’s domain influences the functional side of patterns. For example, a trading app needs charts, data visualization, various inputs, and tables. A course website needs articles, videos, progress indicators, etc.

A product’s brand language mostly influences the visual side of patterns. It forms the basis for what are called perceptual patterns: colors, typography, and so on.

These patterns together create the interface design language. To keep the language consistent, it’s important to document the patterns, explain them, and share them with the entire team – or even involve the whole team in that work. This depends on how the design system is organized.

Language is fundamental for collaboration. Every team member needs a clear understanding of each pattern, how and why it’s used, and why it was created that way. The more effectively this knowledge is shared, the higher the chance that patterns will be used correctly. Of course, the user also needs to understand the patterns well.

An effective design system reduces the cost of design and development while meeting user needs and achieving product goals. However, it has limits. A design system can’t fix poor design or poor UX/UI.

Chapter 2
Design Principles

The basis of any working system is its principles. They express the value and purpose of the product.

Qualities of good principles include:

1. Authenticity. Principles shouldn’t be too generic or vague – they need to be specific and applicable. For example, instead of “Simple,” try “Timeless.”
2. They’re practical and actionable. They should guide and direct decisions. “Make it simple” is too broad, but “No needless parts” is clearer. Think of advising on how to do things.
3. They have a point of view. Although design principles shouldn’t apply to every situation, they can help in complex or ambiguous scenarios.
4. They’re relatable and memorable. Having 3–5 principles works best.

To define principles, start with the product’s purpose. One good exercise is asking team members to propose principles and then looking for common themes. Focus on principles for your team and related groups. Keep developing principles and using them in your work. If they’re not applicable, iterate again. Principles may need adjusting as you implement them.

One of the hardest things is applying principles to UI/UX in practice. Use your principles when choosing a direction or making tough decisions. For instance, if you have 10 different options for a text editor or any other pattern, ask yourself which best reflects your design principles and why.

Chapter 3
Functional patterns

Functional patterns are the building blocks of the interface: buttons, banners, pop-ups, and so on. The product type and its needs can affect which patterns are necessary. Patterns evolve over a product’s lifetime, but their behavior and purpose usually remain the same.

Often in a product’s early stages, patterns aren’t defined, named, or shared within the team. This leads to recreating the same patterns many times. Over time, you need to organize these patterns. To do this:

1. Create a map of patterns grouped by their shared meaning. For example, group them by the user’s steps.
2. Audit your interface and gather all variations of the same element in one place. Ideally, do this regularly as the product grows.
3. Pick the necessary set of patterns and remove duplicates. Name the patterns based on their purpose, not just their appearance. For example, “Billboard” suggests a more action-focused, promotional role than a modest name like “Course Banner.”

Break down each pattern into its parts: text, graphics, etc. This helps combine several elements into one pattern. For example, if you have a few patterns in different sizes or shapes but with the same elements, it might be worth merging them into one component with size variations. It’s also a good way to clarify a pattern’s essence and confirm it with the team.

Sometimes you have to design a pattern that includes content (text or images) but you don’t have that real content yet. In this case, you can create it while imagining possible content. (However, it’s better to set content boundaries in advance and agree on them with the team.)

Chapter 4
Perceptual patterns

Perceptual patterns include typography, iconography, color, shape, spacing, grid, animation, tone of voice, etc. These patterns communicate the brand both on their own and in how they work together. If functional patterns reflect what people want or need, perceptual patterns reflect how they feel.

There are a few ways to explore these patterns: Mood boards, Style tiles, and Element collages (which are basically a variation of style tiles).

It’s important to find a balance between conformity and exceptions in brand perception. Too many exceptions weaken the brand. But if there are too few, things can feel too uniform and rigid.

When you’re fully focused on consistency, some of the important subtleties of what makes a product feel a certain way can be lost.Lucy Blackwell, creative director at FutureLearn

When you add new elements to the design, especially if business requirements demand them, always check if those elements reflect the brand. The more often an element is used, the more it either supports or weakens the brand.

Chapter 5
Shared language

Building a consistent, unified design system requires a shared language everyone on the team uses and understands.

First, accept that naming design system components is important. The easier they are to remember and the more inspiring they are for new ideas, the more reusable the pattern will be.

The name shouldn’t only describe what the object looks like but also its purpose. Good names often use metaphors and have their own identity. Examples might be “Brackets,” “Spotlight,” “Minions,” or “Boss-button.”

It’s best to name components together. You can create a separate chat and invite your coworkers and users for naming discussions.

Naming components isn’t enough to make the design system a daily tool for everyone. You need to immerse the entire team in all kinds of ways. For instance, you could create a special area in the office with all the styles printed out. You can also make posters or cards for each pattern.

Use the names of design system elements all the time, even if it feels awkward at first.

It’s good when learning about the design system is part of onboarding new team members. Regular meetings about the design system are also helpful. You can discuss changes, new components, and modules at these meetings.

Create and maintain your glossary of terms. This is valuable not just for explaining words to everyone on the team, but also for reinforcing a culture where words and shared language matter.

Part II
Chapter 6
Parameters of your system

Three main parameters define how a company manages a design system:

1. Rules: strict or flexible
2. Design system parts: modular or integrated
3. Organization of the work: centralized or distributed

These parameters are not binary. Each company can be somewhere in between. Below are descriptions of the extremes for each scale.

Rules

1. They can be strict, documented, and clearly described. Everyone must follow them at all times. Any exceptions are examined closely to confirm if they are needed.
2. On the other side, they can be flexible, leaving room for improvisation. In this case, rules are more like principles rather than strict guidelines.

Elements of the system

1. They can be modular. In this situation, the system is broken into small pieces that are used to build other pieces and so on. Everything is carefully adjusted and constantly reused. This approach is typical for standard digital products and apps.
2. Or they can be integrated. In this case, the chunks are larger and reused less often. The structure is less flexible. The main consistency might be the color palette, typography, and other basic elements. This format is more common in promo products and landing pages.

Organization

1. Centralized, where designated people are responsible for the design system. This format is more common for large design teams, where designers work in different areas and do not always interact closely.
2. Distributed, where everyone on the team is partially responsible for the design system and its growth.

As mentioned before, these parameters are not binary. Each team can find the balance that works best for them.

(For example, a small team might have a distributed format. Each team member contributes to the design system independently. However, one or two people might pay closer attention to consistency and focus on developing the system.)

Chapter 7
Planning and practicalities

A design system cannot be built by a few people without dedicated resources. To get resources assigned, you need to show the business how it will be useful. There are several ways to do this, but all involve showing clear, measurable value in business terms.

1. Saving time on designing and developing modules. Reusing design system elements pays off over the long term. The larger the team, the more beneficial it becomes.
2. Saving time on large-scale product changes. Without a design system, any complex change becomes a huge task. Many hidden bugs show up, and the team gets bogged down in testing and fixes. With a design system, such changes appear everywhere automatically if a component is used in multiple places. (Of course, this can still cause issues, but much less often.)
3. Faster product launches. Having a library of patterns can let you build new pages up to 10–20 times faster.

If your enterprise has 25 teams each making buttons, then it costs your enterprise $1,000,000 to have good buttons. Nathan Curtis

Besides these, there are less tangible but strategically important benefits: brand consistency, unified pattern use, collaboration, and teamwork.

Where to start when you have resources

1. Agree on your goals. Start by systematizing the interface. This includes defining design principles, identifying patterns, and building a pattern library. Also, think about how to maintain the library. You’ll likely need to refactor code and front-end architecture.
2. At the same time, set up processes. How will you share information with the team? Promote the pattern library and the shared design language within the team and encourage their use. Make sure onboarding includes an introduction to the design system.
3. Make the system’s progress visible to the entire team.
4. Create a culture of knowledge sharing. You can do this through dedicated Slack channels, newsletters, regular syncs, or workshops.

Chapter 8
Systemizing Functional Patterns

Systemizing starts with an audit of the patterns that exist in your product. You can do this in different ways, but the author suggests grouping them by their purpose.

It’s better to do an audit when the interface won’t change drastically shortly and there are no obvious UX problems. Such issues can interfere and distract.

To begin, identify your main screens. Then list the elements on those screens and group them by the function they serve. Keep the level of detail roughly the same for each. From these groups, you can pick out patterns. Some things can be combined into one pattern; others can be standardized into a single style.

Name the patterns. When choosing names, think about whether a pattern will be reused in different contexts. For example, “Button” is used everywhere, many times. However, a content card for a book, movie, or exhibit is a more specific component. The more often a pattern is reused, the more general its name can be. The more specific it is, the more the name should hint at its uniqueness.

The content structure of a pattern is the set of items it contains — text, images, labels, tags, and so on. Several patterns with a similar structure can be turned into a single component with variations. By looking at this structure, you can decide if a pattern should exist as a separate part of the system or not.

During this process, you need to keep deciding which patterns serve which tasks. You also need to decide how many variations each component can or should have. This is a team effort that sets important differences and usage rules for the system.

Chapter 9
Systemizing perceptual patterns

Perceptual patterns, as the author calls them, include colors, typography, spacings, corner radiuses, tone of voice (TOV), iconography, illustrations, photos, and sounds. All these elements shape how users perceive the brand in the product. They are the foundation on which all components are built.

The most effective systems match the team’s core design principles – for example, “timeless, not cutting-edge.” A good exercise is to think about how a pattern aligns with your chosen principles.

For each perceptual pattern, start with its purpose. Collect and group usage examples. Then identify patterns and write guidelines. The approach is the same as with functional patterns.

Example: Color palette. Start by seeing how colors are used in your product. Break them into logical categories: buttons, links, text, backgrounds, and dividers. After that, define the main patterns for using color. Remove shades that have no real meaning. Check colors for accessibility. In the end, write guidelines for using color in the interface.

Example: Animations. Do the same by auditing all animations in the product. Make a table of screenshots, animation types, timings, and motion settings. Then define the patterns for different uses – timings, animation types — and document them in guidelines.

Example: Tone of Voice. TOV is how the product talks to the user every step of the way. Again, start with an audit. Gather important text from the interface and determine the communication patterns that match your brand. Then describe principles and guidelines for writing text. It’s a great idea to include lots of real text examples for different situations.

Chapter 10
Pattern Libraries

As already mentioned, a pattern library is not the design system itself but a way of documenting patterns. Still, it’s a crucial part of the system. In this chapter, the author looks at different ways to organize a pattern library.

Content. Focus on the content. Gather an MVP version of your design system and its documentation as soon as possible. If collecting the entire system at once takes too long, start with screenshots and gradually build components from there.

Organizing patterns. At first, how you group and organize your library is not that important because you will likely change it later. You just need to agree on a basic approach. Some common methods are:

1. Abstracting Perceptual Patterns. Separating functional patterns (components) from styles is a common approach in many design systems.
2. There are also a few ways to organize functional patterns. The simplest is alphabetical order. A slightly more complex option is by purpose — for example, forms, promo elements, cards, controls, etc. Another option is a hierarchical approach. A classic structure breaks system elements down by complexity: Atoms — styles; Molecules — basic components; Organisms — large components made of molecules; Templates — layouts for interface blocks or even complete pages made of organisms and molecules.

Documenting patterns and styles. Keep it simple to start: the component or style name, its purpose, an example, and variations. Later on, you might add versioning, contributors, related components, dos and don’ts, components parts, and so on. Many existing design systems can give you ideas for documenting components.

Workflow. Here are a few points to consider:

1. Set up a process for adding new patterns and define criteria for adding them. One example of a criterion might be reuse: a pattern is added only when it’s reused a second or third time. Of course, you can also consider potential reuse. The key is to keep the process balanced.
2. Decide who is responsible for the design system. In a distributed team, you need a process so that incoming changes don’t lead to inconsistency. With a dedicated team, there are usually curator and producer roles who share responsibility for decision-making.
3. Keep the design library and codebase for the design system aligned. Ideally, they should be as synchronized as possible, including their content and naming.
4. Make sure all elements, documentation, and master design files stay up to date.
5. The component library should be the single source of truth for everyone — developers, designers, QA, and product managers.