Building Scalable Design Systems
A holistic view on building design systems as a product
Introduction
In recent years, it’s becoming more important to embrace a modular approach to design and with good reason; more screens, more devices, more sizes, more places and more people than ever before. Breaking out our interfaces into reusable modules in a pattern driven practice allows us to build faster and more effectively.
In this case study, I’ll be going through my process of building scalable design systems and using examples from a number of the systems I’ve built for some of the companies I’ve worked at.
Problem Discovery
In many of the companies I’ve worked in, there are products currently in the market and actively being used by tens of thousands, and in some cases millions, of users. Common feedback received about the interfaces revolve around the same premise:
- Page designs are inconsistent
- Interactions are archaic and unfriendly to the end-user
- The products are ugly or look outdated
- Features don’t work as expected
- New products start without any sense of framework or guidance
At iPlato, through the discovery phase, I found over 144 different colours being used throughout the mobile app alone. The vast majority of these colours ending up being various shades of the “brand blues” with one core brand colour being completely absent.
At PRSfM, there were almost 30 different spacing measurements being used. Other findings included 18 different variants of the body font size and no Type scale. Other inconsistencies revolved around an extremely strict responsive system being utilised in their CMS tool which wasn’t being run in a headless function.
In startups, where I’ve had more free reign to start afresh, the problems revolve around providing the best user experience with limited resources.
Design Systems as a Product
Building out a Design System should involve more than just the product design team and handing over screens to engineering. By considering a Design System as another product within the company, and maintained in the same fashion as any other product.
For the most effective design systems, including the entire team and their skill set helps build the team dynamic, have everyone contribute and have a sense of ownership of this internal product. Marketing can own the Design Language and define color from branding, typographic scale and levels of elevation, whilst engineers can actively work on and add to the Component Library being mirrored in the Design Kit being put together by product designers. Product Owners are also able to test with Engineers in the Developer Sandbox and help define a common language within Documentation.
Design Language
The foundational characteristics such as typography, colors, icons, spacing and information architecture.
Design Kit
Figma library of shared styles, symbols or components. These are mirrored with the component library.
Component Library
Pre-built components built into the codebase that are version controlled in their own repo.
Developer Sanbox
Developing components in isolation to document use cases and write structural or visual tests.
Documentation
Guidelines on how to consume the Design System and dev considerations.
Governance Model
Guidelines on how to continue to evolve the Design System and how contributions are made.
Design System Structure
For most Design Systems, especially in companies working on a single overall product, or using a single technology stack across their product suite, the six base elements above are more than enough to define and determine the outcomes. However, in companies where multiple products with different front-end technologies are being used, or even multiple platforms (native mobile and web based apps for example), then organising and structuring the Design System to feed into one another can be incredibly beneficial.
The below diagram displays how we built “multiple design systems” with a single one for the iPlato suite of products. The Product Suite included:
- MyGP Mobile – An iOS and Android app that is used by patients
- MyGP Connect – A web based communications tool that grabs patient data from the clinical record and allows Practice Staff to send individual and bulk SMS messages to particular chorts.
- MyGP Buddy – A native Windows desktop application that runs alongside the Clinical programs of choice to pull in data and allow for remote consultation via video, SMS and in-app messaging.
- MyGP Mobile – A React app used primarily for users who do not have access or unable to have access to the native mobile apps and allows for continuous support for remote consultation
The initial Foundations Library stores all the Foundational Tokens for Colour, Typography, Iconography, Elevation and spacing. When used as a library for other other repositories, changes to the foundational tokens can cascade through and have an effect to all products with the next deployment. The Design Kits will use the styling from the Foundation library and self update. From here, brand new or existing projects can pull in a Kit/Library and use these components from the get go.
From a Design Perspective, a separate library that houses all of this information allows for new projects to be kickstarted with all the styles, components and patterns already there for them. The ability to know exactly what individual components will do without requiring to handover every potential design to Engineering speeds up the handover process, as well as the prototyping phase.
The Atomic Method
The Atomic Design Principles laid out by Brad Frost are an industry standard, however they’re great as a starting point of a methodology and works best when extended. Any non-technical person can understand the basic principles immediately. In practice, categorising elements as atoms, molecules and organisms works well at first glance but immediately become debatable.
As a Design System gets built out the question arises “is this thing a molecule or an organism?:” What defines either? Is it the number of elements? The subparts? Visual space it occupies?
My approach adjusts the framework that is a bit more adapating for scale.
Foundation
This is the basic foundation layer of design tokens. Non-component basics that affect the very fundamentals of the Designs being produced.
Components
Basic building block components. Customised implementations of single HTML, non-divisible elements like headings and buttons.
Modules
Everything that can contain other components. A collection of components come together to create a usable module for purpose such as cards.
Prototype
Ultimately, people want concrete pages and prototypes, not design tokens or components. The template is a collection of all things assembled together.
Design Language and Tokens
The Design Tokens are formed from a brand identity and maintain the brand’s ethos. Through this, we can create a level of consistency within the product design to ensure standards are met. These tokens are also updateable, and in turn effect the whole system.z
Kits & Components
With most Design Systems, you’ll ideally want to built multipurpose components that can be used over and over again. From an Engineering perspective, it allows for developers to stick to tried and tested components that lessens the page load and and improve the speed of an application, as well as have a high level of certainty on the performance and usability of a feature.
When designing components in a Design environment, utilising the Tokens as the core foundational elements allows for an improved workflow. In a lean start-up environment, you want to minimise the amount of work done and focus on only building the elements that will be used in the upcoming sprints. This allows for great speed, however, regressions do tend to happen as new requirements are thrown in later down the line. Working with tools like Figma and the excellent Variant and auto-layout features allows me to build at speed. Where one single component, for example a button, can have upto 144 variations using specific parameters.
In the below example, there are over a hundred buttons that are designed and ready for use and can be adopted for any number of use cases in the PRS for Music Design System. Utilising variants, allows for the inclusion of icons, states size, colour and style.
Modules
As the component list is built out, modules start forming based around them. These collections of components in their specific structures create interface elements that form patterns and use-cases.
In the attached example from Borrow A Boat, the card designs are a combination of a Thumbnail Image, Heading Caption, Icon with Text, Price and then iconography, which when hovered will display the full name of the feature.
Each of these components are independant and can be optimised individually to create effective changes across the entire platform.
Prototypes
Once a Kit has been built out with components and modules, prototypes are a lot faster to implement and test out in the design phase, eliminating the wireframing stage.
This allows for much more rapid prototyping and building of product features outside of the UX Research phase. Due to the closeness to final design, it also enables stakeholders to view workable prototypes to test and provide feedback.
List Content
Documentation
The documentation process is incredibly important to the entire process and requires input from all members of the team involved in the development of the Design System. Any tool that can act as a standardised area for collaborative documentation can act as a solid base for a design system’s documentation area. In previous roles, these have ranged from using Notion as a complete Product portal/blog to document progress, release strategies and design documentation to using Confluence or even an entire WordPress installation dedicated to the process.
Adoption
The most difficult area of building design systems is adopting them into existing products and integrating them into the current workflow. There is no one-size fits all solution unfortunately and is dependant on the dynamic of the team and current workloads.
It is important to have foundational Tokens, Components and patterns that can replace existing areas of the Interface prepared and tested prior to deployment into a sprint. Part of the transitional process may include incomplete UI with a mix of previous UI elements existing with newer modular parts being present. These incremental updates are not ideal, but in environments where development resources are stretched thin, then the pragmatic approach would be to maintain advocating and pushing for adoption and being patient, as parts are slowly added into production servers.