Reject All Dogmas

Design systems are so hot right now. Nearly every company has one, and they can be incredibly useful. But as is often the case, a sudden rise in popularity breeds an equivelent rise in abuse.

There are many who believe that a design system should necessarily be the arbiter of all UI elements; the governor of hard rules; the punisher of interface crimes. Not unlike a dictator.

In this thinking, the design system reigns supreme, and any violations are met with swift and severe punishment. Though somewhat hyperbolically, this describes a dogmatic philosophy having a detrimental impact on would-be system adopters, leading them to feel frustrated and restricted and ultimately to reject their systems; and rightly so.

Guidance Over Gospel Top

A design system is not a product. It functions as infrastructure, providing a catalog of resources for the design and development of a product. As such, a system necessarily serves the needs of the people. The people should not have to serve the needs of the system in return.

Design systems should avoid prescribing hard rules. That we call them "guidelines" instead of "rules" is intentional. Systems are fluid, and commandments usually can't withstand the tests of time. Instead, a design system can and should provide guidelines that articulate the opinionated design philosophies of the product designers who consume from it. Also fluid.

There are plenty of stories of designers who feel unnecessarily constrained by rigid or overly prescriptive systems—forced to forgo innovation in the name of consistency. Consistency is great, but if your design team feels like they need to reduce the quality of their product solutions just to adhere to the system, then your system has failed them and the users of your product.

Consistency is not the most important thing for the design of your product.

How well your product solves for the needs of its users is the most important thing for the design of your product.

The same holds true for the design of your system.

The Museum Of Your Product Top

I think of a design system like a museum. A carefully curated repository of artifacts—UI elements, standards, and guidelines—that describe the recurring needs of a product. The stewards of a system don't make the artifacts from scratch, much like the curators of an art museum don't, themselves, paint the works on display. Museum curators may restore certain works, but mainly to provide a compelling way for patrons to consume them. This is, in my mind, a suitable analog for the role of a design system. The system as an extension of the work, but not the work itself.

So who, then, should design the artifacts that your system curates?

By and large, your product design team should. They are uniquely positioned to gather context around user needs and then execute on solutions against those needs. Designing components in a silo without that context is a recipe for disaster.

Granted, it's not always realistic for product designers to design every component. Allowing system designers to create components first and then test them can be helpful for overall product velocity, especially in the early days. The key ingredient is some type of validation. That said, a well functioning system ultimately moves faster when system designers focus on extending rather than creating.

System designers are great at making assets reusable. In the museum analogy, this is the restoration process, which requires elevated consideration for details like principles, properties, states, and documentation. System designers have the latitude to focus on extending and standardizing what product designers create, to make artifacts complete and reusable within a multi-tenant environment.

Those standardized assets can then feed back into the process of executing on product designs. This is a bit more analogous to a gift shop that sells art supplies within the museum, to be purchased and used by artists. The supplies themselves do not directly inform artists work, other than by providing usage constraints. Even then, artists commonly produce interesting results by using supplies in unintended ways.

"Going Rogue" Can Actually Be Good Top

We don't always know what we don't know, and sometimes the intended usage of a thing glaringly overlooks important considerations. Sometimes, the most effective way of uncovering those unknowns is by allowing for a certain degree of rogueness.

I'm not advocating for the wild west. But flexibility is core to a system's ability to serve its consumers. Certainly, systems can and often should provide sensible guard rails to keep product designers honest, but they should do so mainly against the product design team's own standards rather than attempting to create new ones.

A functional system is fluid; constantly learning and improving. For example, constraining product designers to only those components that currently exist in your system is a quick path toward preserving the status quo. Nothing ever changes, nothing ever improves. That's great if your product is already perfect. But if your product is perfect, then you don't need a design system to begin with, since there is no reason to iterate on a perfect product.

It's usually worth sacrificing a little bit of consistency in favor of flexibility. Flexibility reveals unknowns. Flexibility also leads to adoption, which leads to more consistency than if nobody adopted your system at all.

When To Constrain Top

It goes without saying that, if everything were completely flexible then we would be back where we started, essentially without a system at all. Flexibility is best introduced methodically. So, here are some areas where I think it makes sense to keep things a bit more rigid.

• Naming conventions
  Especially at the semantic level. Design tokens, for example, provide meaning and context around how and when to use them. Breaking that meaning introduces ambiguity which reduces their utility. Changing the names of existing tokens can also break the underlying code which, if done often, results in endless reversioning.
  
  
• Foundational processes
  Things like handoff, product inventories, and design QA can be done differently from team to team across an organization. At the system level, choosing a consistent direction actually enhances the flexibility of the system by enabling tenants to communicate and collaborate more effectively.

Eye On The Prize Top

I've spent a lot of words here talking about what your system should and shouldn't do. These are just words. Reject all dogmas. The system that works best for your team is the right system for your team—however that looks. If your system isn't already working well, then I hope these words might provide some small amount of inspiration.

At the end of the day, remember why you decided to build a system in the first place. Why does your product exist? Who is it helping? Staying focused on those higher level business goals will always help you determine the best path forward for your design system.