What I learned about leading a design system in 2018.

Navigating organizational change on the way to design system legitimacy.

I wrote this article to reflect, internalize, and record what I have experienced professionally in 2018. I wanted to take the time to document what I have learned about leading a design system and design systems in general over the past year so that I can be intentional about my efforts to improve in 2019. I publish this in the hope that others may find something useful from my experiences.

“Be stubborn with your vision, but flexible with the details.”

This quote from Amazon CEO Jeff Bezos was a favorite for one senior leader during an executive off-site I attended in November. It summarizes quite succinctly my experiences creating a new design system within a large organization.

You should expect to make adaptations and concessions to the form of the design system as you are navigating the political climate of your organization. A vision of what you are trying to create, anchored by the business problems you are trying to resolve, is paramount to understanding what points you can or cannot safely concede along the way, or other avenues you can take to achieve the same results.

Don’t let getting everything you want, stop you from getting anything you want.

I encountered several hurdles this year, and having a fairly clear vision of what I was trying to create and why I was creating it that way, helped me tremendously to navigate through them.

Organizational chaos

As a newly emerging group, the design system team was very susceptible to reporting structure changes and shifting short term business objectives. Without a clear vision, these events could have completely derailed the design system project by introducing nonstop change, impeding the team’s ability to achieve anything meaningful. Because I had a clear vision, I was able to deflect external noise and provide my team more stability through this turmoil.

Addressing legacy solutions

The entrenchment of legacy design, code, or business processes will have an outsized impact on the design system, mainly due to the amount of attention and effort that needs to be spent to dislodge them. Each situation I encountered was unique, but I found I had three basic choices in how I could deal with the situation: ignore, bypass, or erode. A clear vision will helped me choose which path to take.

Ignore: If you don’t need to deal with it now, don’t. Your time can be better spent elsewhere.

Bypass: Work around the legacy solution without having to disrupt it.

Erode: Slowly chip away at the solution until you can ultimately replace it.

Prioritization

Overall the best thing a clear vision provided me this year was a way to quickly estimate the potential cost/benefit for every decision, argument, or discussion I had about the design system. You don’t have infinite time or patience to fight every battle, so the vision helps you choose which is worth your time.

Through all these issues, one lesson emerged that I will never forget: Don’t let getting everything you want, stop you from getting anything you want. You’ll never achieve the perfect design system, so focus on creating the best system you can with the reality you face.

Focus on making an impact, quickly.

Finding quick wins and using those wins to build momentum is a wise strategy, so choose the path of least resistance. If you are a designer, focus on creating design system artifacts or processes that will help the design team address existing pain points. If you are an engineer, make code artifacts that will provide value to the technologists within your organization. However, if you are capable of doing both, be very careful of taking on too much and diluting or delaying your ability to make an impact.

I have a bad habit of taking on too much at once. I saw better success when I took on less, focused on quality and completeness, and invested the time to properly promote and support the end result.

If your company is like most, opportunities for improvement are abundant. Use a prioritization matrix and choose the opportunities that have the highest value and lowest effort first. Use the successes and accolades from your early victories to gain support and resources to tackle the harder problems later.

Don’t optimize too early.

If you don’t think of your design system as a product, it’s time to start. When you are early in the product life cycle, all of your investment needs to be going into building your core offering and trying to acquire customers.

A mistake I made early this year was trying to build the tools to help maintain the mature design system I had in my mind, before actually building much of the system itself. I lost weeks of time solving problems we didn’t have instead of focusing on creating value for our customers and gaining adoption.

… don’t spend valuable time building solutions to problems you don’t have.

Don’t be blind or ignorant to problems you may face. Be vigilant, and have plans to resolve problems if they arise, but don’t spend valuable time building solutions to problems you don’t have. They may never come, or they may have a root cause that you don’t fully understand. Focus on momentum; even if it is at the expense of efficiency. You can drive out cost for maintaining the design system once it matures.

Partner with a friendly product team.

Many items found in a typical design system seem obvious: buttons, input fields, a color palette, typography. As a system designer it is easy to think in discrete pieces of UI and focus on their composition in isolation. However, it is important that you don’t lose sight of the purpose of the system — to combine these discrete pieces of UI into full compositions that create rich product experiences. Without a product partner who can provide real design needs and context, you’ll spend a lot of time creating theoretical situations for how your components will be used and what capabilities they will need.

You can only spend so much time discussing the philosophical essence of a button before you go insane.

From experience, I know context is important to understand how to correctly use components from a design system, but it is equally important when crafting them as well. Working directly with a product team provides several benefits that will accelerate and simplify the buildout of the design system.

1. It will be easier to prioritize what components and patterns the system needs to provide.
2. It will allow you to see and test the components and patterns in use to ensure they work together within the context of a full product.
3. You’ll have a first customer for the design system, and a case study you can use to obtain more.

My team and I spent a lot of time this year debating button heights, how many variants we should offer, and which side of the label the icons should be allowed. You can only spend so much time discussing the philosophical essence of a button before you go insane. There is no substitute for understanding what your company’s products actually need, and then building that. Once we had our first product partnership, everything became much clearer and easier.

Build a narrative around the design system as it relates to strategic goals set by senior leaders.

For as simple of a concept a design system may seem to you, it is loaded with a lot of historical baggage that can complicate or derail your efforts to create a system within your organization.

“How is this different than a component library?”
— Engineering

“Why do we need this? We already have brand guidelines!”
— Product

“There is a Sketch file with buttons and checkboxes that we pass around.”
— Design

While you absolutely need to have answers and arguments to counter these type of statements, they are not a substitute for a compelling business case. A strategy I used to help control the narrative for the design system and anchor conversations from straying too far off topic was to position the design system as an important supporting piece to the strategic goals set by the senior leadership team.

What is your CEO concerned about over the next year or two? Growing the product? Scaling the organization? Improving the consistency of the experience across touchpoints? The nice part about the breadth of domains design systems cover, is that there is a compelling story to tell for each one of those business needs. Find the one topic the executives care about most, and build a simple, yet compelling narrative about how a design system supports that goal. Then stay on message.

Official funding and organizational legitimacy comes once a business leader makes the connection that the design system is a strategic tool for the organization to achieve its goals.

Understand that it will take time for the story of the design system to filter through the company hierarchy. It needs to reach the right people, and they’ll likely need to hear it multiple times until it resonates. You never know what path your narrative will take to get to leadership, so staying on message will help ensure the right message is communicated, because it is the only message being communicated.

Creating multiple narratives that address the tactical concerns of product, engineering, or design, dilutes the message and the enterprise-spanning value that a design system is capable of achieving.

Official funding and organizational legitimacy comes once a business leader makes the connection that the design system is a strategic tool for the organization to achieve its goals. Absent of this understanding, a design system is just one of many good ideas floating around within a company.