Design System Contribution

Design System Contribution Process

A good design system is like a compass, keeping everyone aligned without stifling creativity. Design system helps product teams achieve a very important goal—consistency in design.

Every time a designer want to introduce a change to an established design system, one need to carefully evaluate this change to ensure that won’t break anything or introduce unnecessary changes.

Ideally, the contribution process should be visualized as a decision-making flowchart, which will help your team determine how to handle the need for a new UI component or style.

Here are 3 essential steps of a contribution process:

Start with the need

Design is all about solving problems, and when you want to introduce a new change, you need to clearly understand what problem you’re solving and why. That’s why you need to encourage problem framing, not just solution requests. This avoids unnecessary or overly specific styles/components (such as styles/components used only in one very specific case).

Check the existing system

Don’t reinvent the wheel! When evaluating design decisions, always start with what’s already available in the design system. Reuse before reinventing. This will help you save dev time and improve design consistency. Check design intent, documentation, and usage examples of existing styles and components to figure out what you can reuse. For example, when you want to introduce a new component, but after exploration of your design system you find a component that serves a similar purpose, maybe it’s worth extending this component rather than creating a new one.

Propose an improvement

Design change proposition is a very tricky thing. You need to clearly articulate not only what you want to change and why, but you also need to evaluate the effort required to implement this new style/component. Shopify Polaris design system offers a very important suggestion—when introducing new functionality, do it as opt-in props or slots—avoid breaking existing behavior. And do not provide a style/component just as a design asset. Offer clear documentation covering areas: rationale, before/after use cases, and accessibility considerations.