Design Systems
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 purpose of digital products. Together they make up the foundation of what we know as design systems.
Patterns
Patterns are repeating, reusable parts of the interface (components) that can be applied and repurposed to solve a specific design problem or meet an interface need.
Functional patterns: Behaviours (Tangible building blocks - buttons, headers, forms). These are the physical embodiments of the behaviours we’re trying to encourage or enable
Perceptual patterns: Descriptive styles that express and communicate the personality of the product visually: colour/typography/voice
Shared Practises
Shared Practises are how we choose to create, capture and share and use those patterns. How do we communicate with developers? Product? The practises we have here are just as important as the visual elements in the design system itself - having proper handoff procedures is critical to design system optimization
Okay - that’s the foundation. How do I start organizing them
Throughout my career I have been involved in creating from scratch or optimizing design systems; and it always starts the same way, by asking what the products ethos is. What is our tone of voice? What are we trying to say with our typography? Color and icon choices?
All of these details are core product functions that need to be defined and shared with the teams. It’s important that when these decisions are being made its done collaboratively trying to include various teams. Sharing these findings early on help get everyone organized and contribute to the 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, and 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 end up getting a list of ethos-directions and are one step closer to building your product!
At Rubikloud we ran a few 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 products ethos a good exercise to do 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 grouping of talent will always uncover very unique results) and ask them to write down the following:
Write down in your opinion, what is good design? What does it mean for our product? How would you explain it to a new member of your team? What are the most important parts of the product (include screenshots)
Remember to use actionable phrasing; “Make it clear” is vague. “One priority, what do you want users to see and do first” is an actionable principle.
Spotify uses TONE (Tone, Usable, Necessary, Emotive) (This is beautiful!!)
The designers on these teams should be able to identify these principles, and if there are different principles between designers, the gap needs to be addressed
Design Principles: Step 3
You will now have a white board (or MIRO/FIGMA) board full of interesting details and ideas! What do you do now exactly!?
First thing is to group all related items, afterwards, group all the stickies that have common themes or unity - remember, unity is very good to uncover and means the team is naturally aligning on goals.
Now you want to find functional patterns - look at the screenshots and start looking at common themes and component practises:
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 the items on the modal contribute to the goal of making, managing and navigating data quick and easy. Keeping users on their screens and allowing information-loading through a modal was a unique way to increase task-efficiency (which we tested!)
Interface Inventory
You might be in a position where you have a style guide that’s clearly defined, and looking at the above seems like a bit of redundant work. Another good exercise to do is to conduct an interface inventory and then to clearly label out those patterns of existing “rules”.
This is a good way to organize all future and past designs and to label out the patterns moving forward; therefore, whenever someone creates something new, we know it will be in line with our patterns and goals. Customer journey maps are a powerful tool for this step to make sure you’re capturing all the components designed. You should also be capturing your products “signature moments” during the audit as well.
“Small interactions that become product differentiators (elegant loading screen). Most powerful are when they have a story about them” - Dan Saffer, Microinteractions.
Shared Language
Illustration by Nor Sanavongsay
Many great buildings were not built by a lone architect, but by a team. They all had to have a deep, shared knowledge of the design patterns that were capable of bringing these buildings to life. Digital products are the same, built by teams - how we communicate and share practises is crucial to success.
In his book “Language and Learning” James Britton explains that conferring names on objects “brings them into existence”. With our digital products, giving something a name gives is a future. If you give something a presentation name, it’s future is limited because it will only be confined by it’s a style (a pink button will only be a pink button! But what if it wants to be a star!?)
After you name them, you want to share them appropriately and have a system in place to continue to share them.
Almost there - let’s talk the parameters of these systems!
Do we want a strict or loose design system?
A strict system will have a comprehensive and detailed documentation and will be fully synchronized between design and development. There will be a strict process for introducing a new pattern in the System. A strict system should be very broad in order to cover the majority of cases the teams may encounter.
A loose system will leave more space for experimentation. The System is here to provide a framework for the teams while preserving some freedom. Designers and developers are free to use it or not, regarding their particular needs for their product.
Do we want a modular or integrated system?
A Modular system is made up of interchangeable parts that build on-top of each other to creates wholes. Modular approach has some advantages: agile - multiple teams can design and build modules in parallel. They are pretty easy to maintain - fixing problems in one module without affecting others. Is also adaptable because modules can be assembled in ways that meet user needs. This follows a lot of what atomic design wants us to do.
An integrated system is made up of individual parts but those parts are not interchangeable because the connections between them are not designed to fit in different ways.
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.
And lastly, centralized or distributed system?
Centralized model - rules and patterns managed primarily by one group of people. They define the patterns and rules, have veto power over the system and manage the library and resources of the design system. Major advantage here is ownership - responsibility = curated, maintained and evolved system overtime. “Design systems designer”
Distributed model - everyone who uses system is responsible for maintaining and evolving the system. This provides autonomy for individuals and empowers them to make decisions. This one is more agile and resilient - if one team misses something another can pick it up.
Personally, I always like to have a centralized model where the leaders champion collaboration and innovation from the various teams. This can happen by having quarterly brainstorms and “jams” on the design system.
Takeaways + My Work
1. Start with ethos
2. Agree on guiding principles
3. Collect and group elements
4. Define patterns and goals
5. Define your system parameters
