This great post by Mike Rivera discusses handling snowflake patterns in a design system in a way that keeps product teams productive yet also maintains the integrity of the system. He describes the possible outcomes for a snowflake:
Debate over whether or not a snowflake is made available for widespread use is appropriate. Debate over whether or not the snowflake should have an entry in the system isn’t. It should always be entered under one of three scenarios:
- The snowflake is deemed worthy of widespread use and gets incorporated into the system. The system team then communicates its availability to all interested parties (including its description, reference to the production use case, and anything else mandated by system guidelines).
- The snowflake is deemed an anti-pattern and is not allowed to be placed into widespread use. The component, its underlying use case, description, intentions, etc. is added by the system team along with the rationale for its rejection and recommended alternatives. Product designers must then redesign to come back into alignment with the system or start over.
- The snowflake is deemed worthy of use, but not widespread use (i.e. it remains a snowflake indefinitely). Again, use case, description, intentions, etc. should be included in the snowflake’s system entry.
Regardless of the option chosen, documenting the decision helps product designers know what is and isn’t in bounds and why.
What I love about this process is that it’s all very intentional. He rightly cites Inayaili de León Persson’s fantastic post, which details the process of getting a new pattern into Canonical’s Vanilla framework. A design system isn’t going to provide a perfect solution for every scenario (especially in its early days), so recognizing and anticipating that out of the gate is critical for the system’s ongoing success.
Discussing how to handle snowflake patterns and formalizing a contribution process (like Canonical’s gorgeous decision tree) are important things that can be tackled before the system even exists. This helps product teams get things out the door quickly while still working with the grain of the design system.