7 requirements of a holistic design system
Dec 2019
I recently created a case-study for my colleagues in New York about a multi-brand Design System project I worked on, for one of our clients back in London. While gathering information for this presentation, I was inspired to write an article and share my thoughts about what I’ve learned during this year-long experience and how it opened my eyes to the broader picture. I finally found the time to publish it.
I’ll start by stating that everyone in the Product Design world is selling, talking or reading about Design Systems. It has become a “buzzword”. To add to it, there are so many different interpretations out there, it is frequently misused. I want to take a step back and define what exactly is a Design System, and what it isn’t.
A “Design System” in the context of Product Design, is a relatively new term. This is also due to the problems it is trying to solve — with the increase of digital products, screen sizes and number of devices we have these days. That is why the term is still vague and unclear.
What a Design System isn’t
It’s important to understand that a Design System is not a visual system or a design language; it is not a style guide, not a CSS framework, nor a pattern library. And yet, all these artifacts use system thinking (and system design), which is not new to us.
This is why words like “design” and “system” can be misleading. A style guide or a pattern library can be a starting point of a Design System (they are in fact the most common artifacts) but they’re not the only component.
(There’s a great talk from Diana Mounter at GitHub, that I strongly recommend if you’re interested in expanding on this topic).
As a starting point, I find useful to look at the differences between: 1. design guidelines and style guides; 2. living style guides; and 3. holistic Design Systems:
1. Design guidelines and style guides, are static guidelines (non-editable in principle). A great example is the beautiful NASA “Graphics Standards Manual”. Style guides and UI toolkits, provide the building blocks and design elements, along with guidance, theory and principles behind components and its usage.
2. Living style guides are a step further in the design process. In addition to the design guidelines, they embed the actual UI and are a trustworthy representation of the current state of things, with automatic rebuilds. For this reason they’re also easier to maintain, in contrast with style guides created as a PDF for example. Material Design developed by Google, Lonely Planet and Mail Chimp are great examples of living style guides, they display the real components along with the code (the real button — with its behavior, such as hover or click states — not an image of a button). They’re also extremely useful for quick testing, because you can immediately check the components’ behavior in different browsers.
3. A holistic Design System includes all design assets and tools, but also governance, ways of working and processes. BBC Gel, Salesforce Lightning and the UK GDS are perfect examples of Design Systems available publicly. In the case of the UK GDS website, there’s a community section with rules around how to propose and develop a new component or pattern, and a criteria for contribution. There’s a system in place with clear guidelines, managed by teams of people who are responsible for its outcome.
The manifestation of a Design System can be a website but fundamentally it’s an ecosystem, it affects the organization.
It is also relevant to add that just because something looks visually or “cosmetically” consistent it doesn’t mean there’s a system underlying it — a Design System is not visible at a glance. It’s hard to judge how companies work internally, their level of automation, or if there’s more to it than what is being shared. It’s worth keeping in mind that not every organization is fully-transparent about their internal processes and design methodology, and what’s frequently shown on the web is just “the tip of the iceberg”.
What a Design System is
A Design System is an ecosystem of components, interfaces, guidelines, architecture and processes, to satisfy requirements of a product or organization, and build deliberate outcome.
It enables teams to collaborate and build good design outcome, guided by standards and design principles. It’s a cross-disciplinary platform that streamlines the design process. To corroborate and add to this definition, I’ve compiled below seven requirements of a holistic Design System:
1. Creating a Design System requires designing the system itself
“A Design System is the official story of how your organization designs and builds digital products.”
— Brad Frost
It is not just about digital design. A Design System is made of many parts; not just the UI toolkits, UX patterns, the code and accessibility guidelines — those are the tools, the tangible output; but there are also the invisible layers (not necessarily reflected in the platform, but essential) such as processes and a governance model — it’s about how people work and communicate, what’s the process for reviews and feedback, and how new patterns are approved.
It’s about “how we design” at [insert the name of your] organization.
The creation and maintenance of a Design System blends different skills (visual UI and UX design, development, strategy, business and service design — it is also about the service this system provides).
It encompasses different audiences too: the company and teams (by shaping the way the organization approaches design, their vision and mission), the individual users of the System (PO, UX, UI designers, developers), and the end-users (the people who use the digital products, the final output).
“A Design System isn’t a Project. It’s a Product, serving Products.”
— Nathan Curtis
To add to the different facets, a Design System needs constant maintenance, it’s a living thing. The real challenge is approaching it from this perspective.
2. Its main challenge is a mindset shift
“A design system needs ongoing maintenance and support. Many teams still focus on the final implementation rather than the underlying system. There’s the need of a mindset change.”
— Brad Frost
In terms of best practices and to paraphrase Brad Frost, a Design System is based on four pillars: the Content, People, Processes, and Maintenance; as described earlier.
It becomes obvious why a Design System is never completed and needs to be kept alive, constantly. That’s why it is so challenging; it requires a mindset shift from focusing on the tangible artefacts and final implementation, to focusing on the actual system that is underlying everything.
To bring the project forward in the organization and for the System to thrive, you’ll need everyone to contribute. And because a Design System requires investment, a big part of the initial process is socializing and selling it internally — “winning friends and influencing people”, quite literally — it’s important to tailor your message according to your audience, in order to communicate its benefits.
For example, when talking to the teams and the design community, it’s useful to highlight how this system will make their lives easier, and showcase how much faster it will be to design; versus talking to managers or the “approvers”, where the focus should be on numbers, KPIs and metrics such as time saved, how many teams can be affected in the short / long-run, how much can be optimized and saved.
3. A successful Design System depends on ownership and advocacy
“The biggest existential threat to any system is neglect.”
— Alex Schleifer, Airbnb
Because without everyone on board there is no Design System. A company’s culture needs to be matured in order to adopt it; this type of initiative needs both top-down and bottom-up support. Design teams and leadership need to be on board with Design Systems, and dedicate time and resources to it.
It is crucial to have a solid governance model in place and review processes for teams to work more efficiently.
Part of it is the creation of a dedicated team responsible for standards and design integrity, guidance, resources and processes such as: approving new components (when there’s the need to create new ones), evaluate whether a pattern is an exception or reused enough across the journeys to become part of the Design System, facilitate discussions and feedback implementation.
It is not just about what we design but also about the way we design. While creating the foundation or building a Design System for your client, you should encourage the right people to own the decisions, because they’re the ones who will need to keep it alive.
Give your client ownership of the design process so they become advocates of this transformation.
4. Design and development are (really) two sides of the same coin
A Design System entails a framework for digital teams to create components from a shared library, in order to mitigate duplication work (for both design and development), inconsistency (i.e. visual, UX patterns), and solve for pain points in the process. It improves cross-team collaboration and defines how teams design.
Among other aspects, a relevant example is naming conventions. Its structure should be heavily discussed between the design and development teams, to arrive at terms that make sense for designers but also for how things are actually built in code — this enables a shared vocabulary.
This is when Atomic Design principles also come into play, to organize and divide components into categories that make sense for both teams, by asking questions like: “what’s the logic for designers to assemble UI elements when building screens?” and “how are molecules and organisms generated and built upon, in code?” (these categories can and should be adapted to your company’s specific needs).
Technical details impact design decisions — this exercise is a team effort.
5. A holistic Design System is future-friendly
It goes without saying: understanding the requirements of design at scale is vital in a holistic Design System. The larger the project, the more important the process becomes (even more than speed and delivery).
The scope and complexity of a company-wide Design System is also very different than creating a suite of websites or an app. The System needs to enable scaling (whether it’s a new brand, an added platform, or a new product) it should grow and adapt along with the teams and the technology.
A practical example is the overarching design principles of a Design System. These will inform every new component or product that is designed in the company — when designing something new, the teams should cross-reference the output with these rules to make sure it ticks all the boxes.
Ideally they should be kept high-level enough to apply to the different domains (not only interaction or visual design, but also tone of voice, content), as well as the desired qualities of the end-product as a result — while remaining flexible and open to future adjustments (i.e. product teams and expertise required, or product’s audience when expanding offering).
6. Solid standards eradicate design debt
We know that incremental errors and changes accumulate over time, and create a disjointed experience. When rules are not clear or teams have doubts regarding how to go about it, it’s a recipe for inconsistency and disaster — this is the opposite of a Design System.
It’s also the reason why exceptions are not supposed to be added to the System (adding countless variations of a component generates unnecessary confusion, since it‘s not crystal clear when or how to use it anymore). It is called a System for a very good reason.
“When building design systems, get into the habit of documenting early. You’re building a design system and that cannot work if the system is you.”
— Karri Saarinen
A successful Design System provides a clear framework and a centralized library for teams to test and create consistent, effective and valuable digital products. This is not possible without a solid documentation.
Getting into the habit of documenting early and clearly is paramount. After all, you’re building a ‘system’. Miriam Susanne sums it all up: “If it’s not documented it doesn’t exist.”
The platform should give the teams all the information needed to create and maintain digital products (their structure, the guidelines, the “do’s and don’ts”, in addition to the components and UI kits) — these are the fundamental rules.
Without the “instructions manual”, two designers may be looking at the same style guide and still interpret it or assemble components differently. Similarly, if a pattern or feature is not clearly documented, it might prevent incremental changes / adaptation, or appear broken. Details matter.
Another big part of documentation is onboarding (i.e. guidelines for designers on how to use certain tools or how to create a new UI toolkit; guidelines for library contributors, for versioning control or the creation of new libraries; guidelines for research and exploration of new patterns).
These standards and procedures are really important to be documented when onboarding new team members who just joined a project, or new hires. It insures everyone is working from the same baseline.
7. Better design requires investment
There are various case-studies and public data available, with concrete numbers on how much companies like Westpac or the Gov.uk have saved with their Design Systems and digital transformation initiatives.
Better design clearly means “better business”; but better design also requires investing in a better system first.
The benefits of a Design System are hopefully sold by now, but it’s still worth pointing out its top three design strengths:
Increased quality and efficiency, by reducing complexity;
Optimized skill distribution, by allowing teams more time to focus on overall user experience or the creation of new products, versus production;
UX & QA efficacy and savings.
These are huge business advantages. With a successful Design System in place changes are easier to implement, because the platform becomes the single source of truth.
This helps with consistency and encourages reuse — therefore building interfaces is done in a systematic way — not only faster, but also resulting in higher quality output.
The system also becomes more valuable and requires less effort as time goes by, because the more components you have in a library, the less you need to design from scratch.
The fact that the components are reusable is what enables scalability — teams spend less time duplicating, and more time creating. It is worth the time and money invested.
Design Systems continue to be a “hot”, relevant topic, because their benefits are an integral part of any legitimate digital transformation initiative in the exciting days to come (not a mere add-on).
Design Systems are hard work to setup, run and maintain; it is not uncommon to take several months to a year — just to get started. It really depends on the scope and project’s complexity; the company’s needs, ways of working and preferred tooling.
Not every client needs a company-wide Design System, and teams come in many different sizes; the crucial part is to design the system with a holistic approach.
Despite the big efforts involved, savings are considerable and immensely valuable. When summarized as faster, cheaper and better products to market; the case for a holistic Design System couldn’t be more compelling.
This article was originally published on Medium — UX Collective publication, December 2019. Also featured on the Marvel App blog.