design system case study

Building and Scaling a Design System in Figma: A Case Study

Building a design system for a multinational company means cataloging every component in meticulous detail. It’s a massive undertaking that calls for both a big-picture view and a focus on specifics. Here’s how one design system team leader accomplished it.

By Abigail Beshkin

Abigail is a veteran of Pratt Institute and Columbia Business School, where she oversaw the design and production team for Columbia Business magazine. Her work has appeared in the New York Times and been heard on NPR.

Determining how to build a design system for a multinational company means cataloging every component and pattern in meticulous detail. It’s a massive undertaking that calls for both a big-picture view and a focus on specifics. Here’s how one design system team leader accomplished it.

When Switzerland-based holding company ABB set out to create a design system , the goal was to knit together a consistent look and feel for hundreds of software products, many of which power the mechanical systems that keep factories, mines, and other industrial sites humming. It was no small task for a company with almost two dozen business units and nearly 150,000 employees around the world. For Abdul Sial , who served as the lead product designer on ABB’s 10-person design system team, scaling the library of components and patterns depended on maintaining openness and transparency, with an emphasis on extensive documentation.

The Role of a Design System Designer

Increasingly, large companies like ABB have teams dedicated exclusively to creating and maintaining design systems. “A design system allows for consistency, going to market in a fair time and not allowing production to get stuck on customizations that are not building value,” says Madrid-based designer Alejandro Velasco . Or, as Alexandre Brito , a designer in Lisbon, Portugal, explains, “Design systems come to provide structure whenever there are many people using the same set of tools. It’s like everyone having the same language.”

If a traditional style guide covers the design basics—fonts and colors, for instance—a design system has a much further reach. “A design system is a mix of a style guide, plus design components, design patterns, code components and, on top of it, documentation,” Sial says. When he worked on ABB’s design system, about 120 designers used it on a regular basis. The effort represented version 4.8 of the system, and the team dubbed it “Design Evolution.”

Design system designers play a different role than those who focus solely on individual products. “You have the bird’s-eye view of all the different products that a company is using,” Sial says.

Working in design operations also calls for communicating with stakeholders throughout a company. “Design system designers have to be social,” says Velasco. “A design system designer has to really like to work and talk with people who have different roles within an organization. They have to be able to distinguish what feedback to include in order to build the design system around the company’s needs.”

The Life Cycle of a Component

Working on ABB’s design system, Sial was guided by one overarching philosophy: “Documentation, documentation, documentation.” For every reusable element on ABB’s websites, mobile screens, or large stand-alone screens, Sial wanted to show what he calls the life cycle of a component. That meant extensive record-keeping for all components and patterns—breadcrumbs, headers, inputs, or buttons, to name just a few. “What are the journeys it went through? What decisions went into it? That way we’re not always recreating everything. Before trying something, you can read and see that someone already tested it,” Sial says.

In his experience, this philosophy is a departure from the typical approach to documentation. In the fast-paced world of product development, for example, documentation is often written at the end of the project or abandoned altogether. But for design systems, Sial says, documentation should be more than an afterthought. “A design system is never done; it needs continuous improvement,” he says. “Design system creators and consumers want to understand the thought processes and decisions in order to keep improving it.”

Documentation is especially important for a design system as large as ABB’s. “With such a large team you have to be able to scale,” he says. “How can we make sure that everybody who joins the team can quickly go to any component and understand how it started, how it was edited, and what version they are using?”

Finding the Right Tool

There are many tools out there for building design systems, including Figma, Sketch, and Adobe XD. Sial experimented with several, trying a mix of design and project management tools before settling on Figma, which offers ample space for documentation.

Sial and his team determined that every component should sit within its own file. “Most of the time, you’re working on one component at a time. If you put all the components in one file, it slows down Figma. By giving each component its own file, it’s quicker to open and you have the whole history and documentation in one place,” he says.

Setting the Hierarchy

Sial set up the ABB design system so that the file for each component and pattern has the same pages. The images that follow detail what’s on each page.

Sial recommends setting up a simple cover page for every component. In Figma, this enables a thumbnail preview of all the components and helps with the browsability of files. In the ABB setup, the cover page includes the component name and what phase it’s in: design, development, or released. The status can be easily updated when the component progresses.

Inventory, Use Cases, and Requests

This page contains examples of the numerous ways that a component shows up in a company’s digital product. In the case of a text field component, for instance, the inventory page would show how the text field looks on abb.com compared to how it appears on an iPhone compared to how it shows up on an Android device. “The inventory allows us to understand clearly what’s already there,” says Sial.

This page should also show the ways the component is being used incorrectly. “This allows you to look at your products and see where there are alignments and misalignments,” Sial says. He advises teams launching a design system project to begin by cataloging what already exists. “Start with inventory and it will guide you as you’re creating the design,” he says.

References, Best Practices, and Competitive Analysis

Sial advises creating a section of each component file akin to a vision board, showing how other companies design comparable pieces. “As with anything else, best practice is to perform competitive analysis and see how other people are doing it,” he says. “Observe other products and see their learnings.”

Tests and Data

The test results data page aggregates all the data related to testing a component, including the results of A/B testing and feedback from users and stakeholders. In short, Sial says, “It’s the whole story of a component.” Perhaps the design team tried a new variation two years ago and found it didn’t work? “Maybe we worked on that variation and we discarded it for some reason,” he says. If so, this kind of history can save significant time by making sure that designers don’t try it again.

The next page lays out a component’s scope so designers can bring a design to fruition. By the time they arrive at the scope page, Sial says, “You have a story. You understand the inventory of all the products. You know what you need to build and you know the requirements. Now it’s time to write it down and make a brief out of it.” He adds that creating the scope should be a collaborative process with the product owners, developers, and designers.

Images of the final versions of the component are found here, with the latest iteration pinned on top. Other designers should be able to review and comment on it.

The sandbox enables designers to experiment with different iterations of a component or pattern directly in Figma. “It can be messy, and there’s no standardization,” Sial says. “It’s just a playground where a designer has the freedom to do anything.”

Figma Component

The file also contains a page for the Figma component itself, a UI element that is easily repeatable throughout the design system. The designer can make changes to the component, and that change will populate throughout all the instances of that component across the company, keeping everything consistent. This page will be exported to the Figma design system library, and any individual designer can drag and drop the Figma component into their design. If the design system team needs to make a change to the component, they can make it once and deploy it throughout the company.

Style Rules

Next, the design system designers and developers create the style rules page, a kind of catch-all for elements that, Sial says, “are not visible in the design.” For example, how will the component render when you scroll down the page? It’s also where the design system team keeps track of unresolved questions or issues. He says he was surprised at how integral this page turned out to be: “At first, we thought this page was not that important, but now we realize we spend most of our time here.”

The handover notes are the instructions for developers on writing the code for the component. The handover document begins with the anatomy of the component, then includes its variations.

The ABB system handover documents also include design tokens . Becoming increasingly popular in large-scale design systems such as ABB’s, design tokens are pieces of platform-agnostic style information about UI elements, such as color, typeface, or font size. With design tokens, a designer can change a value—indicate that a call-to-action button should be orange instead of blue, for instance—and that change will populate everywhere the token is used, whether it is on a website, iOS, or Android platform.

Sial also created a Figma token plug-in to expand the scope of tokens designers can create in Figma. “Figma supports colors, typography, shadows, and grid styles,” he says. The plug-in will generate tokens for more variables, such as opacity and border width. It also creates a standardized naming convention, so designers don’t have to keep track of token names manually. “The plug-in bridges the gap between developers and designers. It allows both to work on a single source of truth for design; if one makes a change in one place, that change takes effect everywhere in the design and code,” he says.

Sial stresses that in his system, developers take an active role throughout the creation of a component. “Early on, we would involve our developers when we had something ready to show them,” he says. “Then we realized that’s not working, and now we literally start kickoff sessions with them.”

Documentation Webpage

The last page of each file contains a webpage with the final design, showing how the component looks as a finished product. “We create a page that shows how the live example will look so the users, in this case our designers, can see how it will look at the end of the day on a real website,” Sial says.

Collaboration Is Key

The role of a design system designer is multifaceted. As Alejandro Velasco says, “Designing a design system involves so many roles, and if I’m leading that, I’m the glue for the project.”

It’s an enormous undertaking and not necessarily the right move for all companies. Startups, for instance, might do better to begin with an out-of-the-box system such as Google Material Design or the IBM Carbon Design System , rather than dedicating extensive resources to creating one. Still, the time might come when that won’t suffice, says Alexandre Brito: “As soon as you have multiple designers working together, you start to realize that there’s a need for someone to build rules that are more in line with the product or brand you’re building.”

Building a design system takes work and dedication; it also takes collaboration. Sial stresses that involving all stakeholders in the development of ABB’s system throughout the process was a priority. “It was really iterative work with my whole team. It was all about listening to them and we took the time to learn and test it thoroughly and develop this structure,” he says.

Having a structure that includes extensive documentation, including history and best practices, is at the core of the Figma design system. “It’s a success because people can read the documentation all in one place,” Sial says. “They can see everything, starting from the use case to the design and moving on to the handover and the final component page. People can see the whole life cycle of a component.”

You can browse Abdul Sial’s Figma file in its entirety here: Component Template .

Further Reading on the Toptal Blog:

• Saving Product X: A Design Thinking Case Study
• All About Process: Dissecting Case Study Portfolios
• The Benefits of a Design System: Making Better Products, Faster
• Helping AI See Clearly: A Dashboard Design Case Study
• Design Problem Statements: What They Are and How to Frame Them

Understanding the basics

What is a design system.

While a traditional style guide covers the design basics—fonts and colors, for instance—a design system has a much further reach. The design system documentation for Switzerland-based holding company ABB, for example, contains design components, patterns, and code components.

What role does a design system designer play in an organization?

Design system designers play a different role than designers who focus solely on individual products. They tend to have more of a bird’s-eye view of all the products a company is using. They also must interface and communicate with stakeholders throughout a company.

What are some best practices when building a design system?

One approach is to organize it in Figma and give each component and pattern its own file. This design system case study demonstrates one approach: At ABB, each file has several pages with extensive documentation on all the ways the element is used throughout the product and all the iterations it went through. Showing the full life cycle of a component is key to building and scaling a design system.

• DesignProcess

World-class articles, delivered weekly.

Subscription implies consent to our privacy policy

Toptal Designers

• Adobe Creative Suite Experts
• Agile Designers
• AI Designers
• Art Direction Experts
• Augmented Reality Designers
• Axure Experts
• Brand Designers
• Creative Directors
• Dashboard Designers
• Digital Product Designers
• E-commerce Website Designers
• Full-Stack Designers
• Information Architecture Experts
• Interactive Designers
• Mobile App Designers
• Mockup Designers
• Presentation Designers
• Prototype Designers
• SaaS Designers
• Sketch Experts
• Squarespace Designers
• User Flow Designers
• User Research Designers
• Virtual Reality Designers
• Visual Designers
• Wireframing Experts
• View More Freelance Designers

Join the Toptal ® community.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

Unveiling the best design systems: Principles, examples, and key takeaways

Systems are all around us, even if we don’t notice them. They are the hidden engines behind banking, healthcare, and even the economy. A system is like a team of different parts that work together to achieve a specific purpose. They bring order to potential chaos and make things work better and faster.

Design systems play a significant role in helping teams create consistent and scalable solutions. A robust design system helps designers and engineers work more efficiently and implement design consistency across one or more products. By leveraging common components and patterns, they can get from problem to solution much faster. This article will talk about the principles that guide successful design systems and key takeaways from a few examples to help you develop your own.

What is a design system?

Guiding principles of effective design systems, essential components of design systems.

• Case study: Example 1  —  Carbon design system
• Case study: Example 2  —  Audi design system
• Case study: Example 3  —  Polaris

Lessons learned from the best design systems

Implementing a design system: guidelines and considerations, design system tools and resources, measuring the impact of a design system.

