As organizations continue to take on more complex digital entities, often spanning multiple products, design systems are becoming more prevalent. Distinct from a pattern library or style guide, a well-crafted design system contains both patterns and guidelines for design practitioners and front-end code that powers multiple digital products. Conference presentations and articles abound with examples of ever more sophisticated systems, and practitioners across the field are anxious to start creating comprehensive systems for their products.
However, kicking off and rolling out a design system takes significant time and investment—one that many enterprises are reluctant to take on. What initially seems like the answer to achieving quality design at velocity quickly becomes a perceived bottleneck. Time and care need to be spent making sure the code is stable and the design elements can adapt to different use cases and design needs. Pieces of the system get rolled out slowly among the different products. How do you keep stakeholders from becoming disgruntled? How do you keep the team motivated to keep working against the increasing pressures of executives who can’t understand why things are taking so long?
In this article, I’ll discuss a practical framework for selling and continuing to market a design system within an organization. I’ll share ups and downs from the process, and how to make sure executives stay invested as the system is designed and built.
Design System as Organizational Change Effort
While many discussions of design systems focus on the what and how of creating one—organizing components, breaking a design down into pieces, etc.—most gloss over the fact that creating a design system is an organizational change effort at its core. A design system represents an entirely new way of working for most design and product groups. In particular, a few key issues pop up:
- Designers worry that the system is too limiting. Because a design system focuses on a consistent and evolving set of components, designers may worry that their creativity will be compromised.
- Developers worry that the system will be hard to implement. The promise of a design system is that a single front-end code repository—CSS, Javascript, even template files—feeds many different products. This means that an update to the system in one place ripples across every product using the system. Thus, a design system is a huge technical undertaking for many teams.
- Stakeholders worry that it will take too long. Creating a design system requires teams to slow down before they can speed up. Components must be identified and prioritized; front-end architecture needs to be put in place. Elements and components need extensive design time to make sure they scale across contexts and situations. As executive sponsors and other stakeholders start to realize the amount of resources required to do this, the promise of increased velocity starts to be questioned.
Failing to acknowledge and address these issues strategically can derail any design system effort. To make sure this doesn’t happen, it’s helpful for leaders of these efforts to think in terms of the organization-wide change they’re trying to create. For this, I turn to John Kotter’s 8-step process for creating organizational change, outlined first in Leading Change (1996), and updated in Accelerate (2014). I’ll put this in context below.
Figure 1. John Kotter’s 8-step framework for leading organizational change efforts. (Credit: Kotter International)
Create a sense of urgency around a big opportunity
The first and most important step of creating a design system is to help your team and executive stakeholders understand the opportunities a design system provides. For example:
- Designers can create consistency across several product lines
- Developers can move faster by using repeatable patterns instead of architecting the same dropdown menu multiple times across products
- Both designers and developers can focus on the big, interesting problems instead of worrying about which color the button should be
- Product managers, executives, and other stakeholders get to create things faster, improving go-to-market time while still allowing experimentation
All of these things make a design system an attractive prospect for teams, but the amount of time and money required can still be hard to swallow. To make your case, it’s not enough to focus on the benefits of a design system. It’s equally important to demonstrate the costs of not creating a system.
For example, a simple user interface inventory can easily show that, for example, your products include 87 different shades of blue, or 20 different button styles. Each of these creates visual inconsistency across product lines, but it also represents the actual work hours of designers and developers.
In the words of projekt202 Managing Architect Drew Loomer, “Just by eliminating code redundancy, more than 20% of a developer’s time can be regained.” Loomer continues, “For a team of 100 developers, this means around $2 million per year.” Putting this information in front of executives in a brief PowerPoint “pitch deck” that you present to them is an extremely powerful way to help them understand why a system is needed.
Figure 2. Using CSS Stats by Github, you can scrape your site’s code and determine how many different declarations and selectors are used.
Build a guiding coalition
Once you’ve created your initial pitch deck to sell your design system project, it’s time to do a roadshow. Present the idea in small group settings to project teams, content publishers, and any other group that will ultimately benefit from the system’s creation. Your goal is to start building a group of passionate advocates across organizational silos and job levels that will keep pushing the initiative forward.
Form a change vision and strategic initiatives
As you gain buy-in for the design system, have a clear vision and roadmap for the future of the system. What components will you start with? How will it roll out across product lines? Will the team do a “big bang,” which may take a year or more? Or does it make more sense to roll out changes incrementally as the system elements are being built? All of these questions should be answered as you start creating your system.
Enlist a volunteer army
Even if you’re able to sell your design system as a funded effort with resources attached, you’ll still need people to help you keep the train moving. Finding like-minded individuals across the company, whether they’re future beneficiaries of the system or designers in another part of the company, will be essential in helping make sure that the effort scales the way it needs to. Your goal is to start building a group of passionate advocates and collaborators across organizational silos that will keep pushing the initiative forward.
Enable action by removing barriers
You’ll notice a lot of excitement as you start planning out your design system. After all, cutting up web pages and organizing components is fun. But once you’ve been designing and building the system infrastructure for a few months and nothing is “visible” yet, you’ll start to see some resistance. Executives who bought into this effort will wonder when they’re going to see the actual benefits proposed and may start threatening to go back to the old way of doing things. Developers and designers trying to use early versions of the system may get frustrated, feeling like they could work faster if they just did things the way they were used to.
Figure 3. Keeping a component/architecture status board helps keep teams in the loop on progress.
As a leader, a key part of your role in the initiative is helping to calm nerves and keep the team focused on moving forward. Continue evolving and presenting your initial pitch deck to groups throughout the organization and give frequent updates to let people know how things are progressing. Keep in close contact with the people most likely to throw a wrench in your efforts to keep them at ease.
Generate and celebrate short-term wins
One of the best ways to calm nerves and maintain visibility for your design system initiative is to focus on making—and publicizing—a few key wins early in the process. Example wins include:
- Creating the roadmap for the system and a plan for v1. Keep this in an easy to find place and update it as the system evolves.
- Getting key architecture in place. In the early days, most of what you create will be visual elements and front-end architecture. Focus on publicizing these releases in human-friendly language for different audiences. For example, instead of publishing a list of all the code that’s been published, consider sending something like, “v0.1 has been released, which includes architecture for the page grid, global colors and typography, and SCSS helpers. On the design side, we’ve focused on global typography styles, our digital color palette, and accessibility rules.”
- Creating your first layout using the new system. A key way to help stakeholders see the value of the new system immediately is to show how quickly new layouts can be created using system elements, while still allowing for visual variety. When an executive sees that a layout was created in a couple of hours, while a comparable layout using the “old way” was done in two weeks, their eyes start to open to the possibilities.
Sustain acceleration
Throughout the process of creating and publishing your design system, never stop sharing the milestones you have achieved. Continue evolving your pitch deck and providing demos of the system to people in the organization. Enlist the help of other teams in contributing ideas to the system. Send regular status/release notes to demonstrate the activity happening on the system. Seeing regular progress helps your stakeholders want to continue investing in the initiative’s success.
Institute change
Throughout this entire process, you’re building out your design system and developing plans to roll it out across your products. As the benefits of the system become clearer, documenting the system’s use and helping teams across the business adopt the system are essential to its success. Focus some time here on helping product teams get up to speed with the system so they can effectively roll it out to their products. This is also a good time to focus on creating an externally facing documentation site that can be shared with developers and designers working with your products.
Conclusion
As digital ecosystems mature, a design system is rapidly moving from an innovation to a requirement for companies looking to execute quality design at scale. But framing the effort as a simple design and front-end development exercise minimizes the impact of the system on every aspect of the product design cycle. By recognizing and treating your design system effort as organizational change, enterprises are better equipped to set themselves up for success.
Retrieved from https://oldmagazine.uxpa.org/the-politics-of-design-systems/
Comments are closed.
