This case study is currently being drafted. Please check back soon for updates…

PRODUCT

Components

VALUES

“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.

CANDIDATES

• Accountability
• Boldness
• Collaboration
• Community
• Compassion
• Continuous Improvement
• Curiosity
• Customer Commitment
• Decentralization
• Disruption
• Diversity
• Empowering
• Fairness/Justice
• Flexible
• Honesty
• Humility
• Inclusion
• Innovation
• Integrity
• Intuitive
• Making a Difference
• Passion
• Persistence
• Self-Improvement
• Sustainability
• Teamwork
• Transparency
• Trust
• Uniqueness

FINALISTS

• Community
• Compassion
• Decentralization
• Disruption
• Diversity
• Empowering
• Fairness/Justice
• Flexible
• Inclusion
• Innovation
• Integrity
• Making a Difference
• Transparency
• Trust
• Uniqueness

PRINCIPLES

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.

Think Inclusively

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.