Why may your design system not be an actual design system?

I recently came across a new list of ready-to-use design systems. While discussing some of them with fellow designers, I had another thought that has been bothering me for some time — most of the design systems I see are not design systems.

So why may the design system you see not be an actual one?

Let’s start by defining a Design System. Nielsen and Norman’s “Design System 101” describes it as “a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.” According to this quotation, such a thing will solve most design issues. But what I see in the wild design world is usually a huge and very beautiful library of components that probably demonstrates some high Figma skills but not a set of standards for solving these issues.

I have seen companies and solo designers invest lots of time and effort in building one, starting from the research of the existing screens, trying to adopt some solution as a baseline, adding a bunch of color shades, transparency levels, and industry-specific components, but if I open one, I’m usually quite confused. I don’t understand how to use it.

Of course, I know how to use components and variations, layouts, and color libraries. But in my opinion, this component library thing only solves the visual consistency issue and does not serve us as a proper system.

So what is missing?

When it comes to real-life tasks, we all face a huge problem — as designers, we forget to document use cases and match them with the flows and components we designed. We all have been in this situation when you have multiple tasks, stakeholders, and managers asking you to create a design, believing that they know exactly what it should look like, some outdated pages we didn’t have time to work on. When we want to deal with the mess and start working on a design system, we mostly make our lives easier by creating organized files and libraries, but we don’t think about the bigger picture.

I can come up with a long list of examples, but if you are reading this, you probably have one even better from your experience. Think about something simple, e.g., showing full info in case there’s not enough room for the full-length text. You probably instantly thought about tooltips, expand, hover mode, or pop-ups to solve this issue — all of these things could work perfectly. And you have these components in your library. But how do you know which one to pick?

Based on your experience, similar use cases, or discussions with the team, you will select one of the components and use it in the design. The next month, you or another designer from the team may do it differently, so there will be more than one solution for the same issue in the product.

While it may not seem catastrophic, when the product grows (and that’s why you probably started working on a design system), these issues aren’t easily solved by design validation or knowledge sharing and review sessions. Even if we can solve these inconsistency issues, why create them in the first place?

I strongly believe that building the Design System often gives us a false sense of security that we did a great job. And it doesn’t mean that we didn’t. We worked hard, probably gained new UI skills, and made the engineering team’s life a bit easier. But the task wasn’t completed. In six months, any new designer, or even you, will try to reinvent the wheel and create inconsistency instead of beating it.

So what would I suggest? Document your work, describe what problem your component solves, how to use it, and its limitations. If you decide on the maximum number of items in your navigational menu or the number of steps in the form, document it, stick to it, and make sure that it’s available to the rest of the people involved in the project.

I can’t say that working on something less than a documented design system is not valuable. But having something that really works for you and doesn’t just provide quick fixes would feel much better.

Originally posted Here