Sample Chapter: Design That Scales
This is a sample chapter from Dan Mall’s book Design That Scales: Creating a Sustainable Design System Practice. 2023, Rosenfeld Media.
Chapter 1
Why Design Systems?
Think about all the Google products you used today. Maybe you checked your email using Gmail during some early part of your day. Perhaps you drove to your office or to an appointment using Google Maps to help with directions. You probably needed more info about something, and you looked it up on Google Search, perhaps using Google Chrome. Maybe you collaborated with a colleague on a Google Doc or Google Sheet. Maybe you watched a video on YouTube. Maybe you did all of that on an Android mobile device.
As a user, you probably didn’t give much thought as to what it took on the Google end to make this kind of day possible for you. And you shouldn’t! All you should care about is whether or not you’re getting the experience you want from using these applications.
Systems Connect Organizations
But what does it take for Google to deliver this holistic experience for you? As of this writing, Google—technically Google’s parent company, Alphabet Inc.—employs almost 140,000 people. Google also works with many external partners and agencies to help them accelerate and innovate on the digital products they create for their users. Keeping thousands of people aligned from a design and engineering perspective requires some kind of system, a set of things working together as parts of a mechanism or an interconnecting network. For organizations that make digital products, one of those systems is called a design system. Here’s my definition:
A design system is a connected, package-managed, version- controlled software product that contains the smallest set of components and guidelines a particular organization needs to make digital products consistently, efficiently, and happily.
This is a mouthful! I’ll explore and explain each of these words and phrases in greater detail in Chapters 2, “Design System Fundamentals,” and 9, “Success Metrics for a Design System.”
Google’s design system is called Material Design. In Google’s own words, Material Design is “an adaptable system of guidelines, components, and tools that support the best practices of user interface design.” (See how close that is to my definition?) Without Material Design, Google employees and partners would be left to design and build each product and screen and interaction and element from scratch each time, creating an incredible amount of effort and unwarranted variation. Having a shared system like Material Design means Google designers and engineers can quickly reference common solutions (Figure 1.1) that are ready for implementation.
Figure 1.1
No matter what Google application you use, the floating action button component always provides easy access to the primary action of a screen in the bottom-right corner.
Design systems aren’t just better for the designers, engineers, product managers, and rest of the team creating digital products. Design systems prove better for users, too, because they don’t have to relearn interaction conventions from application to application. A 2016 Forrester study found that consistency in customer experience led to a 24% increase in revenue, and design systems tend to create interface consistency by their nature (Figure 1.2).
Figure 1.2
Even if you’ve only used one Google product header, you know how to use them all.
But maybe you don’t use Google products.
Maybe you use Microsoft products. Microsoft takes the same approach with their Fluent Design System.
Maybe you use IBM products. IBM takes the same approach with their Carbon Design System.
Maybe you use Salesforce products. Salesforce takes the same approach with their Lightning Design System.
The list goes on and the point is clear: organizations that create and maintain two or more digital products often turn to design systems to help them solve the problem of digital product management at scale. If your organization wants to scale digital products, design systems aren’t just a good idea, they’re an inevitability.
Common Benefits of Design Systems
Design system aficionados often espouse three main benefits of design systems:
- Using a design system advocates efficiency. Starting from scratch and reinventing the wheel each time a digital product is made is a major culprit of digital overspending. Having proven solutions at the ready helps teams address problems more quickly.
- Using a design system generates consistency. Design systems prioritize reusability across digital products, and reusability is the main ingredient in consistency.
- Using a design system spawns innovation. Moving designers and engineers from creating everything from scratch to reusing common interface and interaction remedies frees up their time to address unfamiliar problems and invent solutions for them.
I also like to add a fourth:
- Using a design system bestows relief. Digital product teams regularly stress over unrealistic deadlines and wicked problems. Design systems give them a cheat code that gives them time and space back so they can breathe more easily.
Realizing these benefits is easier said than done. Many success- ful design system initiatives instigate cultural and organizational transformation, and unsuccessful attempts frequently die due to organizational politics. An ingrained and lasting design system practice is necessary to bring about these benefts.
Who Are Design Systems For?
Anyone who works on a digital product team can beneft from a design system. While this book focuses primarily on the roles of the famed “three-legged stool”—design, engineering, and product— design system work includes many other disciplines like content, QA, research, illustration, business analytics, behavioral science . . . any discipline typically found on a digital product team.
Unsurprisingly, these are also the roles useful in making a design system for an organization. It’s natural for a design system to start within a particular discipline like design, IT, or UX. These design systems often fail to gain traction, because it’s too easy for the rest of the organization to see it as “someone else’s library.” A design system needs to belong to everyone, which means it can’t really belong to anyone. Working on, contributing to, and maintaining a design system is truly a democratic and collaborative exercise. The rest of this book will show you how to avoid a siloed birth for a design system and instead create one that eventually represents an entire organization.
Questions for Reflection:
- Does your team or organization manage two or more digital products?
- What kind of efficiencies in tools and processing could your organization benefit from?
- Do you already have a design system in your organization?
Succeeding in Design Systems
Hayley Hughes is a seasoned design system expert who has worked at some of the largest and well-known enterprise organizations of our time. I asked her a few questions about her experience with design systems and what it takes to succeed in the space.
What is a design system to you?
To me, design systems are a community of practice made up of diverse teams within an organization. This practice involves teams collaborating in an ever-evolving feedback loop of observing, making, and reflecting on what a quality experience means for their users, and how to deliver it. The community creates and governs shared platforms and tooling for scaling insights, standards, assets, and services across an enterprise.
You’ve worked on design systems at the largest scale at some of the world’s largest organizations. What skills do you need to work at that level?
At larger organizations, the design system supports thousands of people, from in-house teams to external partners. It needs to work for diverse audiences in a variety of geographies and environments using different devices and technologies. With so many use cases, the system needs to enable unity, not uniformity—rallying teams to create cohesion across experiences, while giving them flexibility and a wide range of expression.
Going from small to large companies is as much a mindset shift as it is a skillset. You stop thinking of systems as a purely pixel-and-code craft and start thinking of systems as a state craft of operationalizing people and practices.
Operational skills like facilitation, coaching, and diplomacy help you organize movements and manage change with large groups of people. That means you drive alignment conversations between a dozen teams. You coordinate rollouts that cascade changes across hundreds of products. You create educational materials for training design system trainers. You build domain knowledge in the product development cycle and identify ways that systems can improve institutional capacity. You look for patterns—matchmaking people and resources. Pixels and code still matter, but you hire others with the skills that it takes to do those jobs, while coaching them on the skills it takes to scale systems.
What are some commonalities between every design system you’ve worked on?
I’ve worked on a handful of design systems at IBM, Airbnb, Nike, and Shopify. One reason I chose to work on these systems is because the people leading them have common values. First, they understand that the purpose of design systems is to improve the quality of decision- making on teams versus just shipping faster. Second, they really care about driving collaboration across teams and introducing changes in a thoughtful way. Third, these teams prioritize equitable work in areas like accessibility, inclusion, localization, and ethics.
From a team size perspective, most systems I’ve worked on had a core team of designers and developers that might range anywhere in size between a handful to a few dozen people at any given time. They’ve all had a shared design language, component libraries, documenta- tion site, and enablement program for training and partnering with product teams. Usually, the system has been positioned horizontally, reporting in through a design, operations, or infrastructure function.
What are some differences in organizations that make each of their design systems unique from one another?
Every design system I’ve worked on has been at a different stage of maturity. IBM’s design system was built from the ground up, devel- oping a design language for everything—not just the software and hardware, but also the physical buildings, business cards, events, advertisements, you name it. Airbnb had trouble getting people to use the system, so I was asked to help drive adoption. Shopify wanted to expand to become a system of systems. This meant focusing on governance and enabling teams to create local systems. Nike’s system needed to become more fexible to support more differentiation across brands, geographies, and use cases. Every system has similar problems, but depending on which stage of maturity they’re in, you might be prioritizing one over another.
How did your career path prepare you to work on design systems so effectively?
There is no one career path that leads you to being effective in design systems. I’ve had teammates who were former biologists that were experts in feedback loops or lawyers who knew how to handle open source licensing. People in design systems come from all different kinds of backgrounds.
A common theme in a design system career path is the idea of being hybrid, or showing interest and capability in multiple domains. This concept most often refers to hybrid skills in design and development, but there are many types of hybrids. Part of becoming a hybrid involves trying on many hats before defining your role in design systems. By doing so, you become an interdisciplinary thinker with more empathy for others.
I wouldn’t call myself a hybrid, but I have spent most of my career doing interdisciplinary thinking. I first worked at nonprofits focused on influencing political and environmental systems. Then I worked at restaurants and art museums that created hospitality, brand, and wayfinding systems. In grad school, I studied healthcare and local food systems. Now, I’m focused on design language systems.
What advice would you give to someone looking to break into a design system career?
Look for the holes. If you’re able to sell the holes as an actual problem, then you can put yourself in a position to fix them. Do the research to show that you know what teams need. For example, if you’re seeing issues with accessibility in a product experience, dig deeper. The business should also care because it probably has requirements it has to meet around compliance to avoid litigation. Combine the user needs and the business requirements into a compelling opportunity, and solve for that.
You don’t even need to say the words design system at first, even if that’s what you’re technically making. Once you solve it, you’ve built trust to ask for more investment, perhaps another teammate or resources to keep filling other “holes.” Keep tracking and measuring the outcomes of the problems you’re solving. Eventually, these things snowball where you can share full case studies and reveal the system that powers them.
What encouragement would you give to design system veterans?
If you’re in an organization that struggles to reward systems work and promote systems people into higher levels, don’t give up. There are periods in your career when no matter what you say, people just won’t “get” systems. Maybe it’s because they require a tolerance for some degree of complexity. There will be other times where you’ll have incredible advocates who not only “get” systems but invest in you and your team. There’s some peace in knowing that this is an endless cycle, as stakeholders and investors come and go over the years.
What we have control over is the ability to apply the holistic approach we take to solving any type of problem within an organization. Don’t just make decisions. Study how decisions get made. People who move into a systems leadership role need to shift their practice toward understanding: How are decisions made, contributed, governed, learned about? Our jobs are to make sure that process, that decision workflow is as seamless and easy to do and conducive to good outcomes as possible. That’s system lifecycle work.
Lastly, remember to ask: Where is the most impact you can make inside or even outside your organization with your skills in design systems? Your answer might be about helping people work better together. It might be about training people to be systems thinkers. Maybe it’s about bringing together the entire organization and the end-to-end user experience. The bounds of systems are only where you draw the line for yourself, on your team, and within your organization. Keep dreaming and let your imagination be your guide.
