What is a Design System?
Design Systems are a hot topic right now, with leading products and hip organisations all developing them, but design systems have been around for decades. We know them as Graphics Standards or Brand Guidelines — a set of principles, rules and design elements that are used to create a brand's communication.
For most brands today though, the vast majority of their communication (and relationship building) takes place on digital interfaces. So a typical graphics standard manual barely covers the tip of the digital iceberg. Enter the Design System of today — a set of principles, rules and reusable components that can be assembled in different combinations to build any number of experiences, allowing companies to manage design at scale.
A design system does not replace a brand’s overarching guidelines, but is rather like a giant ever-evolving-living-appendix.
Why build a Design System?
For the same reason that graphics standard were created — consistency
To build brand equity and ensure the relationship your customers have with your brand is familiar and consistent, we create patterns for design, guided by principles that express your values. Simply put: every time somebody interacts with your brand, everything looks and feels the same.
Because they save money (if done right) — efficiency
An easy sell. If all your various design and development teams are using the same building blocks, which only have to be built once, then this will create massive cost savings on design and development time. Yes, BUT to create systems that work for your company, that allow your teams to use and contribute in an effective way, you need ways of working tailored around your organisation's unique makeup and digital footprint.
What’s in a design system?
Principles for design
This is stuff that matters, this is how your team* will evaluate new design. Principles can be created at a very macro level. For example, Salesforce's Lightening Design System is accessible, living and platform agnostic.
*Ultimately your users evaluate your design. Data insights and testing should inform design iterations.
If there are specific areas or components that are crucial, it is worth creating principles at a more micro level. For example, Google’s Material outlines principles at a component level, becoming a checklist for whether the component is designed and implemented correctly.
Naming, states and classification
For people to rally around design; to talk about it, change it and implement it, you need to have a shared language to ensure no one is wasting their breath. First you need to figure out what everything is called. Are you calling your user inputs “text fields” or “text inputs”, or is this a “notification” or a “snackbar”.
And then when designers design different states, we need to name them in a descriptive way, which speaks to the usage. So rather than button-blue, say button-primary-icon. These names can be used to create design tokens, and should follow a consistent structure from design to code.
If you are creating simple components as well as complex grouped components, it makes sense to add a classification to the component name. Brad Frost’s Atomic Design has quickly become a natural starting point, with small simple elements being classified as “atoms”, more complex components “molecules” and grouped components or sections “organisms”.
Foundation
Going back to our brand guidelines, these are the base brand elements that are used to construct components. They are not in themselves “interface” but rather the overarching foundation of your brand: type, colour, imagery, shapes and iconography.
For example, your brand’s primary colour, let’s say blue is combined with your typeface, an icon and a rectangle to create that button-primary-icon.
With modern interface design tools, foundational colour and type is saved as styles, so that these elements can be shared and updated effectively and efficiently.
Components
Components are the all important building blocks that product teams use to build out an infinite amount of different experiences. This will include everything from simple form elements to way more complex cards, menus and interactive organisms (think graphs or maps on a native app). Components are organised according to the naming conventions within one or multiple libraries and made available to the wider team.
In the old days (5 years ago, lets say) overworked siloed designers were banging out tons of similar non-battle tested components, following vague guidelines and an even vaguer understanding of best practice. Developers would all code up their own components and deploy...
Today, when leveraging a design system, teams can align around building perfect components that look, move and behave exactly as intended, and get rolled out with as much consistent code as possible.
To sum up
If your product or service has more than one app/website, you need a design system. Design systems help product teams to create consistent and on-brand experiences that delight their customers. Managed correctly design systems create efficiencies and reduce design and development time, saving money.
Adaptive has played a critical role developing some small and some big design systems. Look out for our next post: “What we have learnt about design systems”
