Design Systems: 5 Lessons Learned
Throughout of my career as a product designer, I’ve watched design systems go from a nascent field to a highly sought-after area of expertise. It makes sense – the benefits of design systems are compelling. Design systems can improve processes at every stage of delivery. With reusable elements in both design and code, teams can move more quickly with fewer revisions. As a designer, who doesn’t love the sound of making less design revisions?
There was hardly a playbook for creating them when I first graduated college. There was a lot of guessing and fitting work in where we could. It was hard to get buy-in and often felt like an uphill battle. Since then, design systems work has been codified by designers worldwide, solidifying it as a key modality of product design. Dan Mall, founder of Design System University, is one of those designers. I had the pleasure of taking one of his courses this year, and seeing him speak at Config in 2023. Dan Mall has created a huge body of work defining said playbook on design systems.
It all started for me at one of my first jobs. I was a visual designer responsible for white labeling a web application, or mocking up our app’s screens with our clients’ branding. After doing this “by hand” a few times, I wanted to figure out how to make the process faster. I learned that my engineering partners were using SASS variables to implement white-labeling on the front end, and I realized I could do something similar in Sketch with symbols and color styles. So I created a base template of our app in Sketch, identifying the areas that would inherit our client’s brand, so all I would have to do was change a handful of values for the next client, saving me hours of work. Eventually, this turned into a system for our entire suite of products – which meant fewer lines of code, happier designers, and satisfied clients.
Google released Material Design 2 around this time. The application I worked on was loosely based on Material Design 1, and I was tasked with helping update it to the new specifications. This was the first documented design system I had ever looked at, and seeing design and code specs in the same context blew my mind. It completely changed how I looked at design.
I began to see how designers and engineers could work together more efficiently and focus on bigger problems. Five years later, I’m still learning how to improve the process of working on design systems. Every project I work on leaves me with new insights. So far, these are my biggest learnings.
Here’s what I wish I knew about design systems before I got into this work:
1. Creating design systems requires reframing how we design.
Creating design systems requires us to adjust our approach to design, just as we adapt our mindset for designing across different business verticals or for native vs. progressive web apps. Successful design systems require the same level of customization and attention to detail.
When working within a design system, we can’t stop at how each element works within one page, one context. We must consider scaling and implementation of each element. For example: Does this card style work in multiple contexts? Does it need to be configurable? How does this table look on mobile? What happens if there are more than 500 characters in a text area? – We must think about the bigger picture, even when working on something small.
2. Design system components should be derived from real products. (Dan Mall, Design System University)
Design systems no doubt significantly improve the product delivery process. However, the priority should always be on designing the product itself. Thus: Do not spend time defining every possible style you may need.
Especially in consultancy, we are literally counting working hours. Please do not waste your client’s time by spending sprint after sprint defining styles you may never use.
In the Design System University course, Make Design Systems People Want to Use, Mall proposes the idea of design system pilots, where a product team can integrate work put towards the design system into the agile sprint process → the product team identifies components to add to the design system strategically, both the product and design system make progress in tandem.
Approaching design systems in this way, we can better ensure that the design system is regularly contributed to, avoiding a graveyard of components.
3. A great design system lets you focus on making things intentionally different where it matters.
With a flexible enough system, design systems give designers the bandwidth to focus on making a product different where it matters.
For example, I once worked with a large design system that spanned business units and products across a company. The components defined by the system were the lowest common denominators, accounting for elements that would be the same across products. Think navigation, button styles, typography. But these products served vastly different purposes. So instead of trying to wrangle a bunch of products under one generic system, they instead defined the components that needed to be the same (typography, logo size/placement, interactivity principles, color scales), then allowed teams to define standards specific to their product themselves (sub navigation, page templates, etc).
On a smaller scale, designers should spend time defining common standard components and thoughtfully identifying what can be the same so they can devote attention to areas that make the experience unique. TLDR; do you really need 10 different button styles? Probably not.
4. Design systems work is both creative and analytical
Many product designers come from graphic and web design backgrounds, where visual impact is a huge factor in a design's success. In my experience, visual impact is table stakes. It will always be part of a designer’s responsibility. But the analytical thinking required of creating design systems adds complexity – asking us to be agile, quickly switching between creative and analytical thinking.
In design systems, success is defined in part by optimization and implementation. On a recent project, I spent weeks working on wireframes and high-fidelity mockups, then switching to contributing to the design system. This means, I went from translating our client’s goals into mockups to combing through mockups to ensure consistency, adjusting typography to work in more instances, defining a scale for spacing, and much more. In that switch, it felt like I was using a different part of my brain.
I would encourage other designers to embrace this duality and get used to switching between these two modes of thinking.
5. Each design system is unique, there is no one-size-fits-all system
Each design system solution is unique to the product; from when you start the work to what components you’ll need and how you’ll work with engineering.
A design system is a functional product, a tool created for designers, engineers, and other delivery partners. Therefore, it's helpful to follow a user-centered design process to understand requirements, level of detail, and overall goals for the system.
Let’s be good shepherds of product design and consider how we can best use design systems to our advantage – making things different where it will make the most impact, planning a design system pilot in a project, and taking a user-centered approach. Choose components wisely. You probably don’t need to define another button.
I hope this has some helpful nuggets you can use in your work. Creating and working with them has led to some of my most satisfying work – I love how design systems can open doors for designers to exercise adjacent problem-solving skills and even work towards contributing to a codebase.
I’m lucky to work with a great group of professionals who love design systems as much as I do. Special thanks to my colleagues Sophie Calhoun, Lexa Gallery, and Alex Swanson – who shared some of their expertise for this piece.
Simply fill out this form below to receive an in-depth white paper from our team of experts on design systems.