Have you ever had to search for your brand’s design documents only to find yourself lost in the chaos of your company’s design system? Or have you ever been part of a design team but felt completely unclear about your role functions? If so, you and your company might need to know about the best design system organization methods.
A design system is a good way to organize your design toolkit. It allows you to keep your UX/UI documents in one place and design your product clearly from start to finish. This enables better efficiency for designers and developers alike.
There are different types of design systems. In this article, we’ll go into three structures of design system organization and the three models of teams that handle the design system.
Oftentimes, it’s easy to get lost in the chaos. So here are actionable steps to banish the chaos and your ultimate guide to creating (and organizing) a design system that actually works!
In your work as a UX designer, have you ever been frustrated with poor organization? Are there times you feel the effects of a design system structure don’t benefit you?
Some of these effects may lead you to be frustrated due to poor organization:
A combination of these could also lead to feelings of inadequacy or an inability to perform well at work, whether you are part of a large UX team or a solo UX designer.
Ultimately it does not benefit you, your company, or your users if you fall into the pitfalls of many of these common frustrations with poor organization. This is why it’s all the more important to have the best design system organization you can have, so that you, your UX team, and even your whole company can alleviate these problems.
A design system is a well-structured framework for managing design at scale. It provides a team or multiple teams within a company with shared principles, patterns, and tools for effectively managing the design process.
A usual design system would have in it:
It allows UX designers to streamline the design and development process and provides a well-organized repository for easier collaborations among the various designers and teams involved in the process.
Its effect is double — to ensure that team members have their design system UX/UI elements in a single interface that the whole organization can use, and it ensures that end users have a cohesive experience across all products and platforms.
A design system framework has various components for organizing all aspects of UX design, such as brand-specific principles, patterns, and design tools. It can even organize team members within a company. The design system structure also serves as a repository for data and other assets.
There are three common organizational models or three ways to implement a design system structure. These are general structures for setting up your team and the people in charge of accessing and using your preferred design system format (the types of formats are in the next section). Keep in mind that you don’t have to prescribe just one. Companies usually have a hybrid team that combines two or all three within their design system organization.
In a centralized model, the design data is centralized in one team.
This organizational model allows the UX/UI designers, architects, engineers, and analysts to work together as one team. Each outside business unit needing access or assigned work incorporating information from the design system can simply contact this team.
This centralized team will then facilitate the work of the other teams to ensure that they adhere to the design system, such as facilitating the design guidelines for the rest of the organization.
The team also ensures the design system is up to date and meets the company’s needs. This team will be in charge of setting up and organizing the design system — building, accessing, and using it—as part of a centralized team organization model.
A huge benefit of a centralized organization is that design practices, tools, technologies, and company preferences are consistent since one team is in charge of the design system.
This design system model is ideal for companies that take the traditional approach — a design team responsible for reporting, working, and taking care of the general upkeep of the centralized design system.
In a distributed model, the design system is distributed amongst different teams.
Certain team leaders from varying teams will be in charge of the design system rather than one team, as in a centralized model.
These team leaders are usually specialized and experienced UX/UI designers, UX/UI architects, or UX/UI analysts. They may be embedded in different teams, such as the analyst within a data analyst team and the UI expert in a separate team from the UX.
Although they may be on different teams, these experts or leaders have shared responsibilities for the design system. Their varying expertise benefits the system and its important roles among different teams within the company. Decentralized teams can also respond to design problems within the organization or meet the specific needs of their other teams, members, or clients.
The distributed model emphasizes the embeddedness of design within the organization. It allows specialized members of each team to have input into the design system and UX design as a whole.
In a federated model, the people in charge of the design system consist of one centralized team and some individual experts from different teams.
This works because one centralized team is in charge of the core tools, processes, guidelines, and other design standardizations for the whole company. However, the design goals, projects or work completions, and any other design data pertinent to the design project are distributed to experts amongst other teams.
The federated model benefits companies that want to standardize the design workflow by having everyone use the same tools or brand processes created and managed by the central design team. However, it still allows collaborations with experts from other teams for the actual UX design work.
Thus, the federated model takes on parts of centralized and parts of distributed organizational models, but on its own, it’s a common model of hybridization.
Now that you know how teams manage a design system within a certain organization, it’s time to show you the structural differences between the three main design system formats.
These three formats are common repositories of design knowledge within the company that help implement design elements with documentation and guidelines.
As its name suggests, this is the simplest of the three design structures. A visual repository usually includes only the basics of design elements and data to aid UX/UI designers in their work or to standardize the company’s design practices.
The elements contained in a simple repository are easily created and easily maintained, with the design system elements usually in an alphabetical list and a visual format.
Some of the elements contained within a simple repository are those we discussed in the first sections of this article: the style guide, the pattern library, and the design components.
A modular design system, meanwhile, breaks down the whole design system into different modules. Each module is designed and developed individually.
In a modular system, there is an interplay of different modules created, modified, exchanged, or replaced. This allows designers to use and reuse different modules as they see fit. A modular design system would be not only a repository of each small component or module but a whole living and changing process.
Within a modular system, you would have documentation or guides for each module; interfaces that bridge the modules; creation, integration, and testing for each module or a subset of modules; exchange and replacement of each module as they undergo testing; and observation and maintenance to ensure the modules work properly.
A modular design can be an integral design system as it guides and gives structure to the product through its various small modular components.
A code-based component library is made up of prototypes that designers and developers make that behave as the final product should. These prototypes are coded UI elements that improve the efficiency of the workflow since they can carry the design from prototype to handoff.
Although creating these code-based components can take a lot of time and effort, developers and designers have used this relatively new design system to improve the workflow and aid better collaboration among teams.
Finding the right organizational model and the right structure for your team or your company is the key to having the best design system organization.
The structural format provides a clear framework for organizing design components and streamlining the design process. Meanwhile, the organizational model ensures consistency across different platforms, products, and teams and facilitates better collaboration between teams. Both are necessary for a cohesive user experience of your design.
Here are some of the ideal structural formats that align with the most ideal organizational model. (Keep in mind these are just suggestions and not set in stone. Only you are the most knowledgeable about what works best with your own company):
A centralized team, due to the nature of one design team being responsible for data, can align its guidelines, documents, and data in a simple visual repository.
This makes sense because if only the centralized team had access to a simple visual repository, they could then make design choices applicable to the whole company.
Then, a centralized team has a visual repository ready for design choices that other teams may communicate to them, making the whole design process simple and easy.
The federated system might work best with a modular design system due to the nature of the work.
Since a federated model still has a centralized team working with team leaders from other teams, it might be best to align with the modular system in its nature of small parts of the whole picture.
That’s because the modular system lets you work on different, smaller aspects of the design system process — the modules. So, the work of the centralized team, alongside the team leaders, in the federated model will be seamless and easy.
Due to the nature of distributed teams, it might be easier to work with a code-based component library than with the modules or a simple repository.
Since distributed team leaders from different teams are working on the design all at once, it’s easier to work with a code-based component library that everyone can access at the same time.
This allows everyone in a distributed model to work on the same design project or alongside other design projects, easily relying on their own access to the code-based component library.
Poor organization and structure within a design system can lead to a mess of confusion and lack of coordination, hesitation to share ideas and slow making amongst teams and members.
With the right organizational model, a team member knows exactly what to do and how to do it. Meanwhile, with the right structure, the data and components are exactly where you need them to be and exactly right for the user to have the best user experience. It’s the key to having the best design system organization that helps you move from mayhem to comprehension!
This post contains original images by John Hirota. John Hirota is an illustrator working in the fields of design, culture, and education.
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.
You don’t need a PhD, a big budget, or months of planning to do solid UX research. Let’s break down the biggest myths stopping teams from learning what users really need.
Thinking of switching from graphic design to UX? The transition isn’t as daunting as you might think. Here’s what you need to know about their differences, similarities, and career paths.
Here’s what you need to know about the UX design process. Get actionable insights, advanced concepts, and a downloadable checklist to bring in some order.
Users shouldn’t have to guess what to do next. Here’s how you can close the two UX gulfs — the gulf of execution and evaluation — for better designs.
Learn more →
