Part 2 of the Setting up a design system series.

You need a design system! And a Pattern Library! A Living Styleguide is a must have! Today, one cannot work without one …

That's how many design systems, Pattern Libraries, and similar principles get pitched. Now, as much as this is typical, this is a big problem at the same time. In this post we will focus on the question whether one needs a design system.

Where from does the initial idea originate

Very often there are trends which people pick up and they are super excited about them. It becomes obvious that something great is right in front of them. Or a person comes back from a conference and is all motivated and pumped for he or she has been "loaded" with many great concepts and ideas.

That is wonderful! After all this incorporates a lot of energy and brings home a person who is willing to invest energy into a system to improve it. Now, with that being said we have to take a look at the other team members as well:

Who can benefit from a design system and how

First of all let us take a look at the design system itself. What is it? It is a system with elements, styles, and principles which can be used to design something: A product, an interface, even a workflow if we stretch the definition a bit further. It offers components, chunks, bits, blocks, whatever you might want to call the building units and it combines these with rules and some basic definitions (think typography, colours, characteristics, tone of voice, …).

Now who can benefit from such a component-driven system? Well, anyone who needs to interact with the system in some way or the other. What does that mean? A few examples …

The designer

A designer is most likely builder, maintainer, and consumer of this system at once. They have the benefit of not having to build everything over and over again, but can design building blocks and use these to create the more complex things. They can grab components and arrange them in the best way to form an interface for example. They can simply "throw things together" and focus on the structure and usability, not the rough design of a form element. That has been optimised before, probably by them. They build upon their previous work.

The developer

A new landing page needs to be built. Great! Let's copy the last one. But there are new things on it. There are old things on it. Some things from the contact page are used. The validation in the concept wireframe looks more like that of the check-out process. Well, with a design system this could easily be communicated and looked up. The components are probably not just images of a layout unit, but if a design system is extended to the code side of things it makes for a great code repository with standard snippets and modules a developer can use as well. It makes code more harmonised and similar, maybe even dry'er.

The product owner / marketing manager

Something needs to be built. But how can one start? "We are not designers," might be the first thought. The design system can be a source to tap into, just like a LEGO brick box. There will be components which might be suitable to get a first idea created or written down using these components. Fixing and optimising can be done by a UI/UX designer afterwards or, even better, in a collaborative effort.

What do people like about a design system

1. It creates a common language

Of all things a design system creates a common language. When it includes not just the design aspects, but also includes the code, the business aspects, maybe even more than that, it can be the place for everyone to document and look up things. A slider, a carrousel, a teaser slideshow, all of that might be the same, but now it gets one name for everyone to refer to. No more misunderstandings: A rose is a rose is a rose is a rose. And not a flower. And not a plant with a red/white/orange/… blossom in a specific shape.

2. Things are up to date and can be relied upon

When a team has the chance to create and maintain a design system properly, there is a great benefit: It will become a source of knowledge one can tap into, rely upon, and trust. No more outdated design PDF, a code base with a newer version, layouts with even another version, the list of things that can create "forks" goes on.

3. It makes the work easier and faster

When a team can make use of a design system, with a tool like a Pattern Library keeping all the components at hand, sporting a documentation explaining everything, they have the chance wo work faster and create more relieable products. A component which has been tested and designed, can just be reused. No need to invent the wheel again. Just grab a few components, slab them together and a new thing is ready for deployment or release. Well, it might be a bit more complicated than that but it can be as simple as that.

4. New team members can have a faster onboarding

With a design system in place and a good documentation / Pattern Library to bring it to life, it makes the onboarding process a lot easier. A new team member can basically start right away. All they need is to use the things available.

By the way, this is a great way of checking for inconsistencies: Should there be a need to ask questions because the design system does not cater towards the solution of the job at hand it makes sense to improve it at that point. Never let that chance go to waste is a big recommendation I can give you. New team members often have questions: Use this indicator! It actually makes the new team members become a valid contributor to the system right away which usually creates a stronger feeling of ownership. And that is key to a successful design system to work.

What are people afraid of

1. Loosing control

But as a designer I am the one to decide how things should look like! Not a design system.