A design system is a centralized repository of design principles, guidelines, and reusable components that aid in design decision making. Its purpose is threefold: to promote consistency, efficiency, and brand cohesion.

Serving as a single source of truth for a team or organization, a design system establishes standards and guidelines, giving designers and developers the building blocks necessary for efficient and scalable design creation. By providing a library of shared components, a robust design system can reduce redundant workflows and boost a team’s efficiency, making it relatively quicker to go from a problem to a high-fidelity solution.

Using a design system promotes consistent user experiences across a product or platform of products. It provides the visual elements necessary to ensure cohesive branding, which is important for making digital products and websites recognizable and memorable by users.

Design principles create the foundation of a successful design system. They are shared guidelines that set the standard for design excellence and support the team’s mission to create solutions that resonate with their users. Although design systems can each have unique principles tailored toward their context, here are a few overarching ones that can contribute to their effectiveness.

Design components and patterns should be able to work well together to create unified user experiences. Cohesive design systems integrate closely related elements that can maintain visual harmony, and consistent interactions, and address a range of user needs.

By focusing on closely related elements within the design system, designers will have the necessary tools to create consistent and intuitive user journeys.

Effective design systems are composed of reusable modular components, which gives designers the building blocks to create a variety of interfaces. Modularity provides versatility in how components are arranged and configured within a layout.

This approach saves time and effort, allowing designers to easily mix and match the modules to create different page layouts while ensuring a coherent design language throughout the product.

Scalability

A design system is a living entity that continues to evolve alongside the products. Adapting to changes in the scope and scale of products ensures that visual and functional experiences are maintained across screen sizes, devices, and platforms.

Over 200k developers and product managers use LogRocket to create better digital experiences

Using modular design principles, focus on frequently used components that can cover a range of scenarios by creating variants. This ensures that designers have the tools available to meet the requirements of any challenge.

Accessibility

Inclusive products allow fair and equal access to all users, regardless of their ability. Design systems should have inbuilt accessibility best practices that meet WCAG accessibility standards. This considers users who experience challenges while using products in a traditional way and might require assistive tools, such as a screen reader. Even though a design system contains accessible components and elements, designers must still consider how they work together in order to design a holistic, accessible experience.

Every design system has its own unique features or characteristics; however, there are several essential components that all design systems share. Let’s explore the purpose and application of design tokens, typography, color palettes, grid systems, UI components, and documentation within a design system.

Design tokens

Design tokens are variables used by designers and engineers to communicate the values of how things should be styled when building interfaces. These tokens point to important information such as colors, font styles, spacing, or animation.

Instead of providing fixed values to hard-code into a product, which can be hard to change, design tokens ensure that everything stays consistent and works well together, even if the values themselves change.

For example, a design token intentPrimary might point to a primary color value that is blue. But if the team decides to rebrand and change its primary color value to green, every element associated with the token intentPrimary will be updated to green, while the token remains unchanged. This example shows how design tokens keep design systems organized and easy to maintain.

A major component of brand and style guidelines, typography consists of selecting fonts that can be used for specific scenarios. Some key aspects of typography include choosing the brand’s typefaces, as well as defining font sizes, weights, and styles for various use cases, such as headings, subheadings, body text, or labels. Typography guidelines keep content visually organized by establishing a hierarchy and ensuring legibility across various platforms.

Color palette

A well-defined color palette within a design system has a number of benefits, including establishing brand identity, guiding user interactions, and maintaining visual consistency. A color palette generally consists of primary colors, secondary or tertiary colors, and background and text colors.

Before defining your colors, identify the different use cases and contexts in which color might be needed. Thoroughly test your color palette to ensure that there is sufficient contrast between background and text colors, and provide guidance on how colors should be used across different UI elements.

Grid systems

Grid systems help organize and align design elements to create cohesive layouts. A grid is a series of evenly spaced columns and rows that provide structure to designs. They can help position individual components in a way that makes information and content flow smoothly throughout a page.

A design system might have several grids to account for responsive layouts on different screen sizes, such as desktop, mobile, or tablet. The most common types of grid systems include column grids and modular grids.

A column grid system consists of a set number of columns that span the width of the page, providing vertical guidelines for visual alignment. A fluid column grid can adjust to the screen size, either by expanding the column widths or changing the number of columns used.

A modular grid system consists of columns and rows that break layouts into modules, providing more flexibility in how elements are arranged in the layout.

UI components

A design system would be incomplete without UI components, the fundamental building blocks of an interface. UI components are the elements users interact with on a page, ranging from common input controls like buttons, checkboxes, dropdowns, and radio buttons, to navigational components like search bars, breadcrumbs, pagination, and tags.

In addition, there are informational components like progress bars, tooltips, toast notifications, and modals, along with containers like accordions or panels. The components listed represent just a subset of the wide variety of UI components that contribute to a cohesive design system.

When selecting UI components for a design, it’s helpful to consider users’ mental models. Users have become accustomed to interacting with certain UI components in specific ways, so choosing the right component can help with familiarity, task completion, and ease of use.

Documentation

Finally, each design element and component should have detailed documentation to provide guidance on how to properly use them. Well-documented design systems communicate rules and best practices to aid designers and developers during the design and implementation process. It’s helpful to explain common use cases for each element, as well as how not to use them, to avoid inconsistencies in the final design.

Documentation can be communicated in the form of an overview, visual examples or use cases, and scenario explanations to give enough detail on how to use each element and avoid any confusion. It also includes working code for developers to implement and customize the element for their application.

Case study: Example 1  — Carbon design system

IBM’s Carbon is an open-source design system that provides a collection of reusable assets such as components, patterns, guidance, and code. Its primary goal is to build efficiency and consistency in the design process, giving designers a comprehensive toolkit they can leverage in their workflow. This saves designers time from building basic elements and instead allows them to focus on creating digital experiences that meet user needs.

Carbon offers a well-defined design language that includes typography, content, color palette, iconography, grid systems, motion, and accessibility guidelines. This enhances the brand identity across multiple products by defining specific visual guidelines.

Carbon also hosts a library of UI components, patterns, and data visualizations for various use cases. This ensures that design decisions are unified, leading to consistent user experiences across multiple products. Each of the base elements leaves room for customization, which allows projects to scale well as the scope evolves. This modular approach gives designers the flexibility to design for any scenario.

As an open-source design system, Carbon facilitates collaboration and knowledge sharing, encouraging contributions back to the design system. This leads to continuous improvement and has a direct impact on IBM’s projects, ensuring consistent and cohesive user experiences. Also, Carbon’s focus on accessibility shows its commitment to inclusive design, which empowers designers and developers to create accessible experiences for all users, regardless of their abilities.

Case study: Example 2 — Audi design system

The Audi design system highlights its focus on speed, consistency, and quality for development across all Audi products. The design system was created to support designers and developers to build products efficiently that meet the evolving needs of their customers.

The design system acts as a single source of truth for Audi’s global product teams. Its products range from websites to in-vehicle applications, each with unique user interface requirements. Their design system offers a library of brand identity guidelines and components to ensure consistent branding and user experience regardless of the platform.

Efficiency is a common theme across design systems, and Audi’s design system aims to enhance the speed of asset creation by giving designers access to reusable components. By removing the need to recreate basic elements, designers are able to focus on innovation and quickly design pages by leveraging and customizing Audi’s purpose-built components and patterns.

Each of the UI components provides usage guidelines, as well as variations that cover different states and use cases. The documentation includes available properties for developers to understand how to customize each component.

Audi emphasizes accessibility by providing WCAG and WAI-ARIA guidelines, as well as additional web accessibility resources for designers and developers to follow, ensuring that its final products allow equal and fair access to all users.

Case study: Example 3 — Polaris

Polaris is Shopify’s design system, built to guide app developers and designers in creating outstanding merchant experiences for the Shopify admin. Its focus is on enabling designers and developers to create apps that add functionality to the Shopify admin experience.

Shopify emphasizes that “Polaris is the floor, not the ceiling,” meaning that designers should use the design system as a foundation without limiting their creativity. They recommend focusing on solving problems first rather than worrying about consistency, which will come later. Polaris is meant to provide the building blocks with the added option to contribute back to the design system if a gap exists.

One of Polaris’ standout features is its robust content guidelines. It provides rules and best practices around actionable language, alternative text, error messages, and even grammar to ensure that the way copy is worded maintains the brand’s tone of voice and way of communicating with its users. The Do’s and Don’t’s are a great method for providing examples while explaining usage guidelines.

Polaris conveniently lays out the different variants of each UI component across the top of the page to allow users to easily view and compare to decide on the best one for their application. This convenience enhances the efficiency within a designer’s workflow, allowing them to quickly make informative design decisions.

Its icon library is easily searchable with each icon associated with multiple tags, allowing users to quickly find visual elements without knowing the specific name. It provides guidance for both designers and developers on how to access and use the icons, further enhancing their workflow efficiency.

From exploring these design systems, there are common themes and best practices that can be applied when developing your own. Some of the core principles include efficiency, consistency, open collaboration, accessibility, and clear documentation. These principles can be applied to small and midsize businesses (SMBs) to improve design and development processes.

Enhancing workflow efficiency

All three design systems emphasize the importance of efficiency in design and development. The main goal of any successful design system is to help product teams design and develop solutions faster without the need to recreate common assets. Providing reusable components saves time and effort by avoiding redundant work.

SMBs often have little resources allocated to development as they try to maintain a lean approach. By leveraging a design system, they can build efficiency into their workflow by speeding up product development and ultimately saving time and money that can be invested in other areas of the business.

Keeping experiences consistent

Consistency is another common theme of successful design systems. The purpose of a design system is to ensure that teams develop consistent experiences across all their products so that customers can quickly familiarize themselves with their tools.

Consistency is key in preventing user confusion, especially for SMBs that are in the early stages of customer adoption. This can help users quickly understand and see the value of a product without being concerned about its usability.

Contributing back to the design system

Carbon and Polaris are open source design systems that encourage contributions from the community. Design systems are considered a foundation to start building from but may have gaps that don’t address specific use cases or customer needs.

SMBs often have to adapt to changing customer requirements as they learn more about their users. Thus, their design system might not contain the necessary elements for building robust solutions.

A design system shouldn’t limit a team’s creativity by being too prescriptive, but rather spark ideas and allow for innovation. It should leave room for flexibility and scalability, especially for a small team that is growing quickly. By fostering a culture of open collaboration, design and development teams can continuously improve the design system.

Prioritizing accessibility and inclusive design

All three design systems prioritize accessibility by providing guidelines for designers and developers to build accessibility into their solutions. This ensures that product teams are considering users with disabilities creating products that are usable by all individuals.

Accessibility should be incorporated early into the development process instead of treated as an afterthought. SMBs can benefit from designing accessible products to help them reach a broader audience. It’s important to note that investing in accessibility early on can prevent teams from accumulating design debt and having to address accessibility issues later.

Implementing your own design system can seem like a daunting task. Here are practical guidelines and considerations for design system adoption, collaboration, documentation, and maintenance.

Before you jump ahead, first understand why your team needs a design system. This includes identifying any business goals and user needs that the design system would align with, such as improved designer efficiency and consistent user experiences across products. Communicating these benefits to stakeholders, such as product and development teams, can help with team adoption so that stakeholders are on board and aware of the design system’s existence.

Then, define the scope of your design system by outlining the essential elements and components that your team needs. Collaborate with your cross-functional partners, including design, development, product, and content, throughout this process to ensure alignment across teams and cover various requirements.

A guideline to consider is that proper documentation will lead to consistent experiences. It also takes the guesswork out of the team’s workflow, further enhancing their efficiency to get to results quicker. Even with limited resources, SMBs should focus on providing concise and clear documentation that outlines how to use design system elements. Investing the time and effort to document a design system clearly can lead to smoother implementation and avoid any confusion or misuse down the road.

Once your design system is up and running, provide thorough training to help your team use it effectively. Advocate for its adoption, but implement it gradually to avoid disrupting existing workflows and committing drastic product changes that might overwhelm users.

