I see pattern-y things everywhere
I see pattern-y things everywhere
I see pattern-y things everywhere
Sep 27, 2024
Equitable design patterns
As our team refactors our design system, we end up scratching our heads sometimes trying to classify a component, a pattern, or something else entirely.
We decided to shrink our core component library as small as possible and keep what’s in it unopinionated.
The word “patterns” is vague at best and designers and engineers have different mental models for these things.
Documenting “patterns” is not the same as a component, and instead focuses on layout rules, user flows, and/or behavior guidelines depending on what it is.
Resources
Thanks as always to the brilliant design systems community out there for all the writing and research on the topic:
Patterns in Design Systems by Dave House outlines how you can begin to define the differences between the different types of patterns including UI patterns which focus on layout, behavioral patterns which focus on process and service patterns which focus on larger user journeys.
How to Define and Document Patterns in Your Design System by Michelle Chin dives deeper into the unique documentation needs of patterns including where pattern docs should live, elements to document, shared authorship responsibilities, and how to select which patterns you choose to document at all.
The Art of Design System Recipes by Brad Frost takes it up a level and gets into those “other things” that aren’t quite patterns and where and how those “other things” relate to your core design system. Supporting a Recipe layer prevents the core from becoming too bloated but also provides these elements with a home and the team with more opportunities to collaborate.
Takeaways
All of these resources have helped the team at Exygy start to put a couple of things together:
Create parity between design and engineering by auditing and naming patterns
Make space within our respective design and code architectures for how tokens, components, patterns, and features all layer together
Begin documenting our patterns consistently and uniquely from components, leveraging layout rules, references to nested components, and multi-page flows.
As our team refactors our design system, we end up scratching our heads sometimes trying to classify a component, a pattern, or something else entirely.
We decided to shrink our core component library as small as possible and keep what’s in it unopinionated.
The word “patterns” is vague at best and designers and engineers have different mental models for these things.
Documenting “patterns” is not the same as a component, and instead focuses on layout rules, user flows, and/or behavior guidelines depending on what it is.
Resources
Thanks as always to the brilliant design systems community out there for all the writing and research on the topic:
Patterns in Design Systems by Dave House outlines how you can begin to define the differences between the different types of patterns including UI patterns which focus on layout, behavioral patterns which focus on process and service patterns which focus on larger user journeys.
How to Define and Document Patterns in Your Design System by Michelle Chin dives deeper into the unique documentation needs of patterns including where pattern docs should live, elements to document, shared authorship responsibilities, and how to select which patterns you choose to document at all.
The Art of Design System Recipes by Brad Frost takes it up a level and gets into those “other things” that aren’t quite patterns and where and how those “other things” relate to your core design system. Supporting a Recipe layer prevents the core from becoming too bloated but also provides these elements with a home and the team with more opportunities to collaborate.
Takeaways
All of these resources have helped the team at Exygy start to put a couple of things together:
Create parity between design and engineering by auditing and naming patterns
Make space within our respective design and code architectures for how tokens, components, patterns, and features all layer together
Begin documenting our patterns consistently and uniquely from components, leveraging layout rules, references to nested components, and multi-page flows.
As our team refactors our design system, we end up scratching our heads sometimes trying to classify a component, a pattern, or something else entirely.
We decided to shrink our core component library as small as possible and keep what’s in it unopinionated.
The word “patterns” is vague at best and designers and engineers have different mental models for these things.
Documenting “patterns” is not the same as a component, and instead focuses on layout rules, user flows, and/or behavior guidelines depending on what it is.
Resources
Thanks as always to the brilliant design systems community out there for all the writing and research on the topic:
Patterns in Design Systems by Dave House outlines how you can begin to define the differences between the different types of patterns including UI patterns which focus on layout, behavioral patterns which focus on process and service patterns which focus on larger user journeys.
How to Define and Document Patterns in Your Design System by Michelle Chin dives deeper into the unique documentation needs of patterns including where pattern docs should live, elements to document, shared authorship responsibilities, and how to select which patterns you choose to document at all.
The Art of Design System Recipes by Brad Frost takes it up a level and gets into those “other things” that aren’t quite patterns and where and how those “other things” relate to your core design system. Supporting a Recipe layer prevents the core from becoming too bloated but also provides these elements with a home and the team with more opportunities to collaborate.
Takeaways
All of these resources have helped the team at Exygy start to put a couple of things together:
Create parity between design and engineering by auditing and naming patterns
Make space within our respective design and code architectures for how tokens, components, patterns, and features all layer together
Begin documenting our patterns consistently and uniquely from components, leveraging layout rules, references to nested components, and multi-page flows.