True. And that should not change I guess. But are you really interested in doing the same ground work over and over again? 21px spacer this time, 23px next time, 19px thereafter, …

That–and of course exceptions can be part of the system as well–is not the job. The job is to make a design work towards a goal, be consistent, shine by supporting a business or usage cause. It is most certainly more important to focus on whether something offers the right information hirarchie than battling over a few random pixels.

2. Crossing into other departments' turf

Actually some people are not afraid of stepping into other departments' territory. But they might be afraid of not knowing enough about something. Can I use this component as a navigation item? Will it function? What about responsive behaviour? Does it work on a touch screen?

A design system brings departments together. When this is not just the case in a document but there is an actual discussion and collaboration happing in the process of creating components, people are not afraid of asking questions anymore. And you actually know whom to talk to when in doubt.

3. Too much extra work

But we have no time to document everything!

Especially documenting things might be a thing people see as a potential extra work. Yes, true. But only in the beginning. It shows that there is a quick change taking place. Every bit of documentation makes the next use of a similar item, component, concept a lot faster and easier.

However, the initial work load needs to be accounted for. Do not think it will be done on the fly, especially as the process might be trained at the beginning. And there will be discussions about the how and what needs to be documented.

4. It will be old and outdated in a few weeks

Love this one! Yes, 'Living Styleguides' often turn into zombies indeed. They still offer components. But while they were fine in the beginning, they start falling apart, their voice turns into soar throat noises and the way they walk is more like that of a boar being hit by a car on a highway.

This happens all too often when the process behind a design system and its components is undefined and not owned by someone. So the danger is that the system gets created and never updated. That indeed needs to be avoided.

5. It is expensive to create / maintain a design system

No. Yes. Maybe. When it comes to the cost and budgets there is an elephant in the room, actually two. The first is that documentation needs to be written, components need to be sliced, a Pattern Library tool needs to be evaluated and set up. That takes time and energy. With an existing design language and code this might even be a painful transition process with ambiguity along the way.

However, the cost of the actual set up can be an investment when one gets the workflows set up in a fashion that the future work benefits from the systems. More feature creation and faster turnaround times can bring a return on the invested money/time/energy quite quickly.

Just think of costs for onboarding new team members, bringing freelance support up to speed, not loosing knowledge because people leave the company etc. All of that can be put into budgets and excel sheets. But the right things need to be taken into account, not just the cost part.

Which pain points does it tackle

We obviously touched on a few points already, there will always be more but let's create an incomplete list of benefits a design system can offer when created, maintained, and used properly:

• Common language / fewer misunderstandings
• Knowledge documented, not just in people's minds
• Higher consistency in code, design, etc.
• Greater output (speed / features / quality)
• More efficient inter-department communication
• Stronger identification with a product
• Cost-effective ways of working
• No outdated or inconsistent information
• Adapting modern workflows
• …

On the cons side there are a few as well which should not be ignored as they can be strong influencers and make a design system fail in terms of acceptance, trustworthiness, and many more aspects. Some problems include:

• Set up cost (time / energy / money)
• Complexity when integrating existing projects
• New workflows and team communication needed
• Involving all trades and departments
• Keeping the system up to date
• Maintaining a system which might not yield income / turn-over directly
• Additional resources needed for the system itself
• …

Neither list is complete, feel free to think about the issues, ideally in a team meeting.

Deciding whether you need a design system

In order to figure out whether a design system is needed it becomes clear that this is not just a design department thing. Many people on a team / in a company can benefit from a design system. In the next post I will focus on the groups of people involved.

For the actual process of evaluating the benefits and pitfalls of a design system, seeing to what it can help with and where it might interfere with the current way of doing things these people need to be involved. For that to happen it makes sense to get these people or representatives of the group together in a brain storming session. Make sure that people know what such a meeting is all about. They need to have a chance to think about what such a system might incorporate, what they would want from it and what they would not like to see.

One of the biggest misunderstandings of a design system is that it only involves design aspects / is for the design team and that it is about software ("Which pattern library tool should we use?"). A design system is as much about people and workflows as it is about components, fonts, and colours. At least if you are seriously interested in making it a thing that can survive.

Up next: Who must be involved in the creation of a design system …