Maintaining a design system ensures that it evolves with changing customer needs and business objectives. It can be helpful to establish a regular cadence of feedback to gain input from team members in order to continuously refine the design system. Encourage team members to contribute back to the design system in order to fill gaps in the experience. Design system office hours are also a great way to broadcast any new changes or fixes to the design system components.

Many companies use Figma as their main design tool, so it’s a no-brainer to also use it to host design system assets. Teams can create a centralized library of reusable assets, including component variants and design tokens for designers to easily leverage in their Figma files.

Figma is a collaboration tool, which is perfect for enabling multiple team members to work in real time on the design system, speeding up development and ensuring everyone is aligned. Figma recently introduced Dev Mode, which allows developers to quickly inspect and translate designs to code, further accelerating design system adoption.

A popular open source tool for developing UI components within a design system is Storybook. Its main feature is the ability to build UI components in an isolated sandbox environment, which enables developers to render different variations of a component by using props and mock data. This reduces the need to spin up the entire app to test the component, saving substantial development time.

Storybook can be used to maintain documentation for how UI components behave and interact. The platform is interactive, allowing users to test out various use cases for each UI component. It also supports collaboration by allowing teams to discuss feedback during the design system development process.

Zeroheight is a centralized platform for design system hosting and documentation. It allows teams to create organized and interactive style guides, component libraries, and guidelines. Zeroheight ensures that design documentation remains up-to-date as components and guidelines evolve, making it easier to communicate changes across teams.

It also has inbuilt integrations with other design system tools, including Figma and Storybook, which help automate the workflow from design to code. Teams can import their assets from Figma and display developer resources for each component all in the same place as their design system documentation.

After your design system is implemented and teams have adopted its usage, it’s important to evaluate the impact and effectiveness that it has on your business to understand which areas are working or need improvement. The impact of a design system can be assessed by evaluating a combination of quantitative metrics and qualitative insights. This will result in a broader understanding of its performance.

In terms of quantitative metrics, it can be useful to track:

• The number of projects that use design system tokens and components
• The number of components used in each project
• The frequency of each component used across projects

These metrics will give you an idea of adoption rates across the organization, as well as which components are the most valuable to your teams. This can help in measuring which areas of the design system are most successful and which ones might need improvement.

On the other hand, qualitative insights offer a more human perspective. By gathering feedback through surveys and testing, you can begin to uncover the challenges that your team faces when using the design system and what can be done to alleviate these pain points. Continue to iterate and gather feedback in an iterative loop to improve your design system, which will lead to further adoption and success.

Setting measurable goals can help craft a clear understanding of how to improve your design system. These goals can cover things such as reduced design time, improved consistency, and increased user satisfaction. Achieving a successful design system requires an ongoing commitment to collaborate with your team: listen to their feedback and adapt to changes. The resulting value will benefit both your team and users in a significant way.

Conclusion and key takeaways

Design systems are essential for achieving design consistency and scalability in products. They also play a big role in enhancing efficiency in product development workflows. Design systems offer centralized repositories of guidelines and components, driven by principles like cohesion, modularity, scalability, and accessibility. These principles can apply to businesses of all sizes, including SMBs looking to streamline design processes and enhance user experiences.

For designers and teams interested in developing their own design systems, start by collaborating with cross-functional partners to understand its purpose and scope. Then, communicate its benefits to stakeholders so that everyone is on board.

As your team gradually adopts the design system, remember to maintain clear documentation and gather feedback from them. Using tools like Figma, Storybook, or Zeroheight can help you manage and broadcast changes to the design system as it evolves. By continuously tracking the success metrics of your design system, you can identify areas that are lacking and make the necessary improvements that your team and users will benefit from.

LogRocket : Analytics that give you UX insights without the need for interviews

LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.

See how design choices, interactions, and issues affect your users — get a demo of LogRocket today .

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #design systems

Stop guessing about your digital experience with LogRocket

Recent posts:.

Figma Dev Mode: What it can and can’t do for a UX designer

Figma Dev Mode has an easy-to-work-with UI and layout and makes collaboration with other team members far easier.

Creating user friendly support documents that relieve customer support strain

Ideally, UX designers should collaborate with customer support agents more often to improve user experience. Here’s how they can start.

Reimagining Gantt charts for UX project management

Gantt charts, if applied correctly, can be a strategic asset for keeping your head above the waves of complexities in UX projects.

13 UX Podcasts to subscribe to in 2024

Interested in everything UX design? Check out these 13 UX podcasts that are sure to be a blast to listen to.

Leave a Reply Cancel reply

How to Use a Design System – a Case Study

You may have heard of, studied, or used a design system at some point in your coding career. But what role do design systems actually play in our projects? Why should we even bother to create or use them?

In this guide, you'll be learning what design systems are, why they're important, typical elements of a design system, and a practical example of how to implement a design system as a designer. Let's dive in!

What is a Design System?

Design Systems are structured collections of reusable design components and elements. We use them to create a consistent and cohesive user experience across a range of products or services.

A design system is like a set of building blocks and rules for creating digital products like websites and apps. Design systems are made up of key elements like typography, color palette, icons, spacing and layout, and so on.

Importance and purpose of a Design System

Design systems are important for many reasons.

Design systems help you become more efficient. Because it's a collection of reusable components, it saves the time of producing new elements, and helps designers produce new features quickly in projects. It also serves as a productivity booster.

Collaboration

A team trying to build a product may consist of designers, developers, product managers, and others. The design system helps all members of the team make reference to the brand guidelines, no matter what they working on. It also helps to make sure everyone, including stakeholders, are involved in the design process, and facilitates collaboration.

Consistency

Design systems ensure consistency in the user interface and user experience across various products and platforms.

We wouldn't want a scenario where a button design is inconsistent on different screens, would we? That's where the design system comes in. It helps our design assets and elements stay consistent, and it can always serve as a reference point.

Scalability

Scalability here refers to the ability of the design system to grow and adapt to the changing needs of a project or an organization.

A crucial element of any design system is scalability. Design systems help in situations where the project might need to expand to accommodate different devices and platforms or when the team is expanding or when trying to accommodate new trends and practices.

How Design Systems work

To understand how a design system works, you just need to know the kinds of assets or components that make up the system and their roles.

A typical design system comprises of the following parts:

When you open a design system, one of the first things you'll see is a colour palette section. It's one of the most common elements in a design system.

Design systems define a set of of primary and secondary colours, as well as their various uses. This includes background colours, text colours, and so on.

Another typical element of a design system is typography. Every design system usually includes guidelines for typography, specifying fonts, font sizes, line height, and so on.

It may also define how typography is used for different content types like headings and body text, making sure they're accessible and legible for design use.

Icons are very important when trying to give visual clues to your users. Design systems provide a set of standard icons and guidelines for their usage, ensuring they are recognizable and consistent.

Grid and Spacing Styles

A grid system helps establish a consistent structure for different components or pages.

Design systems provide spacing guidelines specifying margins, padding, and other layout-related rules to maintain alignment to create a visually pleasing and organized design.

Documentation

Every well-structured design system has some form of documentation that usually explains how to use the elements and guidelines effectively. The documentation also helps designers and developers understand how to use and implement the design system.

UI Patterns and Components

UI patterns and components are the building blocks of a user interface. Design systems define UI patterns and components such as buttons, forms, modals, accordions, navigation bars, and so on, along with guidelines on how and when to use them.

Content Guidelines

These cover how text and imagery is used in the user interface. They may specify tone, image use, and content hierarchy, ensuring that the content is consistent and aligns with the brand guidelines.

Accessibility Guidelines

Most design systems contain accessibility guidelines in order to increase the usability of products for people with all kinds of abilities. These guidelines ensure that the design is inclusive and complies with accessibility standards like WCAG (Web Content Accessibility Guidelines). This includes colour contrast, keyboard navigation and other accessibility features.

Examples and Use Cases

Most design systems also contain examples and use cases of the design system in action to help designers and developers understand how to implement it effectively.

Differences Between a Design System and a Style Guide

Style guides and design systems are very similar and can often be confused for the same thing – but they're different.

Some differences between design systems and style guides are:

Style guides are relatively limited in scope and may not include detailed UI components or interactions.

Design systems on the other hand, are more comprehensive and encompass a broader range of elements including interactive components, user interface guidelines, amongst others.

Style guides typically focus on ensuring brand consistency, helping maintain a uniform look and feel across various materials and platforms.

Design systems aim to establish both brand and user interface consistency, by providing reusable components and interaction patterns.

Evolution and Scalability

Style guides tend to evolve more slowly, and might not be as scalable as design systems. Design systems are more adaptable and evolve with the product or service.

Style guides are mainly used by designers to ensure visual consistency across a brand. They have a limited role in facilitating collaboration amongst designers and developers.

Design systems, on the other hand, promote collaboration by providing a common language and shared resources between designers and developers.

Real-Life Examples of Design Systems

A lot of software corporations have created their own design systems to help ease the work of their designers and generally make it a smoother experience to build products.

Google, for instance, has a design system which they use for their products – you can see similar styles and elements in most of their products.

Most of these design systems are free and available to the public for use. Some examples of real life design systems are:

• Google Material Design by Google
• Apple Human Interface Guidelines by Apple
• Atlassian Design System by Atlassian
• Polaris by Shopify
• Carbon Design System by IBM

How to Use a Design System for Your Designs – Rayna UI Design System Example

For this article, we'll be using the Rayna UI Design System to illustrate how to use a design system for your designs.

It's a newer design system that I recently learned about, so I thought I'd share my experience by using it for a challenge.

Step 1 – Download the Design System

The first step will be to download the design system you're trying to use. In this case, we'll download the Rayna UI Design System. Go to their landing page @ Rayna UI and grab it from there.

Next, click on "Get Rayna UI" to download the design system.

Next, type your email in order to get the design system sent to your email address.

The link to the Figma file will be shared to your email, and you can open it.

Scroll down in the email to find the link to view the Rayna UI Figma file.

Click on the link sent to your email to open the design system. The link will open up the Rayna UI Design System on the Figma community.

Next, click on the "Open in Figma" button by the right side of your screen.  This will open up a Figma file containing all assets and components of the Rayna UI Design System.

Step 2 – Publish the Rayna UI Design System to your libraries.

The next step is to publish the Rayna UI Design System to your libraries, so you can use it for any design.

The third page on the Figma file (Get Started) contains a guide to getting started with the design system. Included in this guide are resources for beginners so you can gain a solid grasp of the basics, along with steps to take to publish and enable the library in other projects.

Follow the steps given in the guide to publish the library. First, go to the assets panel in the top-left area of your screen, and press the book icon.

When you click on the book icon, it'll bring up a modal for you to publish the library.

Click on the publish button next to the file on the modal.

I was asked to move the library to a professional team, so I could publish there. Click on the "Move to team" button to move the file.

Next, select the team file you want to publish the library to.

After selecting a team, you'll have to publish the design system to the team files.

You'll receive a notification that your library has been published.

How to Use the Design System in Your Projects

Next, we'll be learning how to implement the design system in a design. I'll be designing a sign up screen for a fintech website to illustrate this.

Before starting your design, you can copy some icons you may need from the design system to your design file. I tend to copy the buttons and input field styles I may need, if I want to adhere strictly to the design system.

For the sign up page I'm going to be designing, the details I need are the name of the website, input fields (full name, last name, email address, password, confirm password), and the buttons or CTAs (sign up and sign up with Google).

How to Design a Sign Up Web Screen

Step 1 – select a frame.

Firstly, I'll open the frame I'll be using. For this design, I'll be using the desktop frame (1440 x 1024).

To open a frame, go to the tools panel on the top left-hand corner of your screen. A panel with different kinds of frame types and sizes will come up.

Open the Desktop section and choose "Desktop" (1440 x 1024). The frame will appear on your screen, and you can start designing.

Step 2 – Add Grid Styles

