Building an enterprise
design system
/ context
design lead for in-house product
/ skills
- user interface
- design system
- interaction
- concept
/ date
- 2018 → 2021
/ tools
UXPin
Storybook
foreword
This case study is a first-person story of kickstarting and designing a Design System working with a group of talented designers, developers, writers and researchers.
It reflects the rollercoaster of initiating and expanding the design system while sharing the exciting moments, the struggles and the learnings.
Ultimately, this writing is a thank you note to every initial team member of this journey. I appreciate our achievements and what we learned along the way.
background
In 2017 I moved to Denmark, a week after arriving in Copenhagen I got a role as a UI Engineer in a SaaS company in the legal field. The team at the company was small – I was the second member of the design team. During my early days at the company, I was doing all types of work, from coding static pages to wireframing, sketching ideas or doing high-fidelity prototypes.
Later on, I entirely focus on designing user interface and prototyping. Any new design work, small improvements or big features was a combo of creating new UI elements or just copy/pasting from previous projects. This recurring copy pasting was not exclusive to the design team; developers were also reusing code from other parts of the product when implementing the user interface.
That was, without a doubt, a sign that designers and developers had to do something about this. Everyone on the team were familiar with the concept of Atomic Design and design systems.
It just felt natural that we all thought:
the language
Just before we started working on the design system, we got a new member on the team. Being three in the design team gave us more space and confidence to pave up the way to a promising start of the design system work.
We were having conversations about the design system every week. However, the project did not truly start until we sat down in a cozy café in Copenhagen and started writing the foundations and the terminology of the project.
I treasure this moment of collaboration.
A couple of hours (and a few coffees) later we had in front of us a first draft of the design system terminology. These words defined and aligned the communication of everyone in the team.
proto-design system
The first version of the design system arrived quick. We approached the challenge as a proof of concept – after all, we worked on it during our own time. Planning, designing and developing from the sidelines to show the value of the project to the rest of the company.
The proof of concept included what we believed were the most essential elements of the design system: typography, colors and components.
It was important for us, designers and developers, to have a common goal – from the beginning, we wrote a purpose for the company’s design system.
We asked ourselves, what is a design system?
A modular toolkit which enable teams to create transparent, uniform and reliable products.
A set of standards of standards for design and code with components that unify both practices.
To make this happen we started on the simplest of the ways. The designers focused on scanning, top to bottom, the fundamental views of the product collecting styles and repetitive elements from the user interface.
Meanwhile, developers would start a boilerplate for the prototype. Then, followed up on one item at a time, writing the code for each component.
A couple of months later we had a working prototype both with a code repository in Storybook and a early symbols library in UXPin. The process was a learning experience for all of us. Although, we did it in our spare time, we all had a sense of ambition and pride for this work.
In retrospect, the first prototype taught us two important lessons:
→ The benefits of organizing the UI patterns and styles to create a common language for the team and the product.
→ Bridging the gap between designers and developers strengthen the bond between both practices and improved the collaboration.
We had our very first version of the design system and we were excited to keep working on it.
design system as a service
After our first prototype, we all recognized the design system as more than a side project. Indeed, for it to succeed, the pace of our work had to be consistent.
We adopted the mindset of: "A design system is not a project" – inspired by a quote from Nathan Curtis:
Embracing the idea of a design system being a service changed the perspective of the team. We no longer focused only on components, styles, code and guidelines.
We focused on people.
for designers
Together with developers, we started to look at what the Design System meant for designers. The system is a useful communication tool for designers and developers but also for other areas of the business.
With such a small team, having a handy toolkit to assemble user interfaces with ease would help us concentrate on other areas of the design process: concepts, discovery, journeys, and research.
We built a symbols library in UXPin.
In addition to the UXPin library, the other main outcome of the design system for designers included a portal with documentation. The Design System Docs cover topics such as components, processes, colors, typography and guidelines for copywriting, accessibility, data visualization and inclusion.
for developers
Developers maintain a repository of code with the design system’s components and styles that are accessible through the design system documentation.
Regularly there are meetings between the designers and the developers to decide on new components, updating existing components or discuss next steps for the design system.
for everyone
The design system is a useful resource for everyone in the company. It offers a detailed look into the design process, the guidelines and the individual elements used to create the user interface. It can become the go-to place to download resources such as logos, visuals, and other assets.
The design system docs, is also a living proof of the work from designers and developers. This makes the rest of the organization more aware and familiar with our work.
Moreover, the design system is a welcoming space and contributions from other teams are welcome (i.e. data visualization, technical writing, marketing).
Over time we added expanded the system adding more guidelines.
learnings
My most significant learning from this project is that every design and development team is different. As a result, the purpose of the design system needs to readjust to the team's expectations.
At some point, we were very ambitious. Only to realize later on that we might have needed a more straightforward solution. Asking ourselves who are we building it for and why are we doing it was an excellent way to keep us on track.
Another takeaway point is to take every step as a team. Since the beginning, we took on this project in full swing from the development and the design side. It was a great collaboration, and it is, amongst other things, because of that why we were able to build the design system.
acknowledgements
Original members of the Design System team
design
Thai-Dan P.
Sandra D.
Ramsés C.
development
- Maxi G,
- Bjarki M.
- Christos K.
- Ionut V.
collaborators
- Sherin P.
Contact
email@domain.com
000-000-000
Thanks to my colleagues for the feedback on the case study / 3D Animations by Rotislav Uzonov