How to Select the Right Components for Your Design System.

A five-step guide to deliver a a design system and not get lost on the way.

If you’re reading this article, you don’t need me to explain why having a design system is important. You also don’t need me to explain why having a good design system is even more important. But you probably also saw lots of different canvases and blueprints aimed to help you finally build the design system that will suit your needs.

What if I told you you could follow these five steps to build a design system? One that will be tailored to your needs, easy to maintain, and free of redundant work.

Yes, the design system is much more than just a library of components. As Smashing Magazine notes, you should:

“Think of it as a process and a set of deliverables that create a shared language that everybody on the team will use when creating a product.” — Nick Babich for Smashing Magazine

Before thinking about any small details, I would start by defining the purpose of your design system.

Define the Purpose of Your Design System.

Every design system should be scalable, accessible, consistent, and visually well-developed. However, not all issues can be addressed with the same level of attention to detail. You need to answer questions that I would narrow down to these three:

• What problems are we solving with this design system?
• Who are the stakeholders and users of the system? Designers, developers, product managers?
• How will the system scale as the product evolves?

After you have answered these questions, you can roughly estimate the time and effort you should put into this project. Suppose you’re working on a solution for some large SaaS project that is in its growth stage and will be used by a huge team of designers and developers. In that case, the project will involve information-dense screens that will make following accessibility standards almost impossible — this will be very different from creating a system for small start-ups that will use it mostly to support their brand strategy and identity.

Audit Your Existing UI Patterns.

To avoid reinventing the wheel, thoroughly audit your current design, development processes, and documentation. Identify commonly used UI elements and look for inconsistencies and overlapping across screens or platforms.

My personal approach is to build a UI tree where I group elements into larger categories and sub-categories. This simple exercise gives me visibility into the number of components and their variations for the whole system. Even though it may seem like an annoying activity, you may be surprised how many options you have for secondary buttons or text fields.

Once you have your documented list, proceed to the next step. Prioritize components based on impact.

Prioritize Components Based on Impact.

Not all components need to be included in the first iteration of a design system. Instead, focus on components that deliver the most value. Use criteria such as:

• Frequency of use: Prioritize elements like buttons, inputs, and navigation.
• Complexity: Standardize components that are time-intensive to develop repeatedly.
• Impact: Address critical user experience or accessibility issues.

Every design system starts somewhere, then evolves, and undergoes many iterations of implementations, feedback, product changes, and new brand strategies. I suggest consulting with stakeholders and developers at every stage of your design process. This ping-pong of providing small pieces of your work, getting feedback early, and adjusting is one of the best investments you can make. But at this step, talking to the development team is crucial. You need to understand their limitations; that’s when you need to think about how to make their life easier to deliver the best possible MVP of your design system. But don’t forget about the next step, the approach that you should incorporate as early as possible, the very first second you start designing your components: ensure accessibility from day one.

Ensure Accessibility from Day One.

I will not focus on accessibility itself. Standards, rules, laws, and best practices are hardcoded in the brains of most of the designers I know. I’ll just cover why it is important to do it as soon as you design literally any tiniest thing. Stakeholders, the marketing team, and other people may ask you about specific aesthetics; even as a designer, you may fall into the trap and start designing components following your dream vision. This can easily lead to beautiful details and screens that simply can’t be adjusted and edited enough to follow standards without losing their aesthetic.

I understand the complexity of accessibility negotiations versus aesthetics or delivery speed. But incorporate accessibility as a non-negotiable base for your designs as much as you can. First, you will not have to think about it later and change your designs, but you can avoid negotiations at later stages if your team agrees to set this baseline.

When you finally start building your components, starting from the top-priority ones, being consistent, covering existing needs, and avoiding overlapping — it’s time for the last step in this journey: document and test your components.

Document and Test Your Components

I wrote another separate article about the importance of documenting everything when working on your design system here, and I will cover it briefly here as well. I see design system documentation as a terribly underestimated part of most projects. When you design any layout, flow, component, or pattern, you need to have a clear vision of when and how it should be used and what problem it solves. You should deliver your vision to other people, document it, and make it easily accessible. Keep it simple, but never leave any component hanging around in your design system file without supporting notes.

When we talk about testing, well, this is a tricky part. You may not have time or budget for that, there may not be QA in your team, and you may not have access to real data at the early design stage. But I would still try to adhere to these three principles:

• Use real data in your components. Don’t create a button saying “button.” See if your product needs longer texts or a simple “Ok” will be needed.
• See how your components work in real screens, together with other components and data, not just by themselves.
• Validate your components as soon as developers finish their work, not when they appear in the released product. People make mistakes; sometimes, things don’t work as they should. Catch all these issues earlier in the process.

Final Thoughts

Building a design system is a long and complex process that never ends for some projects. But sticking to these five rules helped me deliver design systems while working as a solo designer and still deliver a solution that I could be satisfied with. It also helped me contribute to the bigger design system development as a team and not get lost on the way.