I like using grids for arrangement and consistency in my designs, so I'll add a grid layout to the frame.

In the Rayna UI Design System, there are already existing grid styles so I can just choose one. To add a grid style, go to the panel on your right, and click on the 4-block menu on the layout grid section.

A list of different grid styles on the design system will come up, and you can choose any which corresponds with the kind of screen you're designing for.

Since I'm designing with a desktop frame, I'll choose Large .

You can detach instance to see the specifications of the grid style you chose. To detach instance, click on the detach icon next to the eye icon on the layout grid section.

You can now see the specifications for the grid style you chose. Since I chose Large , the grid specifications are:

• Count – 12, using columns
• Colour – F4BBAE, with opacity set to 20%
• Type – Stretch
• Width – Auto
• Margin – 112
• Gutter – 32

Step 3 – Add Content

I'll go ahead to start adding content to the screen. I'll use a text to represent my logo – Ketusha.

You can also control text styles and sizes on the design system. To do that, go to the Text panel on the left hand side of your screen.

Following the same format, I typed a heading for the form called "Sign Up".

Earlier, I suggested that you copy the icons, buttons, and input fields samples from the design system file, so you can use them easily while designing. Now, I'm going to paste the input field sample I copied in my frame.

Since I want the input field to be longer, I'll elongate it slightly to 400 width. It was previously 375 width.

Next, I'll structure the input field to how I want it to look like – without icons.

Next, I'll edit the label to the label I want for my design.

Next, I'll just duplicate the input field until I'm satisfied, and also edit all the labels.

Next, I'll add the buttons to the screen.

I'll add the "Sign up with Google" button, so the user can have different options for signing up on the platform.

Next, I'll try to paste the google icon inside the "Sign up with Google" frame but that might not be possible.

To be able to paste and replace an item inside the selection, I'll have to detach the instance. To do this, right click on the item you're trying to replace. A list of options will come up. Click on "detach instance".

After that, right click on the icon again, and "paste to replace".

The icon will be replaced instantly.

We just created a sign up page using the Rayna UI Design System!

Keep in mind that using a design system doesn't mean you cannot be creative and add your own flair. You can add your own style and creativity as much as you'd like as you go.

Using design systems is a necessary skill every designer and developer should cultivate.

Design systems are a critical component of modern product design and development, fostering collaboration, efficiency, and innovation.

Thank you for reading!

I'm an avid reader and I love art. I appreciate people that are taking little, little steps to be better in what they do; it inspires me.

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Featured Topics

Design systems

Engineering

Explore topics.

• Accessibility
• Behind the scenes
• Brainstorming
• Career & education
• Collaboration
• Design thinking
• Diagramming
• Infrastructure
• Localization
• Plugins & tooling
• Product management
• Product updates
• Productivity
• Profiles & interviews
• Prototyping
• Quality & performance
• Social impact
• The Long & Short of It
• Thought leadership
• Tips & inspiration
• Wireframing

Design systems 101: What is a design system?

What exactly is a design system?

Why use a design system, a brief history of design systems.

• Do you need a design system?

Understand the basics of design systems, what they are, how they work, and how they can change the way you design.

Design systems are often the unsung heroes of the products we use every day—from mobile apps and websites to the interfaces on television screens and car dashboards. They serve as the DNA for product design, encoding the principles and elements that define the very experience users interact with. Colors and icons convey meaning. Buttons are implemented with a consistent size and shape. Language is clear and understandable. If your design system does its job well, your end users hopefully don't spend too much time thinking about it at all.

Without a design system, you may find yourself in a crisis of inconsistency— navigating a maze where every turn could lead to confusion, brand dilution, or user frustration. In this series, we’ll walk you through the basics of design systems, dissect what makes them so essential, and guide you through crafting one that not only elevates your digital presence, but also protects it against the spread of design disarray.

This series builds on our Introduction to design systems course , where we cover design systems basics. You can also watch it on YouTube .

At its core, a design system is a set of building blocks and standards that help keep the look and feel of products and experiences consistent. Think of it as a blueprint, offering a unified language and structured framework that guides teams through the complex process of creating digital products. A design system can assist in reducing the amount of time spent recreating elements and patterns while designing and building products and interfaces at scale.

Components of a design system

You can think of hierarchy in design systems like this:

1. Design system

This top-level container is your overarching guidance, an ever-evolving foundational collection of resources and processes for your product ecosystem. It can include technical specs, design tokens, documentation, and best practices; it can also include core principles and processes to guide UX design decisions and product development.

Component versus pattern libraries

While both are integral to design systems, component libraries focus on UI elements like buttons and input fields, whereas pattern libraries address broader design solutions like navigation flows or data display.

2. Component and pattern libraries

These are reusable visual elements and interaction patterns that inform the common interface and behaviors of your product. They can include templates, layouts, interaction patterns, code snippets, and components—supported by detailed documentation.

Distinguishing between design systems and style guides

While often used interchangeably, design systems are more holistic, including coding standards and usability, while a style guide is a subset focusing primarily on visual elements like colors, typography, and imagery.

3. Foundational elements

These set the visual language, including the appearance of elements and the overall voice and tone of the product, such as color and typography. They also commonly include icons, logos, illustrations, and your accessibility and brand guidelines.

Design systems and UX: More than just aesthetics

It’s a common myth that design systems stifle aesthetics, limiting designers’ creativity and enforcing blanket homogeneity across designs. Design systems support designers by solving for repeatable patterns and freeing them up to solve other challenges. By using a design system— shared and maintained in Figma —designers can reuse consistent components, set up variants to seamlessly switch between modes and screen sizes, all without having to copy and paste the same designs over and over again. Updates can be made in one place and propagated across the system, keeping everyone on the same page. That way, designers are free to shift their attention to the next problem, or go deeper on another, and ultimately create more intuitive, accessible, and enjoyable experiences.

Designer Advocate Ana Boyer debunks six myths that may be holding you back from embracing design systems.

The impact of a design system lies in its ability to streamline workflows, ensure consistency across a product, and foster collaboration among cross-functional teams. Whether starting small or scaling across multiple platforms , a design system can enable a team to do more with less—not just when it comes to designing features, but also when building the real deal.

Read more about how Razorpay sharpened developer workflows through a conversation with some of their core team .

A design system is a single source of truth that reduces design redundancy and accelerates the development process . By using the design system, designers spend less time remaking components, and instead pull from a library of brand-approved, development-friendly options to swiftly build out designs. When components are designed with code, tokens, and animation presets, developers can translate them into functional, accessible code, in a fraction of the time. Companies who leverage design systems have witnessed a transformation in their product development lifecycle, achieving faster time-to-market and a cohesive user experience.

For new designers, a design system can serve as an onboarding tool, educating them on the product and principles, and enabling them to contribute sooner. As the system matures, it can provide teams with a shared vision and language that leads to better understanding and more consistent products. This, in turn, can increase trust with the people using your product, leading to a more engaged and loyal customer base over time.

The first noted mention of ‘systems’ or ‘patterns’ in use was at NATO Software Engineering Conference in the late 1960s, credited mainly to Christopher Alexander. His book “A Pattern Language,” published along with Murray Silverstein and Sara Ishikawa, discusses the interconnected patterns in architecture and is considered to be the origins of what we know today as “design systems.”

The concept of design systems has matured alongside technology itself. Design systems trace their roots to the early days of graphic design and print media, where style guides and typographic standards first introduced the idea of systematic design. As branding became vital for businesses in the mid-20th century, the need for consistent identity led to comprehensive brand guidelines.

With the digital revolution , the principles of these systems were translated from paper to pixels, growing in complexity to match the sprawling web and burgeoning app market. Giants like Apple in 1987, followed by Google, IBM, and Microsoft, pioneered comprehensive design languages that would dictate the look and feel of countless user interfaces. These systems were crafted not just for aesthetic unity but for practicality, offering clear documentation and reusable patterns to speed up development and streamline UI design, addressing the burgeoning needs of digital product teams.

In 2006, Yahoo! released the Yahoo! Design Pattern Library and Yahoo! User Interface Library ( YUI ), which sparked mainstream interest in pattern languages. Google’s Material Design was the first to be a self-proclaimed “design language” in 2014. ( Wikipedia )

The NASA Graphics Standard Manual , issued in January 1976 with an introduction by NASA Administrator Richard Truly.

The introduction of Brad Frost’s atomic design methodology in 2013 was a pivotal moment, redefining the structure of design systems. This approach not only revolutionized how we think about UI components, organizing them into a clear hierarchy from atoms to molecules to organisms, but provided a shared vocabulary for design and development teams. Just one year prior, I was also beginning my own exploration into systematic design, sparked by experiences with the Twitter Bootstrap framework and insights gained from industry conferences. Influenced by writings and talks by Bryan Haggerty, Laura Kalbag, and Josh Clark, I recognized the necessity for a systematic approach that could adapt to the rapidly changing landscape of device platforms and little glowing rectangles . Drawing inspiration from graphic standards manuals of years past and frameworks like Bootstrap and Zurb Foundation , I began rallying a group of my co-workers around this idea of creating standards, reusable assets, and documentation—that together would later become my first of many design systems to come.

Rune Madsen published a history of design systems as part of his course Programming Design Systems .

This journey reflects broader trends in the field, from the creation of pattern libraries in the early 2000s to the adoption of responsive design practices. These milestones underscore the significance of design systems as indispensable components of modern digital toolkits. Today, design systems are comprehensive resources that guide the creation of digital products, ensuring they are not only visually cohesive but also intuitively usable across various devices and platforms. This evolution from rudimentary guidelines to sophisticated frameworks illustrates the dynamic interplay between technology and design, marking a continuous quest for efficiency, consistency, and innovation.

How do you know if you need a design system?

Figma Designer Advocate Chad Bergman and Product Manager Jacob Miller host Building Blocks, a design systems office hours. Watch past episodes on YouTube .

One size does not fit all

As you go through your design systems journey, keep in mind that there is no one design system that fits all. Different companies have different needs, which require different solutions.

Pinpointing the perfect moment to implement a design system isn’t an exact science. Instead, it’s a strategic choice informed by a blend of benefits, potential challenges, and the unique hurdles your organization faces. So when might a design system actually be the right decision?

The decision to adopt a design system should be driven by specific needs:

Check for inconsistency

Scrutinize your product’s look and feel across different platforms. If you find jarring inconsistencies or a brand identity that loses its thread from one experience to the next, it’s a sign that you may need a design system.

Consider diverse themes or platforms

Does your product need to shift seamlessly between themes (like a dark and light mode, or different brands) or fit a variety of device platforms and screen sizes? A design system could be the key to managing this complexity with grace.

Cut down on redundancy

Take stock of any repetitive design tasks or recurring issues that eat up your team’s time. Standardized components from a design system can streamline your process.

Enhance communication

Look at how your team communicates about design. Are there misunderstandings, or do you waste time clarifying design elements? A shared design language can iron out these wrinkles.

Ease onboarding

Consider the onboarding process for new team members. A robust design system can make this transition faster and more effective, getting everyone to contribute sooner.

Boost lifecycle efficiency

Reflect on your product’s lifecycle. If there’s room to speed up design, prototyping, and updates, a design system can be a catalyst for efficiency, enhancing every stage of product development.

Before you commit, evaluate your team’s current workflow, the user experience of your product, and the specific problems that need solving. A thorough discussion with your team will help to pinpoint the necessity and potential scope of a design system tailored to your needs.

Read how Headspace built a design system that breathes , utilizing features like variables in Figma to optimize for scale.

Anticipating challenges in implementing a design system

While design systems offer a multitude of benefits, they are not without their challenges. Understanding these hurdles can prepare you for a smoother journey toward a more cohesive and efficient design practice.

Ongoing maintenance

Firstly, akin to any product, a design system demands continuous attention and effort—not just for its initial setup but also for its maintenance. Just like great products, which continue to evolve, a design system is never truly done. Keeping a design system updated and relevant requires a dedicated stream of resources and time, making it a long-term commitment.

