Harvesting existing design system patterns

When starting a design system team for an existing product, its tempting to want to create foundations and best practices for your organisation. This often leads to an unsuccessful team and low adoption.

Instead, collect foundations and best practices to start your design system.

https://twitter.com/danmall/status/1493610161012891651

A step-by-step way to collect these foundations:

1. Collect what’s being practiced.
2. Within that, look for what’s common.
3. Within that, look for what’s good.

Identifying these factors are key in increasing the likelihood of adoption.

I personally refer to this process as 'harvesting'. Look to harvest components rather than create new foundations:

1. Multiple feature teams have similar components
2. Design system team creates an abstracted version of said component
3. Feature teams re-adopt the abstracted component
4. New teams use the abstracted component

It's important to wait until multiple variations of these components exist. You don't want to create the [[20221026123121-the-wrong-abstraction]]. [[20220704125636-design-system-requests-identify-needs]] mentions this, as different teams may create subtly different components that then need to be centralised [[20211115112656-rule-of-three]] [[20230731120128-design-system-deviation]]

[[20220704125509-design-systems-snowflakes]] also fall into a similar category. Once a snowflake becomes common, it makes sense to adopt it into your design system. Recipes as mentioned in [[20211122112956-design-system-component-hierarchy]] can become a great incubation layer to identify what's needed.

[[20220627114201-design-system-existing-product-strategies]]

[[adoption]] [[architecture]] [[components]] [[designsystem]] [[designsystemapi]] [[product]]