The power of relationships in design systems
Consistency isn’t just about components
👋 Get weekly insights, tools, and templates to help you build and scale design systems. More: The Design System Guide / Podcast / My Linkedin
TL;DR: Components alone don’t define a design system—relationships do. Understanding these relationships helps teams identify design inconsistencies, improve usability, and scale systems effectively.
What if your design system had all the right components but still felt inconsistent? It’s not just about components—it’s about the relationships between them.
Why Relationships Matter
Think about it. If you swap out one button component for another, your system still functions. But if you change how buttons, forms, and navigation elements interact, you've fundamentally altered the experience.
Take a card component, for example.
Should it always have a title and image?
Can it contain multiple buttons?
What happens if a button is missing?
How does it behave in different contexts?
Relationships Create Meaning
Components gain their meaning through context:
A button’s meaning changes in a form versus a modal.
A form’s behavior is influenced by whether it’s standalone or inside a modal.
A modal’s purpose is shaped by the components it contains.
These relationships form the foundation of the user experience:
Individual components combine to create the User Interface.
The relationships between components create the overall User Experience.
The system’s meaning emerges from these interconnections.
Documenting Patterns = Defining Relationships
❌ Teams often document components without thinking about their dependencies. This leads to inconsistencies.
✅ Instead of documenting components in isolation, we must define their relationships. Here’s how.
Document:
Behavior Flow: How does the system handle errors? Should a modal always trigger a backdrop overlay to guide focus?
Component Roles: Which components are required for a pattern to function?
Interaction Flow: What behaviors occur when a user interacts with the pattern?
Accessibility Considerations: How do relationships impact focus order, screen readers, or keyboard navigation?
Spacing & Alignment: Should a card always include a heading? How far should text inputs be spaced from buttons?
Without this documentation, teams implement conflicting versions of the same UI pattern, leading to design drift, technical debt, and inconsistent experiences.
A pattern consists of three key elements:
Components – The building blocks
Connections – The interactions between components
Function – The purpose that emerges from these relationships
Example: The Sign-Up Form
A form consists of input fields (Name, Email), a CTA button, and a container. If you remove the CTA button, the form loses its function—it’s no longer a sign-up form but a list of disconnected inputs.
This highlights a key principle: Meaning and function emerge from relationships, not components alone. And not just that - they affect usability and even conversion rates.
For example:
A cluttered landing page with unstructured text and images vs. a page with a clear information hierarchy.
A poorly structured checkout form with too much info frustrates users and lowers conversions, etc.
Patterns aren’t static—they evolve. Teams should continuously test and document how components relate to each other. This iterative approach ensures that the design system supports designers and users over time.
Design System Patterns Documentation Template
This example shows a documentation page, but you can also document patterns in Figma (if that’s where your guidelines live).
1. Pattern Info
Name, Category
Current version/status (also part of your Status page)
Do's and Don'ts with examples
Figma component links
Design tokens used (can link to Airtable Inventory page)
Diagram (interactive or Mermaid)
Changelog
2. Purpose and Use Cases
Screens made available to use in Figma
When to use this pattern vs. alternatives
Problem this pattern solves
Target user needs & real product examples (screenshots, videos, links)
3. Anatomy and Behavior
Component structure & hierarchy
States & variations
Accessibility
Layout specs
4. Technical Implementation
Component API & props
Code examples & dependencies
Event handlers & performance considerations
Link to Storybook documentation
5. Related Components (Optional, but beneficial)
Alternative patterns for similar use cases
Complementary components
6. Metrics (Optional, but beneficial)
Impact on conversion rates
Usage analytics
Usability testing results
With metrics in place, you are closer to the Product and Business.
Example for metrics →
Why This Approach Works
By documenting patterns, we:
✅ Enable faster iterations
✅ Reduce inconsistencies
✅ Improve efficiency
✅ Establish a shared vocabulary
✅ Enhance scalability & maintainability
✅ Boost usability & conversion rates
Great design systems don’t just organize components—they define experiences. ✌️
💎 Community Gems
CSS Custom Functions are coming … and they are going to be a game changer!
🔗 Link
Atlassian released icons publicly
🔗 Link
Track your design progress (in Figma)
Marvin Messenzehl
🔗 Link
Into Design Systems Fck Up Stories
🔗 Link
❤️ People to follow
This week, I would like to introduce you to Guy Segal, Director, Design + Design System at Thomson Reuters.
A design leader with over 25 years of experience in the tech industry, specializing in UX, product design, and DesignOps. Leveraging his passion for design leadership and people management, Guy has a proven track record of fostering innovation and collaboration within design teams, establishing and nurturing design practices, and leading teams to success.In recent years, Guy has focused extensively on design systems, establishing and growing teams around the practice, and launching systems that optimize efficiency and enhance user experiences.