Biagio Design System
This case study is currently being drafted. Please check back soon for updates…
“A design system is basically the story of how an organization builds a digital product” ~ Brad Frost
Values are qualities that drive principles. They are the small, carefully chosen subset of intentionally broad (bordering on obvious) adjectives that serve as a mechanism to inform principles. They describe how a product should feel when using it.
- Continuous Improvement
- Customer Commitment
- Making a Difference
- Making a Difference
The Biagio Design System is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
Principles are the practical, stern, opinionated standards that guide decision-making. They reinforce the core values and help decisions move in a consistent direction. They are catchy, memorable, and specific sentiments that unify the product experience under varying circumstances.
Tools Over Rules
Think of the system as a toolbox, not an instruction manual. Support the community, don’t block them. Design systems are about empowering others with tools and information to improve upon what has already been built — not policing against it.
Lead by Example, Not by Explanation
Show best practices with real examples, not instructions on how to recreate them. Writing an instruction manual on design patterns is laborious to write and read. It’s significantly easier to adopt, understand, update, maintain and implement from live examples. Also, a system can’t, and shouldn’t, try to predict every situation a component will be used in with documentation.
The Goal Is Efficiency, Not Consistency
There are a lot of goals of a design system: consistency, usability, coherence, consolidation, accessibility, efficiency… the list goes on. The point of this principle is to remember the primary driver for a design system is not to enforce consistency.
Consistency is a result of efficiency, not the other way around. When the system is intuitive and empowering to use, consistency becomes an automatic by-product of adoption. Sure, consistency is a key consideration, but when it’s the main priority of the system, it becomes a self-governing restriction that causes stagnation.
Remove What’s Not Absolutely Necessary and Perfect What Remains
It’s very easy to add. It’s almost impossible to remove. Every addition should fight to be included. This is a difficult line to draw, but complexities that creep into the foundation of a design system propagate out and become much harder to amend if users get accustomed to it.
The more you add, the more you maintain. Each time something new is adopted into the system, it becomes a pattern to follow in subsequent definitions.
Accessibility is an integrated part of design system development, not a box to check at the end. Inclusivity is imperative for building successful, ethical products that scale. Not to mention, accessibility is hard, and design systems are in the unique position to champion it as a fundamental standard for design, development, and content strategy.
Design Systems Speak in Tokens
How a system defines, references, talks about, and curates its design tokens (of all tiers) is very important. They are the soul of your system’s aesthetic, the most fundamental visual building block, and the glue that holds the system together in a way no other part can. It’s also frequently the code most likely to be leveraged across code bases.
The System Succeeds When It Can Be Used Independent of Its Creators
This is more of a north star than a principle, but I find it to be a particularly useful periodic gut check. The system succeeds when it equips others with the principles, knowledge, and tools to solve problems without the design systems team.
I think about this principle a lot like the proverb, “Give a person a fish and you feed them for a day; teach a person to fish, and you feed them for a lifetime.” I find it to be a much more rewarding experience when the system strives to inspire the approach to solving problems vs. being the catalog of previous solutions to them.
Flexible enough for different scenarios, specific enough to be useful
This principle is a work in progress for me cause it’s not an easy one to follow from a practical standpoint. There is a strong tension best illustrated by a favorite principle of mine from Nathan Curtis:
Modularity is important (especially to encourage adoption) but too much, and it starts to feel like a puzzle; too little and it doesn’t leave enough room for flexibility. Finding the sweet spot depends on the team, business, product, and component.
- Figma Tokens (Design Tokens)