What is a Design System
A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
Think about a guild. One person from each pillar comes together every two weeks to see whats new.
Do a horizontal view to see what all the products are doing and to identify global patterns
Overview
As your platform grows and evolves, it’s important that the design patterns and visual style are upheld to deliver a defined and cohesive experience. In order to achieve this, you need to have a single point of reference for all the patterns you use, so that everyone internally can refer to them. You also need a shared vocabulary of UI elements and code, to allow teams to communicate with each other in the most efficient way.
Purpose
to document the patterns we use, using the agreed shared vocabulary
to ensure a consistent use of patterns and UI elements
to provide guidance on correct usage of the patterns
to encourage re-use of code, reducing redundancy to a minimum
Approach
How to Build a Successful Design System: Design Systems that Developers Love
Design systems (DSM) facilitate many teams and their processes. Not only designers and developers but QA, for instance, have found benefit from them as well.
Holistic point of view
DSMs are tools that enables efficient creation of products. The sum of a product isn’t just the UI or the UX design, but it’s also the front and the backend code that actually allows consumers to interact with the product.
DSMs aim to provide deliverables between cross functional teams. Not just design but to realize and design an actual product. So as it serves cross functional teams, the ownership of a design system needs to be cross functional as well for it to be a success.
How to
Debunk the notion that design systems are only for developers early in creation process
Allow input from other stakeholders around the business
Workshops
Engagement sessions
Why they fail
Lose sight of common goal - Making great products
Language barrier
Finding common shared goals (We want to create great products)
Design Systems are a translation device
Foster communication
Developer principles within the DSM
Rules on writing and tone (principles)
Naming conventions (for better handoff process)
There’s many different views of a component and many things people are getting out of that.
Visual - What it does it look like
A UI designer might be concerned on how a component looks, is it consistent with the brand, does it align with the purpose and principles.
Interactive - How it responds
UX designers concern themselves around interactions. ie. How do people interact with this component and how it responds to its users.
Content - How it sounds
Content writers are inherently concerned in how a components terminology speaks and communicates to users based on our tone and voice.
Front-end Dev - How it functions
Front end developers might be interested in how they can make the experience consistent throughout the entire application.
Back-end Dev - Where it’s data lives
How do they store and access data?
Data - How it performs
Data analysts may want to monitor how the system is behaving and find opportunities for other departments to improve the application from their point of view.
Summary
Each point of view into a DSM is different, but they all rely on each other. It’s not only important to have an understanding of each others views into this component but it’s also important to have a tool to put all of these different views into a single place and piece them together, especially when it comes to versioning of each of these components.
Message to designers
Sometimes less is more - break things up and prioritize
Alignment is more important then detail
Choose your battles
Bring in your partners early
Show developers a component early in process, understand what they might need to do to code the component
Find common language, adapt developer vocab for components where it exists (it’s already built)
Developer Perspective
Push back before you build
Don’t be afraid to share - a sketch, a comp, a screenshot, etc
Share your keys - current cost of debt, redundancy, QA
Help designers find unseen patterns (query code base: where are things being used?)
Remember, you’re an important stakeholder - be involved, take part
Work Together
Importance of stakeholder - who can you influence?
Slow down to speed up - early alignment is key
Communication makes or breaks a system - treat our users and partners with the same care as we would for any other product