Creating a design system from scratch with minimal resources
TL;DR I helped create a design system and later took over project management.
The story of how a tiny team built a design system in parallel to their normal work.
Situation: The UX team was small but growing quickly, as were most other teams in the company. As with most bigger companies there were a multitude of different products and projects with a range of technology from very new to legacy products. For each new project our team had to design everything from scratch, and each person in the team was responsible for multiple products.
Goal: So we decided we had to build a design system to save work on interface design, unify different tools and make it easier for new team members to get up to speed.
My role: First team member, later project lead
Approach
- decide on basic structure, content, technology and rules
- create an MVP
- make the design system known in the company
The basics
Since we had no budget of millions and each team member had multiple other projects to support we started with the bare minimum of what we thought would help our team.
1. Styleguide
We started with a basic style guide to reduce time spent on UI design for new projects.
2. Technology
The design system was set up with a custom confluence template. While this had some serious drawbacks (e.g. not pretty, fiddly editing) the benefits where that the whole company could be given access with the existing permission management, there was no additional cost and noone in the team needed to brush up their HTML and CSS skills in order to contribute.
3. Content of the MVP
We started with creating the first components, patterns and documenting formats.
Having a central place to document formats like e.g. country codes made it unnecessary to look them up for each new project.
Patterns were also a massive time saver because once you have a general pattern e.g. of when to display an error and what info should be in it this does not need to be written down for each feature of each project and all your customers will get the same error behavior across multiple products.
For components we started with the smallest and most used elements like checkboxes, labels or text input fields.
This was necessary to ensure they looked the same and had the same behavior everywhere. One would think consistency across products would not be a big problem, just reuse the same elements each time. But over the years some of the more complex products had aquired problems like having six different date picker behaviors in the same product, each with its own compelling reason why it was needed.
4. Tests
Since aside from our team mostly developers were supposed to use the design system we set up some user tests with a range of experienced and less experienced developers from different teams. The results were mixed and we improved the content so it would be more useful to developers and the structure so they would have an easier time finding the information they needed. But at the same time it became clear that being thrown into a design system with no prior experience in working with one was a confusing experience. Even if it was just a fledgeling design system such as ours.
My work in this
I created the structure of the design system (that is the information architecture), discussed and tested it with developers and teammates and improved it step by step. In this I learned that no structure will ever be so intuitive that everyone can use it. People’s minds work very differently when it comes to ordering things, which is why not only a good structure was needed but also a good and easy accessible search.
I also worked a lot on what amount of specification is needed to unambiguously describe a component. To cover each edge case you can go into a ridiculous amount of detail and every designer has their own style and level of detail. This needed to be unified to be as short but also as precise as possible. A lot of discussions and tests were necessary before I could set up rules for this and train the other designers in writing components.
Writing patterns. A bulk of my work in the beginning was gathering the most needed patterns and writing them down in detail. One would think that very basic UI/UX patterns are easy and you just need to copy and paste them from the internet. But the closer you look the more you will see that everyone does it a little differently for their own reasons. Writing these patterns myself I learned to appreciate these reasons and to come up with a way to unify the behavior so the design system would have a consistent voice.
Writing components. Gathering all our use cases across different products and fitting them all into one simple component was a big part of my work. The detailed workings of seemingly simple components are fascinating to me. Nothing is placed without a reason.
Advertisement "Do good and tell people about it"
Once we had our MVP we needed to establish the design system as a tool inside the company. We wanted it to be useful to other people than just designers as a single source of truth for UI questions.
We planned a launch with multiple blog posts running up to a certain date with a company wide presentation of our work. Since we had realized that this would not be sufficient for people who really needed to work with the system we scheduled a training session with all development teams of the company to give them an introduction on how to work with the system. I conducted multiple trainings and answered lots of questions from all over the company, some of which were good feedback to be brought back to the team.
Growing up
At this point I took over the design system as project lead. We by now had a small development team to develop components for us (though they were still part of another team).
Over the next time I grew the design system based on the needs of the different projects. By now we were established enough that new projects were either set up directly to use our components or at least the responsible designer used the design system for their concepts. Of course I advocated heavily for the use of the design system. Also the questions were far from over. As it was a new and untested tool I had to discuss, explain and defend the design systems to everyone outside the design team. As mentioned in the beginning the design team was growing fast, so I also trained new designers in using the design system and explained the project and its value to them.
Part of my job was to guard the consistency and quality of the content by reviewing and triggering improvements (e.g. when a project brought in user feedback).
I managed the incoming requests and packaged and distributed work to different team members as well as the developers.
The design system today
By now the design system sports a fully fleshed out set of components for agular systems. It is used for almost every new project and rehaul of older projects.
The style guide was updated to match the shifting corporate identity multiple times.
A complete team of UX designer, graphics designer and developers was established to keep the design system alive.
The ever growing library of patterns and typical page layouts speeds up the design of new systems and features and makes it easier for our junior colleagues to take over a project of their own.
Other departments use the design system as a UI reference by now.
I now longer lead the project but instead handed it over to a new team member to take care of other projects.
Learnings
In this project I learned about the use and problems of building a design system from bottom up.
I learned to manage a project myself and how to push and advocate for it in your own company.
By creating lots of content I learned to have extreme attention to detail and when to use that in writing behavior specifications and graphic design