{"id":8480,"date":"2018-07-11T12:11:10","date_gmt":"2018-07-11T10:11:10","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/?p=8480"},"modified":"2020-01-25T19:29:29","modified_gmt":"2020-01-25T18:29:29","slug":"is-it-enough-to-create-a-design-system","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/en\/blog\/is-it-enough-to-create-a-design-system\/","title":{"rendered":"Is it enough to create a Design System?"},"content":{"rendered":"

\"\"<\/a><\/p>\n

This article won\u2019t cover the basics of Design Systems like \u201cWhat is a Design System?\u201d, \u201cHow does it work?\u201d or \u201cDo I need it?\u201d (to which the answer is \u201cYes\u201d). It will also not cover tool specific topics (Carbon, KSS, Pattern Lab, Sketch, AdobeXD, Invision, UXPin\u2026 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.<\/p>\n

The main question we usually get from clients, regarding Design Systems, is something like: \u201cHow do we create a Design System?\u201d. Or: \u201cWe want you to create a Design System for us\u201d. But actually, what this means for us as a service provider is:<\/p>\n

\u201cIs creating a Design System enough?\u201d The short answer is: No.<\/p>\n

Congratulations, you don\u2019t have to read any further. Now you can go outside and enjoy life. If you don\u2019t like to be outside or if you want to dig deeper, here is the longer answer:<\/p>\n

<\/p>\n

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\u2019t help if you use the fancy carbon Design System but your tech is based on Winforms or Java. Or your designers don\u2019t use Sketch, or you don\u2019t have any designers at all.<\/p>\n

Maybe, having a \u201cclosed\/ready-made System\u201d 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\u2019t 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.<\/p>\n

It doesn\u2019t 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.<\/p>\n

The good news is: If you don\u2019t do things completely random, you already have a system. But chances are that your current system doesn\u2019t take consistency for design and usability into account. The real challenge is to integrate these parts into your current work process.<\/p>\n

Do I need a Design System Team?<\/h3>\n

 <\/p>\n

\"\"<\/a><\/p>\n

I am sure there are companies who work with a Design System without having a dedicated \u201cdesign team\u201d 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.<\/p>\n

Having all these nice tools like carbon Design System<\/a>, zeplin<\/a> and brand.ai<\/a> (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\u2019t cut it.<\/p>\n

I see tools like musical instruments. If you can\u2019t play them, or if you don’t even know what kind of instrument you want to play, you won\u2019t 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.<\/p>\n

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.<\/p>\n

I have a team, now what?<\/h3>\n

\"\"<\/a><\/p>\n

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.<\/p>\n

This is key for the integration. It doesn\u2019t 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.<\/p>\n

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.<\/p>\n

Here are some basic examples of typical problems:<\/p>\n

Same Team:<\/h5>\n

Developer: \u201cOur framework does not support this fancy paging combobox you designed. Also we don\u2019t have time to create a new custom control.\u201d<\/p>\n

Designer: \u201cOk, I\u2019ll come up with something that fits our standard controls we already have.\u201d<\/p>\n

Different Team:<\/h5>\n

Developer: \u201cI can not build what the designer wants\u2026 well\u2026 guess I build whatever I want.\u201d<\/p>\n

Same Team:<\/h5>\n

Developer: \u201cThis control has far more states then you designed in the spec. Can you please make a design proposal for the missing states?\u201d<\/p>\n

Designer: \u201cI can do that!\u201d<\/p>\n

Different Team:<\/h5>\n

Developer: \u201cI have no design for the missing states\u2026 guess I\u2019ll get creative\u2026\u201d<\/p>\n

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<\/a> (e.g. scrum) from the beginning and on a day to day basis (e.g. daily stand up). If the design team is only \u201chanding off\u201d the Design System as a tool, they won\u2019t even get the correct feedback. If they don\u2019t really see how developers interact with it, they won\u2019t find any problems (Do they find everything? Do they miss information? Do they use it at all? What are they doing if they can\u2019t find the right components?).<\/p>\n

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.<\/p>\n

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.<\/p>\n

We have a running Design System, there is nothing left to do\u2026 or is it?<\/h3>\n

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.<\/p>\n

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.<\/p>\n

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\u2019t be of a top priority for them (\u201cour users don\u2019t need a coherent experience across our product line, they only use one product\u201d). That is unfortunate but in the real world, there is no way around it. The best strategy is to be ready for this.<\/p>\n

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.\"\"<\/a>It is impossible to \u201cguess\u201d 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.<\/p>\n

Conclusion<\/h3>\n

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\u2019t matter if you have red-lined-PDFs or carbon as your base. Your system will fail and it won\u2019t be a considerable improvement of everything you had before.<\/p>\n

So, I cannot stress enough the importance of creating a Design System that is fully rooted in your employee\u2019s 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 \u201cDesign System done right\u201d is our client TRUMPF\u2019s work on their interface design system \u201cTouchpoint\u201d which has been acknowledged with a growing number of design awards like Red Dot and iF DESIGN Award:<\/p>\n