Design Systems
Design systems help design teams work more efficiently, create more cohesive designs, and contribute to team synergy. When built correctly, they help companies develop better products and ensure everyone feels connected to the product as a whole. Below is how I have created and developed systems at various companies.
Okay, first off - What the heck is a design system!?
A design system is a set of interconnected patterns and shared practices, coherently organized to achieve the goals of digital products. Together, they form the foundation of what we know as design systems.
Patterns
Patterns are reusable parts of the interface (components) that can be applied and repurposed to solve specific design problems or meet interface needs.
Functional patterns: These are the tangible building blocks (buttons, headers, forms) that represent behaviours we want to encourage or enable.
Perceptual patterns: These are descriptive styles that express and communicate the product’s personality visually (e.g., color, typography, voice).
Shared Practises
Shared practices define how we create, capture, share, and use those patterns. How do we communicate with developers? With the product team? These practices are just as important as the visual elements in the design system itself. Proper handoff procedures are critical to optimizing the design system.
Okay - that’s the foundation. How do I start organizing them
Throughout my career, I’ve been involved in creating and optimizing design systems from scratch, and it always begins the same way: by asking what the product’s ethos is. What is our tone of voice? What are we trying to communicate through our typography, color choices, and icons?
These details are core elements of the product that need to be defined and shared with the team. It’s essential that these decisions are made collaboratively, with input from various stakeholders. Sharing these insights early on helps align everyone and fosters a strong team dynamic.
“If you need to get a group of people to follow a creative direction consistently, reliably and coherently, patterns need to be articulated and shared”
Design Principles: Step 1
Design principles are shared guidelines that capture the essence of what good design means for the team, along with advice on how to achieve it. What is our ethos? What is the core objective of our product? Do we have a “manifesto”? Once you do these workshops with the team, you’ll end up with a list of ethos-directions and be one step closer to building your product.
At Rubikloud, we ran several team sessions to uncover our design ethos and ultimately decided to use “Analytics Made Easy” as our guiding principle.
Design Principles: Step 2 (Shared themes Exercise)
Once you define the product’s ethos, a good exercise is a shared themes workshop. Get team leads from various departments (in my case, I like involving development, product, data, and partnership leads – this unique mix of talent always uncovers unique results) and ask them to write down the following:
In your opinion, what is good design? What does it mean for our product?
How would you explain it to a new team member?
What are the most important parts of the product? (Include screenshots.)
Remember to use actionable phrasing. For example, “Make it clear” is vague, whereas “One priority: What do you want users to see and do first?” is an actionable principle.
Spotify uses TONE (Tone, Usable, Necessary, Emotive) – which I think is beautiful!
The designers on these teams should be able to identify these principles. If there are different answers among the team, you have gaps that need to be addressed.
Design Principles: Step 3
Now you’ll have a whiteboard (or MIRO/FIGMA board) full of interesting details and ideas! What do you do with them?
First, group related items. Then, group all the sticky notes with common themes or unity. Unity is key here – it means the team is naturally aligning on goals.
Next, look for functional patterns. Review the screenshots and look for common themes and component practices.
A Rubikloud card
What is the goal of this? What are the design patterns?
Design patterns: Load/close modal pattern behaviour, condensed table design, filter container
Goal: All items in the modal contribute to the goal of making data management and navigation quick and easy. Keeping users on their screens and allowing for information loading through a modal was a unique way to increase task efficiency (which we tested!).
Interface Inventory
If you already have a clearly defined style guide, this might seem like redundant work. But another useful exercise is conducting an interface inventory and clearly labeling the existing “rules.”
This helps organize all current and future designs and ensures that new designs align with existing patterns and goals. Customer journey maps are also a powerful tool at this stage, ensuring you capture all designed components. You should also document your product's “signature moments” during the audit.
“Small interactions that become product differentiators (elegant loading screen). Most powerful are when they have a story about them” - Dan Saffer, Microinteractions.
Illustration by Nor Sanavongsay
Shared Language
Many great buildings weren’t built by a lone architect but by a team, all of whom shared a deep understanding of the design patterns that brought those buildings to life. Digital products are the same – built by teams. How we communicate and share practices is crucial to success.
In his book Language and Learning, James Britton explains that naming objects “brings them into existence.” In digital products, giving something a name gives it a future. If you give something a "presentation name," its future is limited – a pink button will always be just a pink button. But what if it wants to be a star!?
After naming patterns, it’s crucial to share them appropriately and have a system in place to continue that sharing.
Almost there - let’s talk the parameters of these systems!
1
Do we want a strict or loose design system?
A strict system will have comprehensive, detailed documentation and full synchronization between design and development. There will be a clear process for introducing new patterns into the system. A strict system should be broad enough to cover most cases teams may encounter.
A loose system allows more room for experimentation. It provides a framework while still preserving some freedom. Designers and developers can choose to use it or not, depending on their specific needs.
2
Do we want a modular or integrated system?
A modular system consists of interchangeable parts that build upon each other to create whole systems. This approach is agile – multiple teams can work on modules in parallel, and fixing one module won’t affect others. It’s also adaptable, allowing modules to be assembled in different ways to meet user needs.
An integrated system consists of individual parts that are designed to fit together, but are not interchangeable. It tends to be more coherent and connected, reducing the risk of disjointed elements. However, it is more rigid and restrictive.
Benefits here: Tend to be more coherent and connected reducing risk of disjointing something. Built quicker as a system (no need for reusable parts) However, it is far more rigid and restricting.
3
Do we want a centralized or distributed system?
A centralized model means rules and patterns are managed by one group of people who define the patterns, have veto power over the system, and maintain the design system library. The advantage here is ownership – the system is curated, maintained, and evolved over time.
A distributed model means everyone who uses the system is responsible for maintaining and evolving it. This model provides autonomy, is more agile, and is resilient – if one team misses something, another can pick it up.
Personally, I prefer a centralized model, where leaders champion collaboration and innovation from various teams. This can happen through quarterly brainstorming sessions or “design jams” focused on the system.