Delayed gratification

The impact of a design system is profound, yet it unfolds over time. This slow reveal of benefits can sometimes hinder buy-in from leadership, particularly if it diverts resources or focus from immediate project goals. The initial investment, both in terms of time and potentially expanding your team, might be significant before the tangible rewards become evident.

Resource allocation

Allocating the right resources is a balancing act. Beyond the initial development, design systems need ongoing input from designers, developers, and product managers to remain effective. This might mean rethinking priorities or even expanding your team to ensure the design system doesn’t stagnate.

Cultural transformation

Perhaps one of the subtler yet more complex challenges is the cultural shift required to integrate a design system across an organization. It’s not just about adopting a new set of tools or processes; it’s about changing how teams communicate, collaborate, and conceive their work. To truly embed a design system into the fabric of your organization, you’ll need champions—advocates who are committed to its success and can persuade others of its value. Importantly, as the system continues to grow and evolve, it should mirror the changing needs and contributions of its community, making it a living resource, shaped by those it serves.

Socializing the system

Getting everyone on board with a design system can feel like an uphill climb . It involves educating and convincing various stakeholders of its long-term value, which requires clear communication, demonstrations of its impact, and a strategy for widespread adoption. This often means creating and nurturing a community around the design system, one that spans different departments and roles.

By acknowledging these challenges upfront and strategizing on how to address them, you can set the stage for a more effective and embraced design system. The journey may be complex, but the destination—a more cohesive, efficient, and scalable design practice—is well worth the effort.

Thinking about making the switch? Check out Designer Advocate Clara Ujiie’s “ An insider’s guide to a seamless Figma migration ” for a plethora of resources, tips, and tools for transitioning to Figma.

Next steps in your design systems journey

Implementing a design system is not just about creating a set of standards; it’s about building a culture of consistency, collaboration, and efficiency. Starting your design system journey is exciting, and there’s no one-size-fits-all approach. If you’re not ready for a big leap, small updates can still make a big difference. Check out our other design systems articles , our Introduction to design systems course , and resources such as open design systems on Figma Community.

✉️ Sign up for The Long & Short of It, our editorial newsletter for more design systems tips and ideas!

This is an ongoing series, with much more to come. What else would you like to learn about? Tweet me and @figma with your questions. This series builds on our Introduction to design systems course, which you can also watch on YouTube .

Learn more about how Figma helps teams of all sizes drive consistency, scale designs, and maintain parity with development using our design systems features or request a demo .

Artwork by Cynthia Alfonso .

Subscribe to Figma’s editorial newsletter

By clicking “Submit” you agree to our TOS and Privacy Policy .

Related articles

Creating coherence: How Spotify’s design system goes beyond platforms

Design Manager Juli Sombat sheds light on how a need for more cohesion led Spotify’s design systems team to take a cross-platform approach to components.

The future of design systems is accessible

In the third part of our series, we talk to design system and accessibility experts about making inclusive systems a top priority. Previously, we covered complexity and automation .

How Pinterest’s design systems team measures adoption

The Gestalt team tells us how they used Figma’s REST API to create FigStats, a dashboard for visualizing component usage.

Create and collaborate with Figma

• Apr 12, 2022

Around The Artifacts Of Design Systems (Case Study)

• 19 min read
• Workflow , Case Studies , Design Systems
• Share on Twitter ,  LinkedIn

About The Author

Dan is a Design Advocate for zeroheight , a design system documentation product, drawing on his experience at Auto Trader in the UK, looking after the design … More about Dan ↬

Email Newsletter

Weekly tips on front-end & UX . Trusted by 200,000+ folks.

It can be easy to assume that everyone needs a design system, that you can pick one off the shelf or put one together pretty quickly, and your problems are over. As with many things on the web, your mileage may vary. What I want to share with you are some observations from the last few years, not just from myself but from people that have been part of our design systems journey at Auto Trader.

We started in a very different place to where we find ourselves today: loads of inconsistencies, duplication, communication that needed to be improved, and ultimately the quality and speed of output weren’t what they should be. Our practices today have dramatically improved on so many fronts, one aspect being our design system.

The Problem Space

There are so many really great articles out there about design systems; how to design and or code them, but let’s step back to the beginning.

What problems do you feel that a design system might address? Why do you think a design system might ameliorate them?

If you’re clear on your specific issues, it helps not only inform your solution but help with a narrative that might resonate with stakeholders.

Even at this early stage, language matters . What do you think a design system is? As part of your proposed solution, is it actually a style guide, a component library, a design library, or a more well-rounded system? You might not need something all singing and dancing for your project or organization. Starting with one aspect doesn’t mean you can’t evolve into something else later!

So, you have a sense at this stage that you may be on a greenfield project — or as we were, adding in the foundations to a large traffic site that already existed — and you may have a view on what form your design system might take. Before diving in and starting to plan anything out, we can be clearer with ourselves about where the benefits and the risks might be.

You could start as simply as making lists:

You could take this further if in your organization you need a business case and use a SWOT Analysis as a way to form something robust. This allows you to look at the strengths, weaknesses, opportunities, and risks, and it is often used in business planning. It doesn’t have to be a labored task, but it can help to look at your potential system from other viewpoints.

Mitigating avoidable risks is important. Being clear with yourself about what could go wrong, and what you can do about it helps to make your solution more robust . On the flip side, the potential benefits can lead us into thinking about what our definition of success might look like — our “north star”. What good might look like for your system?

From the vision piece, you need to be able to start somewhere, which leads us to more avenues of questioning:

What kind of a system helps you to progress in a sustainable way for the needs and resources you have? Could a style guide be all you need? Is some form of a component library enough to get you working in a better way? What current and potential audiences might the system have?

You may start with it being a design project to address consistency across a design team, but acknowledging that for it to evolve it needs a wider range of skills which is a kind of debt that will be built-in. In some cases, much as we did, an initial solution may make sense to be replaced by something else further down the line. Not being wedded to a particular solution can be hard, especially if it’s “your baby”, but going back to that north star, and the purpose of the system gives us a healthy reminder of when it can be time to let go.

What To Measure?

Many things may be measurable from the sentiment of attitudes towards the system and experience using it through to the number of components in the system and actually used on the site (or in your app). Actually, looking at where a given component is used can have some useful benefits when it comes to later stages of working with your system, as it helps to gauge the risk of a proposed change, and where you might see some impact.

From your picture of what success looks like, are there measurables that can help tell your story to stakeholders or that give you a sense of how well you’re doing? While in our scenario, we didn’t set out a list of KPIs; we were clear that it should power the majority of the consumer website and look into how or when our native apps may work with it. On the back of our refresh project, we’d be taking care of most of the site outside of focus consumer journeys where our team would act more as support for the teams around them. That gave us confidence that if we were able to deliver output to the site on a regular basis, we would be able to meet that vision we’d set out.

You might often hear the “fail fast, fail often” mantra thrown around, but in the early days of validating how your design system might work, this can be invaluable. “

Assuming that you have a well-rounded design system, you may have designers, content designers, test engineers, front-end and back-end developers, product people, delivery folks — all potentially finding this as a part of their lives. Again, the language that we use matters to ensure there’s a shared understanding across domains.

What’s In A Name?

One key thing that helped us was naming things clearly across disciplines, so we’re referring to the same thing and being clear on its intent. That purpose transcends specialisms and helps give clarity to what an object in your design system is for , what problem it solves, or what role it plays. That clarity of purpose pays off in many ways over time.

Using a well-worn example, a button is a button, isn’t it? Well, not always.

While the visual asset may have the appearance of a button, when it comes to applying it to code, is this a button tag? Is it a link that looks like a button (which is a debate in itself!)? In your framework, is it an internal router link?

There is room for debate, but we ended up in a place where the visual asset gave us the language to talk about it, and the technical execution may differ based on a use case . We’re all now talking about buttons, even when the actual code differs.

We have a component, originally called the “Promo Section”; it was intended for calling out key parts of a value proposition. The following example shows where intent and language differ — as it’s now become a more generic content block. The work now is to look at use cases in the wild and choose as a team: whether we accept that’s what it is and capture it or look at whether it needs to be more than one component based on those use cases.

There’s a lot to think about, and we’ve not even touched upon the design files or what your code might look like yet!

People-Powered

You might start as a team of one or have a group around you to make this happen, but defining roles and responsibilities early on is important. Having an amazing Figma library is great, but if it doesn’t at some point become code and have a release process, it’s a collection of pictures of what could be. Underneath a lot of what a design system appears to be is a mechanism for fostering better communication and understanding . A new system might start from any discipline, but it needs others to be truly impactful.

Not everyone is fortunate enough to have dedicated time or resources to make a design system, so it’s often a balance between how much time it might need to produce some value. You might not be able to start with the ideal system you have in mind but can find a way of communicating the value proposition you believe the design system has. Going back to the problem space, what might be a great example to start with? Looking at your “north star”, what demonstrates the potential through a hack or experiment?

Ownership And Community

I’ve felt less of an owner of the system and increasingly more of a shepherd. The system isn’t mine — it’s shared. The responsibility of ensuring it persists ideally shouldn’t rest on any individual, as if things go well, this design system will be a major asset to your organization.

Designing the “people bit” and structures around the system itself pays off. Initially, we kept those directly involved to a minimum, through availability and, in part, through choice. There were some fundamental decisions to make, and test out, and try to break.

With some great support from our engineering colleagues, we both worked on output (making the first landing pages) as well as road-testing (and breaking) the design system mechanism itself. Alongside, we’d start talking more broadly around the business about what the design system was, how it was different from previous projects, and to set and manage some expectations.

As we weren’t just making the design system but working through refreshing the site, we worked in the open, with our plan and breakdown on a board , so whenever people came by our area of the office, we could talk them through it and get some initial feedback. At that early stage, we also talked through the refresh of the site (and so the design system) with departments that might not normally be in the loop.

Taking time to explain to different audiences, in their domain language, what it is and why it matters can help you to gain advocates, and the advocacy model can help foster a community around the system, as it grows and matures.

Having people that aren’t a part of the immediate team enthuse about it, helps spread that word on your behalf. “

In the earlier days, having “good news stories” or case studies around what the design system has helped us to achieve and amplify the messaging you’re trying to spread. In our case, we were able to be far more reactive with content, because of the fact our design system had solved problems that mapped to that kind of project. We could then have quick conversations focused on what the content was trying to achieve , and we were able to get something live far quicker than we previously had done, and to the same quality as other parts of the site.

Creating a community around the design system can’t be forced. They don’t just happen and can take time to nurture. Some of helping it along is that sense of shared ownership, which can mean many things, including being able to actively contribute or participate. How can people outside the immediate team around the system propose new additions or changes? Is there a clear feedback mechanism? One of the best examples I remember seeing was in GDS ( Gov.uk Design System ).

There’s some inherent tension, as there’s a balance between community and engagement , contribution and a governance process that has rules and processes. How this coalesces around something that works for you and your circumstances will differ. Governance: how you define responsibilities and workflows can become as much established through the community as imposed upon it. Having something as a starting point that can be critiqued is often easier than a blank canvas!

Note : Although it’s a few years old, it’s worth checking out Brad’s article from 2019 .

While there’s a huge amount of care and effort involved in creating and maintaining, everything in the design system needs to be up for debate and a challenge from the community you aim to form around it. All of this helps with engagement, but also helps to make what’s in the system more robust; whether that’s through design changes, code improvements, or just providing better documentation.

It’s about supporting people to understand that the design system is not something ingrained in stone but a way of describing and facilitating solutions to problems. “

Workflow, Communication And Evolution

This flex between what a specialism needs within its domain and what allows for broad communication is really important. How your work goes from inception to somehow appearing on a live website is big stuff. This workflow doesn’t yet dictate the tooling or presentation of your system but underpins its value .

You might start mapping out a workflow like this:

