A decade+ building design systems
My definition: A Design System (DS) is a living product that provides standardised components for designers and engineers to consume during development. By “living product”, I mean there’s a backlog, roadmap, and constant iterations. Typically, it also means there is a squad that creates and maintains the DS. Components are consumed by engineers and designers across all squads, and they (plus customer feedback) inform how each component needs to be improved.
My purpose: A design system is not just a library of components. It is a product that enables operational speed, by removing repetitive work within each squad. While standardising and elevating product-quality and user experience. In order to keep it working efficiently and remain relevant to the product being built, it requires maintenance.
A DS is defined from core concepts like variables, colours, and layouts. Which forms a basis for primitive components. This in turn creates a foundation for more complex components and UI patterns.
“Unit-sizing” always plays a critical role in UI scalability and terminology. It provides a consistent fabric for components to gracefully nest within one another and sit adjacent or list effectively in user-interfaces.
All of the above concepts contribute to “universality“ in component design, which creates both robust and beautiful designs.
A DS is never created alone. Most of our understanding for which components we require and how they should work comes from scoping & development, which happens within sprints. It’s impractical to assume that every component will be ready up-front or for feature-squads. Or to wait for the DS squad to approve components before consumption. By design, that is a highly dependant structure — and doesn’t won’t. As a design lead I support weekly DS-ceremonies where teams come together to whiteboard what works and what doesn’t -> Which is then documented in the DS backlog.
We commonly see components specified in Figma and a developed version stored in Storybook. But documentation (as a Wiki) plays a broader role in adding extra context for how things should be used, what has been learnt, as well as specifics around content-standards for things like PII, internationalisation, and currencies (to name a few).
Note: All design systems work and explanations, such as how I express, explain or visualise concepts relating to DS thinking, are unique to me. This are perspectives I’ve developed over the last decade and are typically in line with best practices in regards to DS thinking. I often use these concepts to educate Product and Engineering teams looking to establish or improve their Design System. I’ve developed more than 6 Design Systems from scratch with long-term contributions to each — with an individual system’s iterations often spanning more than 18 months. Creating complex and mature systems that are adopted by teams.