Why design systems fail and how to make them work in 2020
After shutting down our first design system late 2018 we built a new and improved design system from the ground up.
Back in 2018, when I started my job at WebNL, I was asked to look into ways to improve the bridge between design and development within our company. I came up with a system that automatically extracted design tokens from Sketch designs and translated them into SCSS variables. This was also our first design system.
For numerous reasons this first design system failed. You can read about how it worked and why it failed in my previous article.
In the article you are reading now I will talk about our new design system at WebNL. It is still about improving the bridge between design and development, but without the complexity of automation and the urge to cut down on time.
Switching to Figma
Our first design system was mainly shut down because we were forced to overhaul our codebase. But there were also a lot of problems that needed to be fixed. So we decided to start from scratch.
We learned that Sketch, the tool we had been using, wasn’t the best tool for building design systems. So we chose not just to start with a new codebase and a new design system, but also with a new design tool.
Figma became our new design tool. It’s great for building a design system because of its component library feature. Components can be shared in a library across design files, and they can be pushed and pulled like code in a version control system. For us this was much better than what Sketch offered at the time, even in combination with Invision Design System Manager.
Also, Figma launched an api that could be used to read their design files in other applications. One of my problems with Sketch in our previous design system was that they repeatedly changed the structure of their api and file system. That required me to keep changing my automation in order for it to keep working. Figma promised to keep changes in their api to a minimum.
I was still concerned with Figma’s performance in the browser though. Sketch was already performing badly with big design files. It could only be worse in the browser, I thought. But I was wrong. Figma managed to make their browser based design tool faster than native design tools, even when multiple people were working in the same file simultaneously.
This convinced me we had to switch from using Sketch as our main design tool to using Figma. But deciding that for myself wasn’t enough. I had to convince my entire team.
My boss was already positive towards Figma, that was encouraging. But our designers liked working in Sketch. They had no reason to switch. Getting them to learn a new design tool wouldn’t be an easy task.
I started by making a roadmap. First, I would start sharing articles and tutorials. Then I would demonstrate how to use Figma in person. Finally, when there would be enough trust, I would ask people to try Figma for one or two projects. It would take me some months.
But after six weeks, everyone had already been convinced. It turned out that when our ux designer had been convinced, the other designers were willing to follow. We made the switch to Figma and I was ready to build a new design system.
Making the switch wasn’t really the end of it though. At first, there was a lot of complaining about trivial stuff like dropping images inside frames, or creating masks. This worked a little different inside Figma and Sketch, which required designers to get used to those kind of things.
By being patient, willing to explain and showing confidence in our new design tool, I tried to convince everyone that there was really no reason to go back to Sketch.
After a while, two new designers joined our team and were able to get used to Figma quickly, while they had also been using Sketch before. This proved that we had made the right choice, and that there were really no big drawbacks.
Researching user needs
I also learned some other things from building our first design system. People using the design system have to be involved often and early on. And besides that, I also learned that our designers didn’t like atomic design or big combined components. A new design system needed to be restricted to small and general components like buttons and input fields.
Our designers had also become sceptic towards design systems because they started to feel it limited their creativity and heightened the risk for errors. But we still needed some kind of starter kit to close the gap with our developers. So instead of talking about design systems, I talked about starter kits, components and documentation. Things that people could actually understand and use.
Around the same time, I went to a meetup at another agency called Angi Studio. They specialize in creating design systems for their clients. They also developed a tool called the Design System Checklist. It originates from an exercise created by Nathan Curtis.
In the meetup, the checklist was used as an exercise. I decided to use it as a survey for our design team, so everyone could share their opionion anonymously. I collected the results and created a combined list of the parts that needed to be in our design system.
The survey showed our designers still wanted templates in their starter kit. I had avoided templates in our first design system, because I wanted to give designers building blocks for their designs. But even these building blocks became too big for our designers to work with. So I was surprised they still wanted templates.
In our new design system, I decided to use both templates and small building blocks. Designers would then be able to choose, or use a combination of both. This way they could kickstart their design with a basic structure from a template, or start from scratch with just some small building blocks.
Building a starter kit
Before I started I knew I would still have a hard time convincing our designers to use the starter kit. They were used to working from blank pages for every new project. Of course they would have to recreate buttons and typography styles for every new project this way, but they simply didn’t care. They were just creating pages.
But when frontend developers see the design, they need to turn it into a system of different components. When a designer doesn’t think about that while creating the design, turning it into a system will be more difficult. So I started with making a styleguide in Figma consisting of basic colors, typography, buttons and input fields already in place as a system which designers could use.
I explained to our designers why other frontend developers and I needed to see a styleguide alongside their designs. They understood they could help us out, and they became willing to use the starter kit in their workflow.
Next, I needed to create templates from these components and styles. From our survey I knew that our designers and frontend developers wanted templates for homepages, product pages, article pages, search pages, contact pages and category pages. Since corporate websites are the kind of work we mostly do, I started with templates for homepages, article pages and contact pages.
Another complaint we had was that websites were always designed for desktop, but never for mobile. Partly, this is because of the way we work. In our company the frontend engineers are responsible for making a website responsive. But sometimes designers and clients have their own opinion about mobile design. So I made sure to include templates for mobile screen sizes as well.
And because corporate websites come in all kinds and sorts, I made these templates as generic as I possibly could. I even used a photo resembling the default background of a well known operating system. But for the webshop templates, like product, category and search pages, I could take a different approach.
Webshops have lots of pre-existing patterns that users have become ‘used’ to. They expect this kind of behavior from a webshop, and deviating from this is not recommended when making an mvp. Because of this I was able to make these templates fairly detailed. Best practices like GDPR compliance could all become pre-fabricated.
When we first used these templates to create a new design for a webshop the results were great. Our designers would normally be able to produce just three or four templates, but we were now able to create four extra pages in the same amount of time. This enabled us to agree with the client on more details before development started.
I also created templates for our dashboards. These templates contain components like tables, graphs, charts, tooltips and modals. The components are build in a way that allows them to be resized easily without breaking constraints.
Documentation in Zeroheight
Before we switched to Figma, we briefly used Invision Design System Manager to write documentation for our designs. Design System Manager also offered an option to convert design tokens into SCSS variables, reducing the need for us building this functionality ourselves like we did before.
Sadly, Design System Manager didn’t offer support for Figma at the time. But this didn’t stop us from making the switch to Figma. I trusted that support for Figma would be coming soon, and if not, some other tool would fill the gap. And I was right. After a few months, we discovered that Zeroheight offered the same functionality as Invision Design System Manager did, but for Figma.
We’re still not using this functionality in Zeroheight though. Because of our experience with our first design system we learned that we weren’t ready for automation yet. In the future we might start using automation again, but not until our design system has reached enough maturity.
Despite this, Zeroheight is really great when it comes to documentation. I used it to explain the styles, components and templates in our design starter kit. And I also used it to document our code with snippets and examples.
Since we rebuild our codebase, our components are built with Vue, Laravel and BEM. This means that we use seperate HTML, SCSS and Javascript files, mainly for SEO reasons. So I also need to show these seperately in our documentation.
In Zeroheight I could do this by embedding examples from anywhere on the web, like Codepen or a Storybook. But I prefer using Zeroheights codeblocks, which offer the same functionality but the code is stored in Zeroheight. That way other developers can also edit the examples in our documentation.
Right now we have our design components and code components right next to each other. Designers and developers can compare them, and see what they need to create designs that feature pre-existing code components, or they can see which code components they need to quickly turn designs into code.
Adoption among designers and developers
It’s one thing to create a design system, but it’s also important that other people start using it. So a lot of my effort this year went into talking with other people about what they needed, and how they would use certain parts of a design system.
Getting our designers to use our design system was a success. They particularly liked using the pre-existing styles, buttons and input styles in Figma because it saves them much work and they know that frontend developers can understand their work more easily.
Getting them to use the templates in the design system was a bit harder. But using the templates in pilot projects helped a great deal. When we used the templates to create a new design for a webshop, the designer who worked with me got a better understanding of the value of these templates.
Another important factor in getting designers to participate was listening to user feedback. Over the year, there were multiple moments where I asked designers what they thought about working with the design system, and what they thought could be changed or added to the design system.
Adoption amongst developers was a bit harder. Of course they would use the styleguides created by designers. And they would build reusable components with our new codebase. But getting them to use and contribute to the documentation did not work out yet.
To raise awareness about the documentation, I put out messages on Slack each time I created a new component. And everytime someone asked me a question, I pointed them there. But a lot of times I heard that they had forgotten about the documentation, or the address had ended up somewhere between their bookmarks.
Next year: A design system team and process
To see how a design system ranks on maturity, John Gully and Marcel Somers from PatternPack have created a maturity model for design systems. Their system ranges from inconsistent, where a design system is absent, to governed, where the pattern library process is built into the organisation.
Comparing our design system to this model, we managed to get from inconsistent to beyond manual. After we ditched our first design system, we have now built a new documented pattern library that also contains code snippets.
I could even argue that our designers are at the governed stage. They use the design system in every new project and they are contributing. But our developers are not at the highest stage yet. They are still not looking at or contributing to the documentation enough. So next year, there are two things I would like to do to improve this.
First, I think our design system deserves to have a name now. We are now at a stage where I tell people we have a design system, and they should use it. But people keep forgetting that the design system exists. So we need something for them to remember: A great name.
The second thing I want to do is setting up a design system team and process. I can no longer maintain the design system by myself. It is growing larger at a steady pace, and changes to design and code are always needed. We have actually already started on building new reusable components in a team. But I am still looking for the right process which doesn’t just support building components, but also involving users and writing documentation.
By working as a team, I would also like designers and developers to collaborate more. The gap between designers and developers might become a little bit smaller this way. In 2020, I would like to do a series of sprints by keeping a backlog withuser stories, creating new styles, components and templates for our design system, and write more documentation about it.
Takeaway
After starting from scratch, our new design system has grown and is now being used across WebNL. I have learned a lot from our previous attempts that I used to make our new design system a success. But there are still things that can be improved next year.
Involve others early and often. Building a design system takes a lot of time and effort. Involving others in this process without rushing into things has helped me a lot. But still, involvement of others can be improved for us.
Name your design system. When your design system has reached enough maturity for it to be used, you need a name for it. When you have a name, people will remember it more easily and you can start promoting your design system.
Set up a design system process and team. At a certain point, your design system will grow too big for it to be maintained by one person. Set up a process and divide roles for UX researchers, UX designers, developers and project managers so they can contribute more easily.
Leave a comment if you’d like to share your experience with building a design system or if you have any questions.
