“Design Sprints”, “Agile”, “Stand Up”, “Lean” – Is “Design System” just another buzzword? An attempt to break down the what, why, and how of design systems.
It depends on how we look at it. There’s a lot of innovation going on in design systems right now, which is why it’s been talked about so much. There are many reasons why this happens. To name just a few:
- Developers don’t want to repeat the same work on different media.
- Companies want to be more efficient.
- Product owners and product designers want the products they are working on to be faster and more accessible, while still looking consistent.
All of these are real problems we face daily that have moved us to develop new technologies, new ways of working, and new ways to better manage and scale design.
These are just a few reasons why companies are investing so much more in design systems. However, since it is a new term, its meaning and process are still unclear, vague, and inconsistent. Because of this, we see discussions, buzz, and the occasional goal ‘meme.
As far as I know, there is no formal definition of what a design system is. I think because the problems it solves (especially in the area of digital products) only emerged recently. To explain, I’ll give a real-world example.
We have many products that all have separate code bases and more or less separate teams/owners:
- Main platform
- Prototype viewer
- Design tools
- Mobile apps (iOS / Android)
- Mac apps (sketch plugin)
We also develop and support some static pages:
- Marketing website
- WordPress Blog
- A set of isolated back end templates
We also send HTML emails daily:
- Some of them are automated
- Some of them need to be specially created
We also have different teams that work together daily:
- Front end
- Back end
With all of these different platforms, channels, teams, and processes, several challenges arise. For example:
- How do we make design accessible to all teams?
- How do we make sure that every team uses the same technology, elements, and patterns
- How do we ship new features for each product without repeating the same work over and over? Or in other words, how do we stay efficient?
- How do we bring all of this to consistency?
What are the advantages of a design system?
I briefly mentioned some of the problems we faced before developing design systems. So the advantages are to find solutions to the problems mentioned, e.g. B. Developing consistent and accessible software across different media, reusing and maintaining code and design in a more efficient way. And of course to improve cross-team collaboration.
What can you learn from building a design system?
It’s a challenge to develop a design system that scales well as the team grows. Especially when the products grow in scope and complexity at the same time. It takes a lot of time and effort and there always seem to be hurdles.
What we’ve realized over the past two years is that it can be very helpful to treat the design system as a separate product. It needs its requirements, its features, a solid roadmap, and clear prioritization.
For example, our pattern libraries are not something we built and then left to their own devices. They evolve every day because there is an ever-growing backlog of feature requests (internal only). Managing all of these things while making sure the products stay consistent, don’t break or look weird turned out to be the hardest part. At the end of the day, it’s a mix of design and software so it needs to be treated the same way.
Other things we realized were critical to the process, especially when time and resources are tight:
- Extensive documentation
- Regular examination
- User research
At the end of the day, it might sound very obvious, but we’ve noticed that anything new that is complicated (a UI kit or a pattern library, or even a design process) is slow to adopt – unless it’s religiously enforced.
If it takes effort in learning and time to get used to, people get confused and ignore it. The reason is that everyone wants to get their job done quickly, which means that he/she is more likely to not invest time in something new that slows them down in the short term. It’s just hard to see the long-term efficiency gains. Any deviation from the regular workflow will take some time to make adjustments. Therefore, it is also a challenge to ensure that the solutions are simple, understandable, and straightforward.
How do you start developing a design system?
Another question that we don’t have a specific answer to as every project is different. The first thing we do is do an audit of the existing brand, products, and user interfaces.
By the time we start creating a style guide, Page may have been around for two years. It’s an established product that already has a good, consistent design that people loved and loved to use. However, it may come to a point where important features are introduced and it becomes a platform rather than a single product, so the need for consistency becomes more and more important.
Then we do an audit of the existing code base and identify some issues, for example:
- Identical components were implemented inconsistently.
- The colors were not balanced properly.
- Transitions were determined randomly.
- There are too many different font sizes.
- We counted many slightly different shades of the same gray.
- Many CSS files were either duplicated or not used.
From then on, one chooses the technique and approach to solve the following problems:
- Create a framework to unify all design values
- Create a sample library to make existing user interfaces consistent
- Establish clear guidelines and rules for the use
What makes a good design system?
We don’t think it’s a specific thing and would say that execution matters. But we think these points are critical to a good design system:
- Good, concise documentation
- Rules and guidelines that are easy to understand
- A clear explanation of why certain decisions were made (A good example of this is Bulb’s design system, which provides insight under each component and provides context for why certain decisions were made – mostly supported by user research)
Is a design system always a good solution?
If it overcompensates and clogs the workflow of colleagues with unnecessary processes, it is not a good solution. It wouldn’t be a solution at all.
It is enough to have a sample library without calling it a design system. You can use a simple UI kit. Or a set of design variables when creating a simple website. If it helps you build faster, it does the job. It doesn’t always have to be a system.
You can design and style everything on the go. Like when you create marketing websites. Or products with a lifetime as part of marketing campaigns. It doesn’t matter what or how you use it, as long as you are productive, efficient, and getting the job done.