When to contribute new patterns

There will likely be times where the system and its components fall short of your preferred solution. You have a decision to make — should you stay consistent with what exists, or go with the best possible solution, regardless of consistency?

To help you figure this out, start by plotting out where each solution fits in this “perfect vs consistent” framework. Rate the solutions according to:

• Consistency with the rest of the product (x axis)
• How appropriate the solution is for your specific situation (y axis)

To practice this framework, let’s imagine some possible scenarios. Consider the more obvious directions:

When deciding between A or B, go with A. It’s the better solution to the problem, assuming all options are inconsistent. A or C? Obviously C. Of two equal solutions, choose the one that is more consistent with the rest of the experience. A or D? D is consistent, but A is a much better solution to the problem. In that situation, it is likely that you can contribute the new pattern to the system, so others can leverage it in the future.

Now let’s look at the less obvious directions:

Go with A if it’s the perfect solution and has the potential to scale to the rest of the system

Deciding between A or E is trickier. If A is clearly better than E, but E is much more consistent, go with A. This is because A has potential to become a system pattern and eventually get closer to E, and maybe even surpass it, in terms of consistency.

Go with E when consistency trumps perfection

Go with E if A seems like a snowflake solution. Building a snowflake solution will make it difficult for other teams to adopt it. Breaking consistency is also costly because new, custom solutions add complexity to the experience and are hard to learn, so its benefits should significantly outweigh the cost of inconsistency.

When both are appropriate and there’s not a massive difference in value, consistency trumps perfection.

The key here is to zoom out. When we’re designing for scale, we need to think broader and look at our specific problem area as a small part of a larger system. So spend some time figuring out if your solution is unique, or if it has potential to solve other problems. This is why it’s important to have good awareness of the whole experience before you start, and why it’s important to contribute back to the system if you land on a solution that would benefit others.

For initial questions about contribution, reach out in #polaris if you work at Shopify, or the Shopify Partners Slack if you’re an open source contributor. To get help with the strategy for a larger contribution, start a GitHub discussion with the system community.