Lessons learned building a design system at scale
Design systems are a crucial part of product development and their benefits are easy to see — they help designers and developers focus on solving problems without worrying about UI details, prevent design and technical debt, safeguard accessibility standards and facilitate a more efficient product development process.
Over the last two years, our design systems team built the Booking Design System which is now widely adopted throughout the company. In this article, I’ll share 5 lessons we’ve learned along the way to help you build yours more efficiently.
Design systems are product development tools that come in different shapes and sizes depending on the product strategy they’re built to support. Before investing time and resources into building one, take the time to consider why you’re building it — this’ll save you a lot of headaches later on.
Think about how your design system will align with your product roadmap and concretely define the top-level business problem you want to solve. This will facilitate every design decision you make during the process and also inform your definition of success. You could build your design system to scale up a certain platform, to provide a consistent cross-platform experience or simply for marketing. All these different scenarios will require different approaches, development strategies, success metrics and different people involved.
Having a clear goal will also help you with adoption. Design systems help product teams reach their goals faster and more efficiently, so as long as you clearly communicate how your design system will help solve a certain business problem, you’ll find that it’s easier to rally people behind your cause.
Establishing a common language across all roles in an organisation is the cornerstone to a good design system. Because systems design is such a complicated subject requiring a high level of thinking, the lower you keep your barrier to entry the higher your initial adoption rate will be.
A good design system should be intuitive. Unless your colleagues are familiar with the topic, don’t start with a complex structure or complex terms and methodologies, those can come later. Initially, keep it simple.
If you find yourself explaining different parts of your design system to your colleagues over and over again, there’s most definitely room to simplify. Leverage the fact that you’re as close as it gets to your end users. Grab your colleagues, get their feedback and just like any other iterative process, iterate until you remove all the unnecessary complexity.
Although we took lots of lessons from other famous methodologies (such as Atomic Design), the initial version of the Booking Design System came with a simple structure and methodology:
Being simple and easy to understand, this structure allowed designers, researchers, front-end developers, copywriters, and product managers to learn and speak the same language quickly, reducing the time required for product teams to integrate the design system into their products and day-to-day work. It also enabled us to organically shape the future of our design system depending on the needs of our product teams. Today, we use a different methodology with a more complex structure. And we can afford to do so since everyone is well educated and knowledgeable around the topic.
A design system shouldn’t be a policing tool. While it needs to ensure that your highest standards of quality and accessibility empower your designers, it also ought to create an environment where anyone can contribute easily to its continued development — doing so is really important for creating a sense of shared ownership, and helps speed the creation and implementation of the system.
Dan Eden on Paving the Path of Least Resistance
The moment your design system becomes a hindrance for a product team, you have an opportunity to collaborate and come up with solutions that will benefit others later on. At Booking, our product teams have extensive knowledge of different sets of user problems they work on. Sometimes the solutions to these problems require them to design new patterns into our products. By having well-defined processes and guidelines for contribution, we make sure that the extensive work done by our product teams are fed back to the system when possible.
Members of our design systems team are always on call to facilitate collaboration sessions where we discuss these new patterns and if they can benefit others. We consider a series of questions from a living template we’ve build over time, such as:
Then we work together with that product teams’ designers and developers to have their pattern go through an abstraction layer and eventually feed back to the system. Going through this process many times, we’ve found that it’s not only beneficial for the system but also serves as a great educational tool that gets people familiar with how our design system works.
Documentation is a must-have for design systems of any scale. It allows everyone to make consistent decisions, fast and efficiently. If you provide detailed documentation to support every single aspect of your design system you’ll find that in no time, your users are very competent in the use of your design system.
But in order to unlock the full potential of documentation, you have to take it beyond describing component specs. Here’s a list of things you can add to your documentation to make the most of it:
It’s also a good idea not to keep your documentation limited to components. Documenting different UI concepts or patterns, design principles and even your contribution guidelines will answer lots of questions regarding the usage of your design system. As an added benefit, with more topics you have documented, the more people you will have contributing as long as you have clear guidelines.
Our design systems team makes multiple decisions every day. In time, we’ve found out that if we don’t document these decisions and they only live in our minds then they’re not a part of the system. Blame yourself first if someone is not using the design system in the “right” way. It’s most probably because you haven’t provided enough reference material. There’s an easy solution to this though. Make documentation mandatory in your release process. Have a checklist to go through with every merge request to your design system to sustain a higher quality of documentation.
Building a design system isn’t enough. To provide even more efficiency to your users, you have to proactively integrate your design system into their workflows with tooling.
The first rule to tooling is to deeply understand your users’ day to day tasks and workflows. This way you can build tools that organically become essential to your users’ workflows. After you consider which audience will use your design system the most, prioritise accordingly and you can build a variety of tools spanning from Sketch libraries to component viewers to code editor plugins. The more tools you build, the more relevant you become to a wider audience. But there’s a catch.
With every new tool you build, the risk of tech and design debt can increase. A good way to prevent this is to dissociate your tooling from your design system and build it in the form of a service. Having your tools consume their information from one source of truth (the design system) will prove better in the long term and allow for a foundation to build more tools upon.
Our design system app BIQ is one of our major design system tools. It’s widely used by designers and developers as a companion tool to their day to day tasks. You can see how it works here.
It does a great job at everything previously outlined for such a tool: proactively integrating into our users’ workflow, using a single source of truth and keeping everyone up to date with our design system. With the advantage of being a native app thats deeply integrated with Sketch, BIQ can control and install new versions of our Sketch libraries into our users’ devices with every release of our design system. Our designers can then use the latest UI components in their designs as Sketch symbols and our developer can get the latest code snippets that match those designs without breaking a sweat.
Another added benefit to using BIQ in your workflow is its focus on accessibility. Accessibility is a topic we care deeply about at Booking. Not only that it helps product teams to comply with accessibility standards effortlessly, being human-centered also betters the world and brings us a step closer to achieving our company mission to empower people to experience the world. The colour contrast checker and the accessibility documentation are one of the most used features of BIQ and they help our designers and developers on a daily basis.
Building a design system is a challenging, never-ending process. It might be daunting at first, but it’s not so different from building any other product. As long as you know why you’re building it, listen to your users, understand their needs and smoothly integrate your design system into their day-to-day context, you’ll be on track for success.
🙌 🙌 🙌
Thank you for reading. If you want to chat more about design systems, please comment below or find me on Twitter.
Special thanks to Stuart Frisby, Phil Hammel , Steffan Williams, Erin Weigel, Jason King, Cătălin Bridinel and Steven Baguley for their help and support.
Lessons learned building a design system at scale
Research & References of Lessons learned building a design system at scale|A&C Accounting And Tax Services
Source