Published in


Design System Contribution Criteria

How to Decide What Belongs & Convey Work That Remains

Can I add my awesome Card design to the library?

Should we publish my Chart colors in system doc?

Shall I merge my Layout Grid CSS into the system repo?

Designers and engineers always confront challenges the system doesn’t solve. And then, they’ll solve it. Through blood, sweat and tears, they’ll develop fervent belief about the solution’s value. The system is their path to amplify that value. But is the system the right place for it?

Does It Belong in the System?

Systems are never the repository for every style, component, and feature designed and built for every product ever. Instead, a system should include what’s shared across many products and omit what’s not.

#1. Is it relevant to any other product? If so, how many?

For example, a toast error message could be relevant to an entire app ecosystem. On the other hand, a souped-up data grid with toolbars unique to their product may be irrelevant to everyone else. I’ll use a scale:

  • Useful only to your product? Not good enough.
  • Useful to another product? Let’s at least chat about how useful.
  • Useful to 3 products? Got it, let’s at least discuss this with the community.
  • Useful to 5 products? It probably belongs.

#2. Is it consistent with the system’s vision?

If your system already sports page-, inline-, and toast messages, a “top hat” for system outages and other announcements could fit nicely into the set of messaging components.

#3. How much will it cost to make and maintain?

Got a primitive pill that needs a few varied colors? Easy. Proposing a complex, multi-panel calendar date picker? Let’s take a breath.

Basic pill vs Very Complicated Date Picker (Source: readthedocs.io)

#4. Does it trigger momentum in a new direction?

A system team can’t take a burgeoning library in every direction at once. If your team is focused on areas like error messaging and notifications, a Tooltip contribution could trigger growth elsewhere.

#5. How deeply can YOU guide its use?

Adam Rowe, a recent system collaborator, came up with this productive and reasonable challenge question:

#6. Is the timing right for contributor AND system?

Ultimately, a contribution conversation must zero in on timing. Does your system team’s release cycle and roadmap have space for this now or later? Does this feature pair well with other current developments?

What’s Left to Be Done?

In my 10+ years of system work, I’ve never seen a contribution complete enough to be immediately merged into the system. Instead, there’s work to fine tune the contribution to:

  1. Expand to a minimally sufficient feature set,
  2. Reduce scope to omit contentious features, and
  3. Always, always normalize to how system features are designed and built.

#1. Expand to Cover a Minimally Relevant Feature Set

You can’t add half-baked features to a library. Premature and simplistic solutions risk inconsistent interpretations per product that you meant to eradicate. Even worse, adding features later risks triggers breaking changes that can alienate adopters.

#2. Reduce Scope to Broaden Relevance

The contribution may also need to reduce scope to a relevant essence useful across products. Consider an already arduous collaboration across three flagship products to unify a Card component design.

Three alternative Card designs
Card design added to the system

#3. Normalize! Align with System Composition and Quality

Perhaps a design include myriad non-system colors, wacky spatial choices, and product-specific icons. Or, maybe contributed HTML markup is crude, CSS is unorganized across files, and — gasp! — uses Stylus instead of the system’s Sass. Without a doubt, contributions always lack every text / background combo, size option and theming construct the system offers.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nathan Curtis

Founded UX firm @eightshapes, contributing to the design systems field through consulting and workshops. VT & @uchicago grad.