• A need emerges;
• The team (TBC) discusses it, and the outcome of this forms a proposal;
• This proposal is worked on and taken to a crit session;
• Once complete, the component is reviewed and made available to the system;
• Once tested, it can be used;
• When used in-situ, gather feedback and see how it performs “in the wild”.

Considering how to manage change isn’t always easy. We chose to start our components in an opinionated way; they’d do one job and wouldn’t include much logic. While you could craft them in a more futureproof way, you can’t predict what change is needed, but enabling and facilitating change is an important part of any design system. A new bit of content needs to be passed in a different style of a call to action.

How should we not just update the component itself but its uses all over the site? Baking in some assumptions, that changes are just possible but actually desirable, is really important. How do you roll out a breaking change across your codebase? If you update your component in your design tool of choice, what knock-on effects are there?

Each item in a proposed workflow might have the depth to be explored. For us, we wanted to make it feel like a “push” when we updated a component, so the live site would always be up to date — every change would be versioned and released immediately to the site like we “pushed” it out. Under the hood, we use conventional commits to automatically trigger versioning of our code, which runs our build processes that include automated tests.

Once pulled into an app in one of our React apps, future builds of the design system would trigger upstream builds for that app, so every intentional change is pushed out to the site, and in theory, the components should always be up to date, unless a developer specifically needs otherwise. Explaining that process hopes to illustrate the simple workflow intent , to “feel like a push” actually involved a chunk of engineering to ensure pipelines and build process worked as we’d expect. We also have the ability to flag a potentially breaking change, as a beta release to manually pull into apps to validate before making that change permanent.

Understanding Change And Evolution

Some components might start off looking or functioning in similar ways, but how might this play out over time? It might make sense to build them from a shared look and feel or set of functionality. A better way to solve a given problem emerges, and so this link to another component no longer makes sense.

There’s an element of understanding that we bake in potential tech or design debt into the components we create. While there’s a contract in the code between your component and its context of use that needs to be preserved, the way it’s constructed can change . So, the balance lies between not over-engineering every component when it’s created and considering how change might happen with a sense of how scenarios might play out.

Back to our example of the Promo Section I mentioned earlier. This has been used for more than its initial intent, but we can learn from that. There are some options we can explore:

Do we keep it as it is and expand on its intended purpose? Do we look at what use cases have emerged and split this into multiple components? Is it something that needs reevaluating entirely?

That second option is worth exploring. Maybe this split into two components means that they still look the same? If they do, maybe they use some of the same mark-up and styles and share that common base. Following this through, we might have better or different ways of solving problems these components cause today. Using the same base is a practical short-term solution, and realistically, we can’t know if we’ll ever change them in the future. If one diverges its presentation, have we baked in some debt, or do we accept that and factor that into future changes?

The Source of Truth and Making Proposals

One early principle we had was that live code trumps the design. That’s a controversial statement in some circles, so I’ll explain: our users are actively using and experiencing our design system components. As good as the work and thinking are in your design tool, it’s unrealized potential until it makes its way through to the live website. Keeping naming, structure, and change tight prevents design work from diverging too far too soon for the system. That doesn’t mean that play and experimentation are in any way limited, just that they should exist outside of the system until the concept is ready to promote. And so, there’s another aspect of change, when change is needed or new components are required.

We’ve done some work around our proposal structure (which as I write is in its early days), but so far so good. A proposal starts by recognizing the component’s purpose, i.e. what problem it was created to solve . That actually starts the basics of the documentation for it too, and capturing that early. We have regular open-invite design system-focused sessions, where proposals can be discussed and challenged, and from that designs can be critiqued, and code could be submitted as pull requests. As a collective, we try not to make the process too labored but also hold a proposal to some level of rigor.

A proposal might include some of these:

• Purpose/Intent What problem does the suggested component solve?
• Use Cases Often a component would be proposed to the design system if it was needed in more than one place. What use(s) does it have, and how does the use case map to its intended purpose?
• Anatomy What are the elements, spacing units, and typography that make the component? (Early experiments with this seem useful for us.)
• Related Components If this isn’t a fit for what you want, what others do similar jobs?

What we’ve found is that this actually becomes part of the documentation, before a component is actually added to the system!

In the early days or thinking about our approach, we also had the notion of ‘lenses’ to look at components/design patterns. Different ways to turn the work around in your mind and see them from different angles.

Some might be reminders, some technical, some not:

By no means, this is an exhaustive list, but it might help with how you can think about your components differently. Think of some useful prompts of your own , based on how your site works — forming that together might be a great way to bring some different disciplines together!

There’s a lot to consider, but it doesn’t have to all be done at the beginning. Governance, workflow, communication, and community are all really important and, more often than not, need to be considered as a part of the design system itself. These are the things that enable contributions and manage change . It allows for a challenge to establish patterns as much as it helps roll out work using a raft of solved problems. Acknowledging when decisions will lead to tech/design debt and being clear on what level of debt is acceptable might not be something that’s clear from the beginning but discussing it helps with making informed decisions.

Some form of design system might be a part of your work from a lone freelancer to a massive multi-department organization, so your mileage may vary, but hopefully, you’ll look a little broader when starting a design system. The aspects around the community and the kinds of debt you can accrue might resonate across all kinds of systems .

Like many things, a design system isn’t ever a finished thing — it’s a journey. How we go about that journey can affect the things we produce along the way. While we’ve learned a lot, there’s still a lot further to go. There will always be new challenges, and change is good.

As Ryan DeBeasi said in his article:

“A design system isn’t just code, or designs, or documentation. It’s all of these things, plus relationships between the people who make the system and the people who use it.” — Ryan DeBeasi, Design Systems Are About Relationships

I look forward to hearing how you get on, and how you make these aspects around the artifacts of your design systems work for you!

Smashing Newsletter

Tips on front-end & UX, delivered weekly in your inbox. Just the things you can actually use.

Front-End & UX Workshops, Online

With practical takeaways, live sessions, video recordings and a friendly Q&A.

TypeScript in 50 Lessons

Everything TypeScript, with code walkthroughs and examples. And other printed books.

• Mini Projects
• Web Development
• Career Guidance
• Developer Essentials
• Data Structures and Algorithms
• Programming Languages
• Crio Community
• In the News

A Comprehensive Guide to System Design

In the dynamic landscape of software engineering, system design stands as a pivotal phase that lays the foundation for robust and scalable applications. Mastering the art of system design involves understanding intricate design concepts that fuel innovation and ensure seamless functionality. In this comprehensive guide, we'll delve into the world of system design, explore its core concepts, and equip you with the knowledge to excel in this crucial aspect of software engineering.

Table of Contents

What is system design, key concepts in system design, understanding the components of system design, the process of system design, best practices for effective system design, case studies of successful system designs.

At its essence, system design is the blueprint that transforms concepts and requirements into tangible software structures. It is the strategic process of defining the architecture, components, and interactions of a software system to fulfill specific functional and non-functional requirements. It involves translating high-level concepts into concrete designs that can be implemented and executed efficiently.

Modularity and Abstraction: Breaking down a complex system into modular components promotes reusability, ease of maintenance, and efficient collaboration among developers.

Coupling and Cohesion: Striking the right balance between component interdependence (coupling) and the functional relatedness within a component (cohesion) is crucial for a well-structured system.

Architectural Patterns: Different architectural patterns, such as client-server, microservices , and monolithic, offer guidelines for organizing components and handling interactions.

Data Flow and Communication: Designing effective data flow and communication mechanisms ensures seamless information exchange between system components.

Trade-offs and Constraints: System designers often face trade-offs between factors like performance, cost, and development time. Understanding these trade-offs is vital to making informed decisions.

A well-crafted software system is a composition of carefully crafted components, each serving a specific purpose and collaborating seamlessly to bring a digital vision to life. Every component is designed and precisely placed to ensure smooth operation and optimal performance. These components encompass a spectrum of functionalities, from managing data and user interactions to securing sensitive information and facilitating communication between different parts of the system.

Let's take a closer look at these fundamental components that form the backbone of a well-structured system design:

Components and Modules: Each component encapsulates a specific functionality, allowing for modularity and reusability. This means that developers can focus on refining and enhancing individual components without disrupting the entire system.

Data Management: Data management involves designing databases , defining schemas, and implementing strategies for data storage, retrieval, and maintenance. A well-designed data management component ensures that information flows seamlessly through the system, enabling accurate and timely decision-making.

User Interfaces: A user interface component involves creating intuitive, aesthetically pleasing, and user-friendly interfaces that facilitate smooth interactions. From buttons and menus to forms and visual elements, a well-designed user interface component enhances user experience, making it easy for users to navigate and engage with the application.

Communication Protocols: In a world where systems often need to talk to each other, communication protocols act as the language that enables effective dialogue. These protocols define the rules and conventions for data exchange between different components or even between separate systems. Whether it's a web service requesting information from a server or two modules sharing critical data, a robust communication protocol ensures that information is transmitted accurately and efficiently.

Security Measures: With the increasing importance of data privacy and cybersecurity, a dedicated security component is essential. This component encompasses encryption, authentication, access control, and other measures to safeguard sensitive information and prevent unauthorized access. A well-designed security component shields the software system from potential threats and vulnerabilities.

System design is a structured process that involves several stages. It involves a methodical process of conceptualization, refinement, and construction. This process serves as the blueprint for transforming abstract ideas into tangible and functional software systems.

Now, let's delve into the phases that constitute the process of system design:

Requirements Analysis : It is the foundation upon which the entire structure rests. This involves understanding user needs, functional specifications, and potential challenges to ensure that the design aligns with the project's goals.

Architectural Design : The architectural design phase shapes the high-level structure of the software. Here, designers determine the major components, their relationships, and the overall flow of information. This stage lays the groundwork for the subsequent design steps.

Component Design : The component design phase adds depth to the narrative. Designers delve into the specifics of each module, determining how they function and interact. This involves defining interfaces, algorithms, and internal mechanisms that contribute to the overall narrative of the software.

Database Design : The database design phase sculpts the data storage and retrieval mechanisms. Designers create a blueprint for organizing data, defining tables, relationships, and access methods. This step ensures that data is managed efficiently and can be accessed when needed.

User Interface Design : Designers craft user interfaces that are visually appealing and user-friendly. They create layouts, select fonts, and design interactive elements that enhance the user experience.

Integration and Testing : The integration and testing phase brings all the components together. System designers integrate different modules, test their interactions, and identify and rectify any issues. This step ensures that the entire system functions seamlessly as a unified entity.

• Thoroughly understand user needs and requirements before diving into design.
• Create modular components to enhance reusability and maintainability.
• Maintain comprehensive documentation to aid understanding and future development.
• Develop prototypes to validate design concepts and gather user feedback.
• Keep It Simple. Strive for simplicity in design to reduce complexity and improve system clarity.

Let's dive into some fascinating real-world examples that showcase how the principles of system design have been applied to create impressive and impactful digital experiences. These case studies provide a glimpse into how thoughtful design choices can lead to revolutionary solutions and redefine entire industries.

Netflix Streaming Service

Netflix, the world's leading streaming platform, is a prime example of successful system design. Behind the scenes, Netflix uses a microservices-based architecture . Think of this as a city with different neighborhoods, each serving a unique purpose. These microservices allow Netflix to deliver content seamlessly to millions of users worldwide. Just like each neighborhood has its own shops and services, each microservice handles a specific task, like user authentication or video streaming. This modular approach ensures scalability, easy maintenance, and quick updates, contributing to the smooth streaming experience that millions enjoy daily.

Uber's Real-time Matching

Uber's success is built on a robust system design that enables real-time matching of drivers and riders. Imagine a magic matchmaking spell that instantly connects people needing a ride with available drivers. Uber's system uses advanced algorithms and location data to make this happen. It's like having a digital GPS guiding drivers to their passengers in real-time. This efficient system design ensures that users get reliable rides quickly, making urban transportation more convenient and accessible.

Amazon Web Services (AWS)

