Context is (like Principles and Patterns) one of the invisible building blocks that hold a design system together and make it valuable. These invisible LEGO bricks are often ignored. If they are not considered they cannot be controlled and just “something” will be created.
What I’ve experienced over and over again is a mindset where teams across domains, brands, or businesses tend to think their products are unique. The truth is they’re far more alike than different.
— Hayley Hughes, Shopify / Source (Blog)
Also if products look different, they can have the same context in common. The context should be part of the “reason for existence” of a component. It’s really important to Document everything / the context of a component:
Once a set of components becomes standardized in the system, teams tend to unconsciously assume the decisions behind them are valid and continue to use them, rather than question if they still meet the need.
— Hayley Hughes, Shopify / Source (Blog)
If context is systematized like a product, it will add further value to your design system. These are topics you can consider while describing the context:
— Hayley Hughes, Shopify / Source (Blog)
A good example how to define and describe context is this page of the Shopify design system. This text does not remain abstract and provides concrete instructions to the designers:
Retail experiences - Shopify Polaris
Shopify writes the documentation with focus on what action they are driving: “Callout cards are used to encourage merchants to take an action related to a new feature or opportunity.”
— Yesenia Perez-Cruz, Shopify / Source (YouTube)
When every user of the design system sits behind his computer, one can sometimes forget the importance and impact of the decisions one makes. In Facebook’s little red book there is an interesting graphic that illustrates how important every developer is.
— Ben Barry / Source (personal website)