[greybox]
A review of
Building Design Systems
by Sarrah Vesselov and Taurie Davis
Publisher: Apress
141 pages, 8 chapters
About this book
A good reference for Methods/How-To
Primary audience: Designers who are new or have some experience with the topic
Writing style: Matter-of-fact
Text density: Mostly text
Learn more about our book review guidelines
[/greybox]
If you’re familiar with the huge amount of work that entails creating and maintaining a design system, you’ll wish you had come across this book earlier, as it’s full of wisdom nuggets you’ll want to implement as soon as possible. If you are just starting with design systems, you’ll learn, anticipate, and prepare for the endeavor with lots of practical advice from this book.
The authors first take some time to introduce us into the world of design systems, which works as a great way to understand where they come from historically, from Bauhaus all the way to the present. The main goal of this introduction is to develop a definition of what a design system is in the context of the engineering, product, and design disciplines: “A design system houses the processes and philosophies behind your design decisions. Your design system is a documented approach to systematic design [which] lets teams move faster by reducing the layers of translation between design and implementation.” This leads to stating the differences among design systems, style guides and component libraries, terms that many times are used as synonyms in everyday life when they are distinctly different.
And then, they dive right into what in my opinion is one of the highlights of this book. Instead of jumping to implementation phase and how to organize and create components (they do that thoroughly too, but in Chapter 5), the authors help the reader understand if and when it’s the right time to implement a design system in their company, based on the age of the organization, its team size, and the volume and type of work they do.
Chapter 3 focuses on the very important topic of how to sell design systems internally. It does so by showing where the value of a design system is for the company, soft skills required to have the necessary conversations, and also useful insights to understand each of the different stakeholders, and it even includes personas of them.
While it would be easy to just focus on “design stuff”, over and over again the authors take the time to encompass the design system quest as a multidisciplinary effort that requires designers to be strategic about it. Chapters from four to six, dedicated to ideate, implement and maintain a design system, are rich and deep dive in topics ranging from lexicon, guidelines and design principles to accessibility, technical implementation and measuring impact across the company (to name a few) include clear definitions, useful examples and techniques you can apply in each stage. Same for the Gitlab case study, where you can see their starting point (a fast-growing product with major inconsistencies, and a design team already maxed out), challenges they faced (getting stakeholder buy in and implementing a design system without slowing down the larger goals of the product team) and the strategies they put in place. Some of their key learnings were to create a unified vision, setting clear, attainable goals, and to evangelize early the main stakeholders and get them to be allies of the process.
Something I really liked is that the book uses the clever trick of referencing other chapters whenever two topics connect (for example when discussing possible reasons of failure, they associate it with the appropriate section to avoid each pitfall); this allows the reader to not only read it as it is intended, but also use it as a reference guide and jump quickly from one section to another.
This book is really helpful because it offers meaningful insights of the politics and everyday life of creating and maintaining a design system, while at the same time it also de-risks the most critical instances, with content such as “Understanding Why Design Systems Fail” or “Salesmanship: Preparing for the “No”. The biggest value it offers is that it helps you, time after time, to plan for the best and prepare for the worst. Sometimes plans will fail, but after reading this book, you won’t be caught off guard again.
[bluebox]
Engage with other teams and key players within the company. Most important will be members of product and front-end engineering, as they will be the first to reap the rewards of the system. They may also be your staunchest allies.
Diplomacy is not about politicking or quid pro quos. Diplomacy is about understanding and defining the expectations of both you and your colleagues. Build trust and be flexible. Listen to their needs and make a concerted effort to find the balance between your needs and theirs. Not only will it help ensure support from other departments, it will also help to better inform and shape your design system.
As a part of diplomacy, you’ll have to educate those around you about what it is you are proposing. Don’t assume what others know, or don’t know, about design systems. Practice empathic listening when speaking about your design system. Don’t expect that they have understood what you have said. Try to put yourself in their place and listen from their point of view. Look at their body language and pay attention to the questions they ask. No matter how well you think you are messaging your intentions, they may not be understood.
[/bluebox]
