This article was previously published in UX Collective.
For a short period of time I worked on a design system at WebNL, an agency specialised in web design, development and marketing based in the Netherlands. Our design system was aimed at improving the bridge between the design and development of the products we’re making.
In this blog I will explain how we did this, and why it didn’t work eventually. Hopefully this will prevent others from making the same mistakes we made, even though we’ve learned a lot from them.
The beginning of the journey
When I started working at WebNL, one of my first tasks was to look into the possibilities of improving the transition between design and development of web products. Traditionally this has been a process of developers ‘copying’ the mock-ups made by designers.
The designers did their work primarily in Sketch. They translated their vision of the product into static designs. The developers then wrote HTML, CSS, Javascript and PHP to convert these static designs into a working product.
One of the biggest ambitions inside the company was to find a way to make this process less time consuming as the work was basically done twice.
So the first step I took was to find out more about ways in which this process of ‘copying’ could be automated. I looked into automation in Sketch and found out there were plugins that used the Sketch API for this purpose. But the plugins I found lacked reliability and I wasn’t really interested in writing my own Sketch plugin.
I looked further and discovered that Sketch had recently opened up their file system format so their files could be used in other tools. Every property of every group and layer in the design was now easily accessible outside of Sketch and I quickly realised that I could use this to translate these properties into working products automatically.
Building the first prototype
After my discovery, I quickly made a proof of concept. It was a very simple prototype that could turn a Sketch file into a working website. A Sketch file is basically a zip file consisting of images and json files. The prototype translated these json files into a Javascript array so it could read all the properties stored inside the Sketch files and use it to generate a standard website.
Our developers were using a centralized file in which SCSS variables were stored. These variables controlled visual aspects of elements like colors, typography, buttons, and form elements. I took those elements and build them into a library of Sketch symbols which could be edited by designers. Designers could then use these elements as a starting point for new projects.
When the visual appearance of these symbols had been changed, I could take the Sketch file and use it to create a new file with variables. Designers could now control these elements in the final product.
There were also some drawbacks. We could only translate the properties of the design into code if they had been standardised. Designers could change properties like colors, font properties, borders and shadows, which were then translated into working code. But the layers and symbols they added would not be translated.
That didn’t seem like a problem. When designers would come up with new properties or elements, developers could just write new code to extend the existing code. I also started making more complicated elements like cards and menus in a standard way to make sure designers would not have to come up with new properties or elements as much as before.
A modular approach for the symbols in our design system
My first prototype got everyone at the company excited. The standardised way things worked had the potential to speed up the workflow of designers and developers alike. While designers could use the standardised elements as templates to make a jumpstart, developers would spent less time on getting things right.
We got permission to spend 100 hours as an investment for future projects. I used these hours to make more elements, and translate them into code. A frontend developer worked alongside me to build the same elements as HTML with SCSS properties.
When we were done, we started using the design system in production. The results were still moderate in the early phase, but showed a lot of potential.
Realising we were building a design system
Ironically, when we started to work on the system we didn’t know what a design system was. We had never heard of it before until our boss introduced the term design system as an existing thing, and as a way to give the project a noticeable name.
We named our project the WebNL Design System, and I started to look into other companies that used design systems.
During this time I read about Brad Frost, a pioneer in design systems. He talked a lot about them, and he was even writing a book about it. From his book I learned about atomic design systems, a concept I implemented in our design system.
Atoms, molecules, organisms, templates and pages
I also read about how Airbnb was automating the design process. They used intelligent image recognition to analyse sketches made on paper and translate them into working prototypes immediately. I showed a video of their work inside my own company and that caused people to be even more excited about the potential of design systems.
Another example from Airbnb was react-to-sketch. Airbnb uses it to generate Sketch symbols from existing React components. They can use the react components as a single source of truth like this. For us that didn’t work because we started a lot of new projects where the Sketch designs were the source of truth. So instead we tried to generate code components from existing Sketch symbols.
This difference also exposed another difficulty we had compared to other companies. They usually had a single brand, providing a single service through a few digital products. But we were making products for a wide range of brands providing even more services. So our design system had to be more flexible.
Vox Media has an excellent example of a flexible design system that can be used across brands. To me, this proves the feasibility of such a design system, even when it will still make things hard when trying to automate the workflow between design and development.
Fixing bugs in production
After the first hype about our design system, things started to head south. We used the system extensively, but never without trouble.
We decided to use the system in short sprints where products were made within one week because that was where we needed it the most. But on several occasions, especially in the beginning, we had to solve issues during the sprints.
Instead of spending time on production we had to debug the system and produce bug fixes. Sometimes the designers had just broken things while editing the Sketch file. During those first trials, I worked on getting fixes into the system and making things more enduring so designers couldn’t accidentally break things.
And it worked, the system became better and more reliable. But the system still wasn’t meeting up to expectations.
Managing expectations
Beforehand we didn’t expect that having a design system that could automate things would have us spent less time on projects. The time we saved could be spent as extra time on our projects, we reasoned. But after a while, a product manager still mentioned that we weren’t spending less time.
So not everyone was expecting the same thing from our design system. But things were also not exactly as how we expected them to be. This was because there were still a lot of bugs, not related to the design system but related to the projects. So any time left at the end of the projects would be spent on solving bugs instead of nice features.
In a way, this was not what anyone had expected to happen. But I didn’t see this as a problem. We just had to make the system more efficient so more time could be freed up, and fewer bugs would be produced.
Error handling
Yet this wasn’t were our problems ended. Even though the system had become more reliable, the designers were still making mistakes while building their Sketch files. These mistakes didn’t result in breaking the system anymore, because I had set up error messages that could be analysed by the developers.
My idea was that these messages would cause developers and designers to talk more about problems together so they would understand each other better. But while they were indeed talking more to each other, it didn’t help them understand each other. The designers still didn’t understand the design system.
Eventually, I even heard some developers who weren’t directly working with the design system talk about how it didn’t work because designers weren’t using it right. I realized that I had to spent more time explaining the system to designers and co-creating with them.
Teaching designers about design systems
I had already spent a lot of time with developers. But I hadn’t spent much time explaining the design system to designers, assuming they would intuitively know how to use it. This was a mistake.
After that realisation, I spent a lot of time teaching our designers how to use the design system. I found out that they had some understanding about components, but they just weren’t used to working with nested components, naming conventions, and working with layer and text styles.
This caused them to ignore some core Sketch principles that the design system relied upon. But moreover, they also weren’t used to working with design templates.
Before the design system was created they always started out with a blank page, using ideation to create new and innovative designs. They wanted each design to be unique and incomparable to another. Even though the design system had been built upon patterns used in their previous work, they wanted to deviate from that work.
This caused headaches with developers because they now had to do more work instead of less, complying with the wishes of designers.
The end of our Design System
We did eventually reach a point where designers understood enough about Sketch principles and design systems so they could use it without much trouble.
But by the time we reached this point, an unexpected decision was made to completely overhaul our standard code base. There would be no central file with SCSS variables anymore, making it harder to generate SCSS variables from our Sketch files. All of the existing code components were also put out of order, they would all have to be rebuild before we could automate them again.
At the same time, another company launched its Design Systems Manager (DSM). This was a product which had become available in beta a short while after we had made the first prototype. Their system offered an API to translate designs into SCSS variables like we had been doing ourselves before. Now it was out of beta and could be used in production.
Even better, it offered a Sketch plugin for designers which made it easier for them to work with the components and styles used in our design system. We also decided that it would be best to switch to their API for future use, as we had found out that Sketch was continuously updating their file format, making it time-consuming to maintain generating SCSS variables ourselves.
These events finally made us decide to pull the plug on the design system. We would have to rebuild the design system in a new way to make it automated again, and we just didn’t have the time at that moment. Instead, we focused on smaller improvements and our new codebase.
Takeaways
I still think design systems can do a lot of good, and at WebNL we are also still working on new design systems for clients. They are just more customized now and less automated. But there are some lessons we have learned that everyone should take in mind before creating their own design system.
- Manage expectations. Don’t make yourself or other people think your design system will change the world by saving you time. Instead, focus on things that are really important, like designers and developers understanding each other.
- Don’t do everything at once. At the start of your journey, it can be tempting to try and make a complete design system. This won’t work as you’ll have to explain and decide upon everything you make together with other designers and developers. Instead, try to take small steps over time.
- Design for people. The biggest mistake I made is thinking that I could improve the connection between designers and developers by putting a system between them. It’s much better to actually get them in a room and have them making decisions together, even when this process takes a lot of time and effort.
I hope these lessons can help you avoid the mistakes we made during our first attempt at building a design system. Hopefully, I will be able to share about our new design systems workflow in the near future. I’m also curious to know about how other people use design systems in their workflow. Leave a comment if you’d like to share your experience or if you have any questions.
"Get your designers and developers into a room and have them make decisions together."
