currently work at Microsoft on the Fluent Design System and Teams Component Library. Previously I worked at EagleView and helped design their first design system.
I’ve always loved the idea of approaching design systematically, with global styles, rules, and guidelines. In the beginning, this concept was curiously intriguing to me. But, like many designers working on their first design system, I underestimated the feat of the task at hand.
The following is a brief account of my journey and career in design systems. I hope that you find my experiences useful wherever you might be on your path in design.
Once upon a time
EagleView gave me my first shot at design systems. They had a large portfolio of digital products (~20) and each looked vastly different. On top of that, they had multiple products in various stages of flight and on different platforms (native and web). The leadership, design, and engineering teams had come to a consensus that they needed a design system from identifying the following problems (most of which are more common than we would like to admit):
- Onboarding designers to multiple UI libraries and engineers to multiple codebases was tedious and prone to redundancies
- Engineering sprints were bogged down by the development of the same components over and over again (How many times do we need to create a button?)
- Designers were spending countless hours crafting one-off UIs for new products
- Customers (users) were experiencing a lack of cohesion across platforms (e.g. native and web) and applications, resulting in jarring and confusing experiences
The list goes on…
To make things more challenging (depending on how you look at the situation), I was given only one requirement, the Design System needed to be built in React. Sounds easy right? I didn’t know where to start.
Start with what you don’t know
I learn best through hands-on problem-solving. Throw me into the deep end of a pool and I’ll usually swim. My initiation into the design systems’ world was kind of like that, but in the dark, blindfolded, and with a lot of sharks (ok maybe not the sharks part). I realized that there were many things about design systems that I simply did not know, but how to remedy my predicament was unclear. YouTube seemed like a good place to start. So, I typed “design systems” in the search bar and clicked on the first video that looked interesting. The following videos were (and still are) extremely helpful to me:
- The Future of Design Systems | Hayley Hughes | Airbnb | Awwwards Conf San Fran
- Reimagining Design Systems at Spotify — Shaun Bent — Design Systems London 2019
- Material Theming: Build Expressively with Material Components (Google I/O’19)
- Design Systems, when and how much? — Diana Mounter
- How to Design a Dark Theme Using Material (Google I/O’19)
- Building (And Re-Building) the Airbnb Design System | Maja Wichrowska & Tae Kim
I approached my research with an open mind, soaking up as much of the knowledge as I could like a sponge.
Define principles and priorities upfront
In an episode of the Design Better Podcast, Brad Frost, design systems expert, and creator of the Atomic Design Methodology spoke about how essential it is to define which aspects of a new design system are most important to the team and company.
Getting the key stakeholders in a room and agreeing on a few principles and priorities before even putting pen to paper, is critical.
If you do this, when the going gets tough, one can always refer back to that day, asking, “Do you remember when we agreed that this (thing) is the most important part of our new system?” Now, this isn’t to say that priorities and principles can’t change, but having a reference point or a north star helps to guide the systems designer(s) and keep everyone on track.
Define success metrics
There are several ways to measure the success of a design system. At EagleView, we collectively wanted to: increase our sprint velocity by ≥50%, free up as many design hours as possible, and increase collaboration productivity by creating a shared language between design, engineering, and product. The last two metrics are a bit ambiguous and I suggest you check out these two articles if you are looking to get more granular with your KPIs:
- How To Save 35 Hours Using A Design System | Marcin Fuja
- And You Thought Buttons Were Easy | Nathan Curtis
“Using a Design System can remove over 50% of the time needed to design, develop and test, in addition to ensuring consistency and giving your team more time to focus on what’s important: quality and innovation.”
– Marcin Fuja, Sr. Frontend Developer @ PGS Software
Design with context
Let me save you a few hundred hours — designing design system components in a box with no context is a waste of time; don’t do that.
“Successful design patterns don’t exist in a vacuum.”
– Yesenia Perez-Cruz, Sr. UX Manager, Polaris Design System
At EagleView we identified a core product that would be our guinea pig for the Design System and informed us which components that I would design and work with engineering to build. Nearly every component I designed and was built was contextually driven.
My work at Microsoft is a bit more matured because we have an enterprise design system that is several years old. Contributing to a mature system vs. a young system yields similarities and differences. At EagleView I was the only systems designer, while at Microsoft I have much more support. Both types of situations can serve value, and I have learned a lot from both experiences. Below is an example of our React <Button /> component in context.
Establish a process
It becomes easy to get lost in the work, no matter the size or maturity of your design system. Establishing a process helped keep me on track and my collaborators in the loop by providing realistic ETAs on requests. After reading this article on how Atlassian’s design teams leverage Jira, I was inspired to test it out with our design system. While at EagleView I created a Kanban board using Atlassian’s Jira Software and at Microsoft, we use Azure DevOps to track our work.
“Kanban is a popular framework used to implement agile and DevOps software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.”
– Atlassian
The board I created had six columns. When a ticket was first created, it sat in the “Backlog” column. Once a new component or feature was prioritized in a biweekly backlog grooming session, it was moved into the “Exploring 🐕” column. Initial research, accessibility checks using WCAG, Apple’s HIG, and Material Design, and mocks would be conducted and created. The ticket would then move to the “Sparring 🥊” column, which was a fun way to say design review. The whole design team would review the work I presented, make critiques, and provide suggestions. Next came the “Finalize Specs 📐” column. This was where I would make adjustments based on the feedback I received, and create every needed component variation e.g. all the states of a button. I would also perform a final accessibility check. After my checks were complete and specs were finished, I would move the ticket to the “Final Review & Sign Off 🔍✅” column. Depending on the ticket, either the Director of UX, Director of Product, or a product manager would comment on the ticket with their approval, and the ticket would then be closed out and moved to the “Design Done 🎉🍺🍷” column.
This process was not perfect, but it helped bring transparency and accountability to the work that was conducted.
Understand your tech stack
Should designers learn to code? The short answer is no. Here’s the thing though, that’s kind of like asking if you need to learn to speak Russian if you want to visit Russia. You don’t need to, but you might have a better time visiting Russia if you know Russian. I’ve been to Russia and I wish I knew Russian at the time.
I am no expert but I took it upon myself to learn HTML, CSS, and React. The more I coded, the more I learned, and the easier it was for me to communicate with my engineering counterparts, write component specification documents, and understand technical constraints and possibilities. Having at least a basic understanding of front-end languages will help you accomplish more with your designs and work better with your engineering partners.
Learning the ins and outs of your design tool is critical. Before EagleView, I had only worked in XD (insert sad face here). Shortly after switching to Figma, I was converted. It was love at first sight.
Whatever tool you do use for your design system, keep learning. There are countless videos and resources to help designers understand all the nuances of their software. I always do my best to keep up to date with Figma.
Final thoughts
Thanks for taking the time to read my story. If you are starting out on your first design system, don’t be discouraged, we all have been there before. Keep reading and watching content, make friends with other design system designers, and most importantly, ask for help when you need it.