Amazon Web Services (AWS) is a game-changing example of system design in the cloud computing world. Imagine having a supercharged toolbox of digital tools and resources that you can access from anywhere. AWS provides this by offering a wide range of services, like storage, computing power, and databases , through the cloud. It's like having a virtual workshop where developers can build and deploy applications without worrying about the hardware. AWS's scalable and flexible system design has transformed how businesses manage their IT infrastructure, enabling startups and large enterprises alike to innovate and grow rapidly.

System design is the backbone of software engineering, shaping the way applications function, scale, and deliver value to users. By understanding the core concepts, following a systematic design process, and considering key factors, developers can create software systems that meet user expectations and adapt to changing technological landscapes. Learning system design empowers software engineers to craft innovative, reliable, and efficient solutions that drive the digital world forward.

Written by Amani Undru

Top Skills to Land Tech Roles at Global MNCs in India

Empowering the Future: Celebrating Developers of India

Accessibility in Design Systems and DesignOps

This is a case study about my experience of learning how to research, design and build accessible web components, then scale their impact through a design system.

Scaling accessibility and inclusive design across the largest bank in Canada, RBC. 

Rather than everyone individually fixing the same accessibility problems, a design platform enables an organization to propagate accessible components and documentation at scale. Requirements, standards and best practices are multiplied outwards saving time and money for product teams using the platform.

I spent 3 years helping the design platform team to ensure  RBC.design was built with accessibility and inclusion in mind.

RBC's design platform is a collaborative effort that leverages the wisdom of designers, and developers throughout the organization, working towards the common vision of unifying design and front-end development across RBC. The platform is currently used by various product teams across RBC; the main consumers are designers, developers and quality engineers.

Welcome To scaleyourapp.com

We discuss the latest trends in technology, computer science, application development, game development & anything & everything geeky. Subscribe to our newsletter or connect with us on social media.

• Architecture
• Backend Engineering
• Career & Learning
• Distributed Systems
• Product Development
• Real World Architecture
• Software Design
• System Design
• Uncategorized

Trending News

• System Design Case Study #5: In-Memory Storage & In-Memory Databases – Storing Application Data In-Memory To Achieve Sub-Second Response Latency
• System Design Case Study #4: How WalkMe Engineering Scaled their Stateful Service Leveraging Pub-Sub Mechanism
• Why Stack Overflow Picked Svelte for their Overflow AI Feature And the Website UI
• A Discussion on Stateless & Stateful Services (Managing User State on the Backend)
• System Design Case Study #3: How Discord Scaled Their Member Update Feature Benchmarking Different Data Structures

System Design Case Study #2: How GitHub Indexes Code For Blazing Fast Search & Retrieval

System design case study #1: exploring slack’s real-time messaging architecture.

In this blog post, I explore Slack’s real-time messaging architecture with a discussion on the architectural and system design concepts they leverage to scale and keep the latency low. 

The study will help us understand the intricacies of real-world web-scale architectures, enhancing our system design knowledge notably. 

With that being said, let’s get started. 

Slack’s Real-time Messaging Architecture

Slack sends millions of messages daily across millions of channels in real-time across the world. A Slack channel serves as a dedicated space for communication and collaboration among team members. Channels in Slack can be created for any project, topic or team.

The core Slack services, aka Servers, are written in Java. They are Channel Servers, Gateway Servers, Admin Servers and Presence Servers.

Image src: Slack

Channel Servers

Slack’s Channel Servers (CS) are stateful and in-memory. They hold channel information in-memory. Every Channel Server is mapped to a subset of Slack channels based on consistent hashing. At peak times, approx. 16 million channels are served per host. 

The channel ID is hashed and mapped to a unique server. Every Channel Server host receives and sends messages for the respective mapped channels. 

Consistent hash ring managers manage the consistent hash ring for the Channel Servers. They replace the unhealthy Channel Servers pretty quickly with the new Channel Server ready to handle traffic within 20 seconds. 

Two key things to note here :

1. The Channel Servers are stateful. They hold channel information in-memory. Why stateful and in-memory? Isn’t this a scalability bottleneck? If a Server node handling a certain client request with their specific information stored in-memory goes down, other cluster nodes can’t replace that node without the client realizing that the server went down.

2. The traffic is routed to different Channel Server nodes via consistent hashing.

Let’s discuss the first point. 

Stateful Services 

Slack Channel Servers hold channel information in-memory and are stateful to deliver messages to clients quickly and efficiently. Since the backend servers store the channel information in-memory, they don’t have to poll any external storage like a database to fetch information on every client request. This enables the service to quickly return the response to the clients, keeping the latency low.

Yes, this introduces some scalability challenges, such as since the information is stored in-memory, the need for augmenting the internal server memory arises as the channels and the clients increase over time. This makes scaling horizontally challenging. In addition, each Channel Server node is vulnerable to failures and data loss. If the node goes down, there is a risk of the client data being lost. 

This is a tradeoff Slack was willing to make to keep the latency low. However, not much information is given in the article on how they avert data loss, whether they use replication, take instance data backups, or use persistence storage plugged with the instances.

Leveraging Managed Cloud Services

If a business leverages managed services of a public cloud platform, the platform handles replication, backups and other necessary tasks to keep the service running, enabling the business to focus on building features as opposed to managing its infrastructure. This is the primary reason web-scale services migrate their infrastructure to public cloud platforms. 

Relevant Reads:   Twitter moved a part of their workload to the Google Cloud to free their resources of the effort that went into managing the on-prem infrastructure at the Twitter scale. Evernote Engineering originally managed their on-prem servers and network. But with the increasing popularity of the business, scaling the infrastructure, maintenance and upgrade became challenging. To focus on innovation and avert investment of resources in infra management, they migrated to Google Cloud .

Picking the Right Cloud Instance

Running in-memory memory-intensive operations ideally requires us to pick memory-optimized cloud instances. Memory-optimized instances provide a higher amount of RAM than other instance types. 

Cloud platforms provide different instances, such as storage-optimized, compute-optimized, memory-optimized, regular instances and such. Based on the use case requirements and resource usage patterns, we can pick the fitting one. 

Profiling, running performance tests and continuous monitoring of our stateful services help us understand the resource utilization patterns, including memory, storage and CPU consumption. 

Plugging Persistent Storage to the Instances

Along with a memory-optimized instance, we can also pick a persistence storage that we can attach to our cloud instance. Persistent storage ensures data availability and durability across system reboots, application restarts and hardware failures. 

Cloud providers provide persistent storage options such as AWS EBS (Elastic Block Storage), Azure Disk Storage and Google Cloud Persistent Disk to provide reliable and scalable storage for stateful services. 

Stateless and stateful are two common architectural patterns for designing microservices. It’s relatively easy to scale stateless microservices in contrast to stateful. Stay tuned for my next blog post, where I’ll discuss scaling stateful microservices.  You can subscribe to my newsletter if you wish to see the content slide into your inbox as soon as it is published.

Mapping Slack Channels to Channel Servers Based On Consistent Hashing

Every Channel Server is mapped to a subset of channels based on consistent hashing, and the hash ring managers manage the consistent hash ring.

Consistent hashing is a technique that is used to distribute data or traffic across a cluster of servers, ensuring minimum data rebalancing across the cluster nodes when a few nodes go down or are added to the cluster. This becomes vital for applications that need to scale up or down based on frequently changing traffic, like in a real-time messaging app.

Slack uses consistent hashing to route channel messages to different nodes in the cluster. Each channel has a unique ID, which is used as a key to hash to assign the channel to a unique node in the cluster. This ensures the messages for a given channel are handled by the same server, ensuring consistency and minimal network consumption. 

If we do not use consistent hashing and rather just regular hashing, adding or removing a few server nodes in the cluster would require recalculating hashes of all the channels. This would require a lot of data to be rebalanced between servers and disrupt the service for the users. 

Consistent hashing maps both the channels and the servers on a circular hash ring, using a hash function that produces a uniform distribution of values. To have a detailed read on consistent hashing, this is a good resource . 

Consistent hashing is leveraged by popular databases like Cassandra, Couchbase, VoldemortDB and DynamoDB to manage data distribution amongst nodes in the cluster. 

In addition, some of the web-scale services like Spotify uses consistent hashing to distribute the load of millions of users across their servers.  Akamai uses consistent hashing to map requests to the closest edge server in the CDN. Pinterest uses consistent hashing to store and retrieve billions of pins and boards across their distributed database. Discord uses consistent hashing to scale to 5,000,000 concurrent users.  

Consistent hashing is a valuable technique for building highly available, scalable, fault-tolerant distributed systems. 

Moving on to other core Slack services:

Gateway Servers 

Gateway Servers service is the interface between Slack clients and Channel Servers service. They are deployed in multiple cloud regions nearest to the end user, enabling a Slack client to quickly connect to a Gateway Server in the nearest cloud region. 

Gateway Servers are again stateful and in-memory, holding user information and web socket channel subscriptions. 

Presence Servers 

Presence Servers are in-memory tracking the online presence of users. This service powers the green presence dots in Slack clients. The users are hashed to individual Presence Servers. 

Admin Servers

Admin Servers are the interface between the Slack web app backend and Channel Servers. They are stateless and in-memory. 

Service Discovery

The Channel Servers are registered in a service discovery tool called Consul. Service discovery in distributed systems or microservices architecture facilitates automatically detecting other services in the network, facilitating scalable and resilient communication between them.

In a service cluster, nodes constantly scale up and down, and their IPs and other configurations change dynamically. Service discovery ensures all services can communicate with each other without manual configuration updation. 

Slack registers its Channel Servers in service discovery to keep track of the location and availability of each node. It becomes easy to manage them during auto-scaling, failures and service upgrades. 

Establishing a Connection With the Backend

Every Slack client keeps a persistent connection with the backend via web sockets. Web sockets enables Slack client and the server to establish a low-latency, bi-directional communication. This makes the technology fitting for real-time apps like chat apps, online games, etc. 

When the interaction between the client and the server is frequent, web sockets reduce the overhead of repeatedly establishing an HTTP connection. This helps with the reduced network bandwidth and other resource consumption. The data can be exchanged with lower latency than a regular HTTP connection being created and terminated repeatedly. 

When initiating a request, the client fetches the user token and the web socket connection info from the Webapp backend. This backend, written in Hacklang, hosts all the APIs called by the Slack clients. 

The information fetched from the Webapp backend includes the host names of the Gateway Server service and the token that authenticates the user to create a web socket connection. 

After fetching the information, the client hits the Envoy proxy at the nearest edge region. The Edge proxy forwards the request to the Gateway Server, which fetches the user information, including all the user’s channels from the Webapp and sends the first message to the client. 

The Gateway Server then subscribes to all the Channel Servers of the user based on consistent hashing. The connection is now ready to exchange messages in real time. 

The Envoy proxy service is used as a load balancer for different services and TLS termination in this setup.

Two key things to observe here:

• Why is a proxy service being used as a load balancer?
• Why isn’t the Webapp deployed at the edge as opposed to being in the main region to cut down latency further?

Using Proxy Service as a Load Balancing Solution

Envoy is an open-source, high-performance, cloud-native proxy server originally developed by Lyft. Slack leverages it to handle millions of concurrent connections . It can dynamically adjust the load across a cluster of servers based on various metrics such as latency, availability, etc. and is designed for cloud-native applications and service mesh architectures.

It also supports web sockets, facilitating secure communication by performing TLS termination and encryption between the client and the server. In addition, it can integrate with Consul, the service discovery service. 

Proxy services like Envoy can also be used as load balancers when there is a need to manage the incoming traffic in addition to providing additional proxy features such as caching, observability, security, etc. 

If proxies can be used as load balancers, why implement dedicated load balancers?

Proxy servers aren’t an alternative to dedicated load balancers. They have distinct characteristics and use cases and offer varying features and performance levels. 

For instance, if we need a proxy server in our system architecture and it can fulfill the load balancing requirements, we can deploy a proxy server to perform both functionalities.

In contrast, if we need a dedicated load balancer, we cannot replace it with a proxy service. It may not offer the range of features a dedicated load balancer has. 

