Given the amorphous nature of the term “Design System”, it’s no surprise that it means different things to different people. Even among design practitioners.

The terminology is used across varying contexts in broad and sweeping ways — think UX, visual design, branding, and development — and often lacks definition, structure, and even boundaries.

For your typical marketing, brand, and creative folks, a design system means documenting things like logo usage, wordmarks, and hexadecimal codes so internal and external partners can represent the brand properly. Basically a static artifact that tells you to do ✅ it like this; and definitely don’t ❌ do it like this.

The artifacts also largely render best-case scenarios that assume complete control over context and corresponding surface areas — like a billboard ad on Sunset Boulevard for a new show from one of the streaming providers.

A good example of this type of artifact is the Big Green Guide from Hulu.

Although toolkits like this certainly have their place and are useful, they do not amount to a design system.

They essentially contain the ingredients to be used in a recipe that ultimately becomes a design system.

This so-called design system recipe 👩‍🍳 if you will, includes those ingredients, plus the actual assets housed in a design tool (e.g., Figma), a set of rules/annotations explaining how, when, and where to use them, as well as the code to actually build stuff.

Design decisions — like brand considerations — are baked-in 🥖 through the use of tokens, which standardize things like color, typography, styles, spacing, etc.

The benefits are pretty clear: a design system helps ensure consistency and scalability across different platforms. This helps to ensure both experience quality, usability, as well as brand continuity. (Studies show that visual polish and consistency increase user trust).

A design system done well also improves team efficiency and time to market. It speeds-up delivery in that teams can plug-and-play with existing components. They don’t have to reinvent the wheel every time they want to build a feature and it also saves on QA time.

Uber’s Base design system represents a good example.

However, if as a UX Designer, you find yourself articulating this level of detail and nuance when initially pitching your cross-functional partners on why they need a design system, their eyes may have already glazed over. It’s probably too much detail. Too soon.

To keep our food metaphors going (last one, I promise)… they don’t necessarily care how the sausage 🌭 is made.

Let’s put ourselves in the shoes of our different stakeholders:

• The marketing, brand, and creative group mentioned earlier have most likely already dipped-out. They probably saw their contributions as being done at the afore-mentioned artifact delivery phase (i.e., “Just follow the brand guidelines.”) The issue here is that this view is short-sighted. It doesn’t comprehend what a design system is. It also fails to fully understand the nature of interactive, digital products that continue to evolve, change, and even adapt to user context.

• Product Managers and the business side just want to ship their features and perhaps care less about broader product cohesion. (They may even think of it as IT or infrastructure work; and not a means to enable the business, which is a sad state of affairs). They typically see resources spent on creating a design system as overly time consuming, (i.e., “Let’s just ship this feature on time.”) The shortcoming here is that modern day software development generally includes multiple teams — from a few in a startup, to possibly hundreds in a large enterprise — contributing to a single product experience. Any work towards this benefits the product longer-term, even though it does require some short-term investment.

• And our Engineering friends tend to want to to keep their velocity up. Working on the design system during a sprint(s) can drag down velocity. Repurposing existing components and/or tweaking them slightly tends to be the path of least resistance (i.e., “I’m just going to use what we’ve got, but make this change.”) That said, they generally do grok the benefits.

Perhaps these representations are a bit stereotypical and maybe even at tad cynical, but you get the general idea around. There are motivational forces at play.

So, if you are a designer looking to pitch the idea for a design system at your company, here are some recommendations after having stood up a couple myself:

• Establish a shared understanding of what a Design System will really mean for your product and workflow. Define it. Answer how it will work for your teams; ideally by showing examples. Or even flows! As mentioned earlier, the term is pretty darn nebulous.

  • Note: Please be wary of showing super-mature design systems (e.g., Google’s Material Design, Spotify’s Encore, Netflix’s Hawkins, etc.). Those have been years in the making. The companies also have fairly sizable teams devoted to what have now become large, internal products. Showing them can feel like you’re trying boil the ocean — especially when making an early business case.

• Start small and prove out the ROI. You don’t need a dedicated team to get started. Design Managers and leaders can assign goals, stretch objectives, etc. to prove out the concept. Senior-level ICs can both nominate areas that are the best candidates for standardizing components and take on some of the work. Once cross-functional partners and engineers on product teams see the value, broader investment is that much easier to justify. 

• Leverage platform conventions as much as possible. From iOS to Android, and tablets to web, there are tried, true, and tested designs already out there. You should have a pretty good reason to break established conventions.

• Consider high-traffic product areas first. What are the key flows and most used surface areas of the core product? What has the most friction? What can wait? Answering these questions generally gives you the most bang for the buck. (As an added benefit, it quickly proves out core component usability at scale, as well!)

• Try to align the initial systems work to features coming up on roadmaps. If there is overlap, chances are the convergence will increase adoption. There’s nothing worse than well-designed components sitting on a digital shelf collecting dust.

• And finally… on the topic of governance and deciding what officially makes its way into the system, I’d suggest keeping the decision-making framework within the Design function early on. It’s essentially the UX team’s responsibility to understand interaction context, what components exist, or what would need to be created to solve a new problem elegantly. Keep that under the design team’s purview for as long as possible.

Well, there you have it. Hopefully this gives your attempts at pitching and establishing an effective design system the fighting chance it deserves.

Thanks for reading.

Marc