The problem
Design systems (e.g. style guides, pattern libraries, etc.) are all the rage. They speed product design through consistency of patterns, components and behaviors which, in turn, drives out random, one-off elements (let’s call them ‘snowflakes’). It’s a noble goal, except that design systems also slow down product teams. The drive for consistency and the efficiencies that stem from it can crowd out the flexibility needed to craft the right element for the right situation at the right time. How do we embrace this conundrum? By not making it a conundrum. We can embrace snowflakes as a positive aspect within design organizations — without conflict of ideals, professional shame or complete dilution of a design system’s benefits.
As a product designer, I design the best solution I can for my customers. To the extent that a design system propels me toward that goal, it serves me and the business well. But when it doesn’t, when I’m too constricted, I don’t stop designing or cut corners. I move ahead by keeping critical elements that aren’t available in the system…I use and spec snowflakes.
Snowflakes will enter design systems if they’re deemed worthy, but at a cost: they don’t instantaneously appear in the design system. Delays are caused by debate, setting standards, coding, testing, etc. Additionally, another delay exists between the time a new component is made available in the system and its uptake by product teams (I’ll only address the first in this article). Both delays, nonetheless, increase iteration cycle times for product designers. Delays are significant, especially if you’re on a regular release cadence like I am in the enterprise space. They may cause you to miss your release date or to hit it with inferior UI.
Inayaili de León Persson wrote about Vanilla’s intake process, shown below. As an open source project, Vanilla solicits issues and proposals from the public. According to the article, contributions are reviewed every couple of weeks. Delays are built into their process. If delays exist, product is inevitably hampered.
The solution
Product designers should use snowflakes until the design system’s intake process delays are sorted out. The process illustrated above should be a parallel track of work, independent of a product team’s schedule. The two tracks of work will eventually sync, but the process need not create delays for product teams during the interim. The considerations below give structure to that process and explain the resulting outcomes.
Considerations and tips
Product designers need to know the design system well
Product designers are responsible for knowing what’s available in the design system. If an existing component meets the needs of the proposed design, then no additional work is necessary and it can be put to use right away. The idea is not to encourage the proliferation of snowflakes. Rather, it’s to keep product teams nimble. Judgement and temperance, as always, are needed. Pull from the design system first and always.
When a snowflake materializes, be clear about its intent
If no system component suffices, then a conversation with system designers is in order. Product design should outline what the new component is, the use case(s) in which it arises, and why similar, existing components won’t work. In simpler terms, product designers should advocate for their customers against the design system’s pressure to be consistent. After this exchange, product design should move forward with the snowflake while the larger debate about its merits takes place with the appropriate parties.
Snowflakes should be included in the design system, regardless of outcome
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.
Benefits
The clear benefits for me as a product designer are two fold.
Speed!
We all know the pace of product design is fast and, seemingly, getting faster. When product teams are able to speed ahead of the design system, they can push the envelope of what’s possible making them more responsive to the marketplace and the people who use their designs.
Learn!
Snowflakes allow product teams to learn what works, what doesn’t and why. The knowledge gained can be fed into the system itself through more informed debates and decisions about future changes. Similarly, product teams are able to improve their product through testing or, if a snowflake happens to make it to production before system designers get to it, through actual usage analytics.
I see delays to rapid design innovation as a major design system workflow problem. Embracing snowflakes — not as a last resort, but as a primary feature — within design systems is one solution. What’s your stance?