Why isn’t the Webapp deployed at the edge to cut down latency further?

The Webapp is not a performance-critical component of Slack’s architecture. Most real-time messaging and interaction happens through web socket connections, which are handled by the Gateway Servers. The service is deployed in the edge regions. Moving the Webapp to the edge would not significantly improve the user experience.

In addition, the Webapp interacts with other Slack’s core services that are deployed in the main region as well. Moving the Webapp to the edge would increase network latency between the Webapp and these services with an introduction in additional complexity and overhead for managing and synchronizing the data across multiple cloud regions. 

Broadcasting Channel Messages to all Clients

Once the client establishes a secure web socket connection with the backend, each message sent in a channel is broadcast to all the online clients of the channel in real time. 

The Webapp sends the channel message to the Admin Server service, an interface between the Webapp and the Channel Server service. The Admin Server, with the help of the channel ID, discovers the Channel Server via the consistent hash ring and routes the messages to that Channel Server. 

The Channel Server sends out the message to every Gateway Server in different cloud regions subscribed to the channel. And the Gateway Server, in turn, pushes that message to every client subscribed to that Slack channel. 

Key System Design Learnings from this Real-time Messaging Architecture Case Study

Microservices architecture helps with independent service development, management and deployments. The Gateway Servers are deployed in the edge regions, whereas the Webapp and the Channel Servers are deployed in the main region. In addition, based on the requirements, some services are stateless and others stateful.

Every Server has a dedicated responsibility and is implemented as a microservice that helps Slack scale individual Servers based on specific service requirements and allocate resources (infrastructure and engineering) based on the service demand.

This helps with agility and flexibility in feature development and maintenance. Teams in the organization can own specific services, make changes to them, test, debug and deploy quicker without stepping on each other’s feet. 

In addition, if a certain Server faces issues or downtime, it doesn’t impact other Slack Servers. This helps with the system availability, resilience and fault tolerance. 

Though microservices are not the solution to every architectural scalability problem, tradeoffs are involved when picking the right architecture (microservices, monolithic, modular monolith, hexagonal architecture, etc). 

When implemented, microservices bring along a lot of architectural and maintenance complexity, such as inter-service communication, service discovery, distributed system management, and so on. Monolith architecture in contrast is relatively simple to work with. 

Picking the right architecture requires a thorough application use case analysis. There is no silver bullet.

Different categories of cloud instances (storage-optimized, compute-optimized, memory-optimized, etc.) can be leveraged along with their add-ons as per the fitting use case.

Consistent hashing helps with the data or traffic distribution across a cluster of servers, ensuring minimum data rebalancing across the cluster nodes. The technique is used by a bunch of web-scale services and distributed systems to scale.

A proxy server can also be leveraged as a load balancer, given we already use it in our architecture for the proxy server use cases, and it fulfills the application load balancing requirements. This cuts down the complexity of managing a proxy server with a dedicated load balancer.

Persistent connections reduce the overhead of repeatedly establishing HTTP connections between the client and the server if their interaction is frequent and lasts long. 

With multi-regional cloud deployments, edge deployments are leveraged to minimize the latency as much as possible.

If you wish to take a deep dive into the fundamentals of designing a large-scale service, I have discussed all these concepts and more in my Zero to Mastering Software Architecture learning path comprising three courses I have authored intending to educate you, step by step, on the domain of software architecture, cloud infrastructure and distributed system design. This learning path offers you a structured learning experience, taking you right from having no knowledge on the domain to making you a pro in designing web-scale distributed systems like YouTube, Netflix, ESPN and the like.  Check it out .

Related read : Facebook Real-time Chat Architecture Scaling With Over Multi-Billion Messages Daily

Information source : Slack real-time messaging architecture .

Enhance your distributed systems knowledge and system design skills with these resources .

I am Shivang. Here is my X and LinkedIn profile . Feel free to send me a message. If you found the content helpful, consider sharing it with your network for more reach.

I’ll see you in the next post. Until then, Cheers! 

System Design Case Study #2: How GitHub Indexes Code For Blazing Fast Search & Retrieval

Web Service & Associated IT Roles

Related posts

Facebook real-time chat architecture scaling with over multi-billion messages daily, twitter’s migration to google cloud – an architectural insight, how evernote migrated & scaled their workload with google cloud platform, understanding sla (service level agreement) in cloud services: how is sla calculated in large-scale services, what do 100 million users on a google service mean – system design for scale and high availability, how razorpay handled significant transaction bursts during events like ipl.

Zero to Mastering Software Architecture Learning Path - Starting from Zero to Designing Web-Scale Distributed Applications Like a Pro. Check it out.

Master system design for your interviews. Check out this blog post written by me.

Zero to Mastering Software Architecture  is a learning path authored by me comprising a series of three courses for software developers, aspiring architects, product managers/owners, engineering managers, IT consultants and anyone looking to get a firm grasp on software architecture, application deployment infrastructure and distributed systems design starting right from zero. Check it out .

Recent Posts

CodeCrafters  lets you build tools like Redis, Docker, Git and more from the bare bones. With their hands-on courses, you not only gain an in-depth understanding of distributed systems and advanced system design concepts but can also compare your project with the community and then finally navigate the official source code to see how it’s done.  Get 40% off with this link . (Affiliate)

DataCamp  offers courses, skill tracks, and career tracks in data science, AI, and machine learning. With interactive exercises, short videos, and coding challenges, learners can master the data and AI skills they need. 

With the data engineering courses, you can learn how to design and create the data infrastructure businesses need to scale and master one of the most lucrative skills worldwide.  Check out the website here . (Affiliate)

Follow Me On Social Media

Username or Email Address

Remember Me

Registration is closed.

Conference on Systems Engineering Research

CSER 2023: The Proceedings of the 2023 Conference on Systems Engineering Research pp 541–558 Cite as

Systems Thinking Design in Action: A Duplicated Novel Approach to Define Case Studies

• Haytham B. Ali 5 &
• Gerrit Muller 5  
• Conference paper
• First Online: 26 March 2024

Part of the book series: Conference on Systems Engineering Research Series ((CSERS))

This study uses systems thinking as a duplicated research methodology to define and validate a case study early. This case study is a part of a complex sociotechnical research project. We use a systemigram to visualize the case study, including its different aspects, also called embedded units of analysis. This visualization aids in sharing, understanding, and stimulating discussion, explanation, and communication among heterogeneous stakeholders from industry and academia. We support the systemigram as a conceptual model with other systems thinking tools, including a context diagram, and customers, actors, transformation, worldview, owner, and environment (CATWOE) analysis. In addition, we applied other tools, such as workflow analysis and stakeholder analysis. We found that using systems thinking and its tools, mainly systemigram, aids researchers in well-defining, understanding, validating, and communicating the case study, its context, its aspects, its goals, and its relations among the heterogeneous stakeholders.

• Systems thinking
• Systemigram
• Early validation
• Sociotechnical research
• Methodology

This is a preview of subscription content, log in via an institution .

R.K. Yin, Applications of Case Study Research , 3rd ed. (SAGE, Los Angeles, 2012), ISBN 978-1-4129-8916-9

Google Scholar  

H.B. Ali, M. Mansouri, G. Muller, Applying systems thinking for early validation of a case study definition: An automated parking system, in MODERN SYSTEMS 2022: International Conference of Modern Systems Engineering Solutions

H.B. Ali, T. Langen, K. Falk, Research methodology for industry-academic collaboration – A case study, in CSER2022 Virtual Conference , vol. 32(S2), (Wiley Online Library, 2022). https://doi.org/10.1002/iis2.12908

Chapter   Google Scholar  

B. Sauser, M. Mansouri, M. Omer, Using systemigrams in problem definition: A case study in maritime resilience for homeland security. J. Homel. Secur. Emerg. Manag. 8 (1) (2011). https://doi.org/10.2202/1547-7355.1773

G. Muller, 1.1.1 Industry and Academia: Why Practitioners and Researchers are Disconnected . INCOSE International Symposium, Rochester, New York, USA, 13–16 June 2005, vol 15(1) (Wiley Online Library, Hoboken, 2005), pp. 1–9. https://doi.org/10.1002/j.2334-5837.2005.tb00648.x

G. Muller, System and Context Modeling—The Role of Time-Boxing and Multi-View Iteration . In Proceedings of the Systems Research Forum, Orlando, FL, USA, 13–16 July 2009, vol 3 (World Scientific: Singapore, 2009), pp. 139–152

M.I. Drotninghaug, G. Muller, M. Pennotti, The value of systems engineering tools for understanding and optimizing the flow and storage of finished products in a manganese production facility. Published online 2009

A. Patrick Eigbe, B.J. Sauser, J. Boardman, Soft systems analysis of the unification of test and evaluation and program management: A study of a Federal Aviation Administration’s strategy. Syst. Eng. 13 (3), 298–310 (2010)

Article   Google Scholar  

Siemens Metro Oslo. Studio F. A. Porsche | Premium Design Services. Accessed 8 Nov 2022. https://www.studiofaporsche.com/en/case/siemens-metro-oslo/

twiki. Oslo Metro: T-Bane. Transport Wiki. Published September 7, 2018. Accessed 8 Nov 2022. https://transportwiki.com/oslo-metro-t-bane/

J. Gharajedaghi, Systems Thinking: Managing Chaos and Complexity: A Platform for Designing Business Architecture (Elsevier, 2011)

A. Basden, A.T. Wood-Harper, A philosophical discussion of the root definition in soft systems thinking: An enrichment of CATWOE. Syst. Res. Behav. Sci.. Wiley Online Library 23 (1), 61–87 (2006). https://doi.org/10.1002/sres.689

D.S. Smyth, P.B. Checkland, Using a systems approach: The structure of root definitions. J. Appl. Syst. Anal. 5 (1), 75–83 (1976)

P. Checkland, Systems Thinking, Systems Practice (Wiley. Published online, 1981)

Download references

Acknowledgments

This research is part of a larger research project, the second iteration of the Human Systems Engineering Innovation Framework (HSEIF-2), funded by The Research Council of Norway (Project number 317862). We also take the opportunity to thank the Norwegian Industrial Systems Engineering Research Group (NISE) for their valuable discussions and feedback. We also acknowledge the company for their practical cooperation, especially Bjørn Stokkeland. We also thank Aline Pereira Da Silva for contributing as a co-researcher in the workshops.

Author information

Authors and affiliations.

University of South-Eastern Norway, Kongsberg, Norway

Haytham B. Ali & Gerrit Muller

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Haytham B. Ali .

Editor information

Editors and affiliations.

Stevens Institute of Technology, Hoboken, NJ, USA

Dinesh Verma

Astronautics Aerospace and Mechanical Engineering Department, University of Southern California, Los Angeles, CA, USA

Azad M. Madni

Endevor, Wilmington, DE, USA

Steven Hoffenson

Appendix A: Stakeholders, an Elaboration of These Stakeholders and Their Interests

This Appendix lists Table 2 . Table 2 illustrates the stakeholders (who), an elaboration of these stakeholders (what), and their interests (who).

Rights and permissions

Reprints and permissions

Copyright information

© 2024 The Author(s), under exclusive license to Springer Nature Switzerland AG

About this paper

Cite this paper.

Ali, H.B., Muller, G. (2024). Systems Thinking Design in Action: A Duplicated Novel Approach to Define Case Studies. In: Verma, D., Madni, A.M., Hoffenson, S., Xiao, L. (eds) The Proceedings of the 2023 Conference on Systems Engineering Research. CSER 2023. Conference on Systems Engineering Research Series. Springer, Cham. https://doi.org/10.1007/978-3-031-49179-5_37

Download citation

DOI : https://doi.org/10.1007/978-3-031-49179-5_37

Published : 26 March 2024

Publisher Name : Springer, Cham

Print ISBN : 978-3-031-49178-8

Online ISBN : 978-3-031-49179-5

eBook Packages : Engineering Engineering (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research