This article won’t cover the basics of Design Systems like “What is a Design System?”, “How does it work?” or “Do I need it?” (to which the answer is “Yes”). It will also not cover tool specific topics (Carbon, KSS, Pattern Lab, Sketch, AdobeXD, Invision, UXPin… it is too much). It is a fairly broad overview of the challenges companies have to face, when they try to install a Design System for the very first time.
The main question we usually get from clients, regarding Design Systems, is something like: “How do we create a Design System?”. Or: “We want you to create a Design System for us”. But actually, what this means for us as a service provider is:
“Is creating a Design System enough?” The short answer is: No.
Congratulations, you don’t have to read any further. Now you can go outside and enjoy life. If you don’t like to be outside or if you want to dig deeper, here is the longer answer:
Creating a Design System is not that hard (it is a lot of work, but not too complex to start with). The hard part is to apply the rules over a long period of time in a growing dynamic team and environment. It is even harder to expand the system, (create new rules / controls/ concepts) and apply it to your work process, while keeping consistency and reduce the amount of design dept. It is less than easy to make people use the system. There is no template that fits every team/ company/ technology/ product/ workflow. It doesn’t help if you use the fancy carbon Design System but your tech is based on Winforms or Java. Or your designers don’t use Sketch, or you don’t have any designers at all.
Maybe, having a “closed/ready-made System” is not the way your team works. Maybe you handle everything with Jira / Confluence, or Microsoft TFS and Sharepoint. Your Dev team might be used to getting tickets, checking the documentation somewhere and finishing the ticket. In this case, they can’t be bothered to check in some other place to find the right control and read all of the documentation and concepts, only to find out if it is the right control at all. They probably prefer specific tasks with specific parameters.
It doesn’t matter if you have a PDF with red lines, Word files, a static HTML site, Sketch files or a super dynamic and build-server-integrated living Design System. When it is not a part of your default work process, no one will use it. And if it is not easily accessible and self-explanatory no one will use it correctly.
The good news is: If you don’t do things completely random, you already have a system. But chances are that your current system doesn’t take consistency for design and usability into account. The real challenge is to integrate these parts into your current work process.
Do I need a Design System Team?
I am sure there are companies who work with a Design System without having a dedicated “design team” successfully. But it sure feels easier to have dedicated people who are only (or at least mainly) responsible for the integration and maintenance of it. I use the plural, because you should never relay such a task on one person. Firstly, the amount of work in most cases is simply too much (depending on the size of your company / team/ product, of course). Secondly, if you lose this person, you lose your system. And thirdly, integrating a Design System requires skills in many fields. You need experience in visual design, usability and programming (at least you need to know what your developers want and how they work). Only a few people have the necessary experience in all these fields, to even work on such a task by themselves.
Having all these nice tools like carbon Design System, zeplin and brand.ai (there are so, so many promising tools and frameworks out there), it is easy to underestimate the integration of a Design System. It seems that tools are getting more attention than team composition or integrating the right processes. But tools, unfortunately, won’t cut it.
I see tools like musical instruments. If you can’t play them, or if you don’t even know what kind of instrument you want to play, you won’t create good music and no one will even join your band. Also, having a drummer in your band is a good start, but if you force him to play the guitar, bass and keyboard as well, he most probably will fail. Especially if he is supposed to do it all at the same time.
That’s why you need to get a team of interdisciplinary people to work on the Design System. Everything else will, most likely, be way harder.
I have a team, now what?
Now that you have the workforce, they need to be enabled to question your current process. And most likely, this process needs to change to accommodate the integration of a Design System.
This is key for the integration. It doesn’t mean that the new team has to dictate how everything should work, by no means. But they need to be able to talk to developers, marketing and project managers. Together they have to find a way to establish a process that works for the whole team.
When developers and designers work in the same team (same scrum sprints for instance), they face similar challenges together. Designers will get a better understanding of what developers need. Developers will get a better understanding of what users need. It will make compromises between design and development much easier and most likely better.
Here are some basic examples of typical problems:
Same Team:
Developer: “Our framework does not support this fancy paging combobox you designed. Also we don’t have time to create a new custom control.”
Designer: “Ok, I’ll come up with something that fits our standard controls we already have.”
Different Team:
Developer: “I can not build what the designer wants… well… guess I build whatever I want.”
Same Team:
Developer: “This control has far more states then you designed in the spec. Can you please make a design proposal for the missing states?”
Designer: “I can do that!”
Different Team:
Developer: “I have no design for the missing states… guess I’ll get creative…”
Of course, it is possible to have different teams working on different stuff and still get a decent product in the end. But from my experience of many relevant projects, it makes things way easier, when designers are included into the development process (e.g. scrum) from the beginning and on a day to day basis (e.g. daily stand up). If the design team is only “handing off” the Design System as a tool, they won’t even get the correct feedback. If they don’t really see how developers interact with it, they won’t find any problems (Do they find everything? Do they miss information? Do they use it at all? What are they doing if they can’t find the right components?).
Also, and this is a big one, you avoid that they form opposing groups. From my experience, it is very easy to make developers hate designers and vice versa, if they are not working in the same team on the same tasks.
And from my personal point of view. I like working with developers. As a designer I often find their insight feedback extremely helpful. They usually have a good sense of what power users need and they can usually explain choices and restrictions of the product better than the product managers.
We have a running Design System, there is nothing left to do… or is it?
Having established a Design System within your process is a lot of work. You can be very proud if you managed to do it. Unfortunately, this will not suffice in the long run. Things will change. Different products will need different styles and concepts. Stakeholders, products or even subsidiary companies will need alternations. To deal with that, your system (including your process) needs to accommodate changes and alterations.
You might feel that the easiest solution would be to use one dedicated Design System for each product or something similar. But one big reason for having a Design System is to bundle up all these alterations to create a coherent experience (for users, clients and developers) that is not bound to a single device or product.
In order to do that, system and processes need to be ready for change and alteration. If your system works in a larger, more complex environment, chances are that stakeholders want to push their agendas. Usually, consistency across products and devices won’t be of a top priority for them (“our users don’t need a coherent experience across our product line, they only use one product”). That is unfortunate but in the real world, there is no way around it. The best strategy is to be ready for this.
This means that controls and concepts need to be changed easily. Also, the possibility of having many versions of the same control needs to be a given. Maybe you need different primary buttons, or some controls need AR / VR support. Maybe one product has a different color scheme or even a completely different way of navigation.
It is impossible to “guess” what works for your company or your team. This is definitely a topic that needs to be discussed with team members and stakeholders. The responsibilities need to be clear. Otherwise your system (and your products (plural!)), runs the risk of getting convoluted and overwhelmingly complex to manage. It is fine to have exceptions and you should not place consistency over usability. But never the less, it needs to be clear why and where an exception exists.
Conclusion
A Design System is not just a tool or a framework to help you gather and organize components. In fact, the tooling is not the most important thing. Sure, it is nice if you have a living styleguide, where designs, CSS and your custom components are updated automatically with every build cycle. But if no one is using it, your design language will still be flawed and you will barely be able to handle the amount of design debt your teams create. It doesn’t matter if you have red-lined-PDFs or carbon as your base. Your system will fail and it won’t be a considerable improvement of everything you had before.
So, I cannot stress enough the importance of creating a Design System that is fully rooted in your employee’s workflows. Having a dedicated team and the willingness to change and adept current processes and structures will also be far more important and help you establish a common design language across different products, teams and even companies. A good example of “Design System done right” is our client TRUMPF’s work on their interface design system “Touchpoint” which has been acknowledged with a growing number of design awards like Red Dot and iF DESIGN Award:
If you are interested in finding out more about Design Systems and how we can support you in building yours, feel free to check out our UX Management service page, where we give more insight into this topic.
