Article written on Friday, 10 Jul 2020
Setting up a design system is not a small job. There are so many things to consider. You might also just wonder if you, or the company you work at (or for), actually need it? If you need to know how to get started, which approach is most suitable, or which tools fit best, then this book 'Laying The Foundations' will lead you the way. Here's my full review ...
Let's start by mentioning that you have to make sure not to skip the foreword, written by Meagan Fisher Couldwell aka @owltastic, as it says a lot about what the book is all about. It actually comprises it perfectly.
CHAPTER 1 & 2
What is a Design System, and how do you sell it?
Andrew starts by explaining what a design system is, what the advantages are, and how you can sell the idea of creating such system. By highlighting common problems most developers can identify with, you sow the seed of the idea. This way you can try to make them excited about how this could be solved. Andrew explains how you can make as many people as possible enthusiastic with all the ways a design system could benefit them, whether it's designers, developers, managers from marketing or sales,...
The designs we create can shape our world in positive ways. When we design systematically, we're able to efficiently create better experiences for our users — but design. Systems also empower us to work better together.
The book also explains why it's important to have a design system, especially for large companies, because it's about solving problems. It's good to have brand guidelines, and to use that as a manual, but putting these guidelines into practice is usually another thing. That's where a design system comes to play its important role. Andrew explains the value of having such system, why it saves time and money and talks about other benefits.
First you get to understand what a design system is, because you need to know what it is for, so you'll be able to sell it of course. Also, this selling, is not just a stage of the process. It's an ongoing thing. This ongoing process of advocating, and it 's as important for its success as the creation of it. The book explains the why and how.
Laying The Foundations
From here on, the book explains how you can set up such system, starting by laying up the foundation. "In order for teams to work together to create great products, they need a strong foundation" Andrew states. Digital brand guidelines is one way to get started. Andrew approaches this from a realistic point of view knowing that in 'real life' it's not that simple as 'starting from scratch' with a shiny new system. In reality you often have to either inherit a mess, or at least deal with a lot of issues to address...
In 'real life' it's not that simple as 'starting from scratch' with a shiny new system...
In his book Andrew explains how brand guidelines and design systems work well together. Having strong guidelines for your brand identity is a vital piece of your 'Digital Foundations'. With 'Digital Foundations' you define an all-encompassing set of guidelines for all the different digital properties. Its intention is to unify all these, to be the starting point of each. Meanwhile Andrew also touches the valid point of being as accessible, and as inclusive as possible and explains this with particle examples and resources. While a lot of companies make these Digital Foundations publicly for the world to see, since it's good for P.R., and recruitment, he warns not to loose focus on its core reason.
Design System Model
Andrew starts with the importance of having a shared language and understanding that everyone on the team feels comfortable with, because there is the confusion of using different terminology used in a different context. The simpler the language, and the less jargon, the easier to communicate.
Andrew introduces us to his own terminology and model and uses this as an example to explain the basics of how you can set up a design system using these terms. He explains this by showing examples of a system he created for Adobe Portfolio.
As design is mostly about problem-solving, Andrew advises that we first have to identify our pain points and investigate the problems, or problem areas that need to be solved. Then we have to decide which approach to take to get started. He explains the difference between an iterative or wholesale approach, laying out the pros and cons of both, and the importance of involving the entire team.
An Iterative Approach
Starting by explaining the iterative approach first, he stresses again how important it is to get started and continuously work on it with a group of people. Once you have 'found' your team, he advises to get going by conducting interface audits: like color audits, code audits and visual audits. Doing a visual audit is the best way to identify where the problems are, and to scope out the extent of the problem. How to conduct such audit is all explained in the book.
A Wholesale Approach
Next, the other approach, the wholesale approach is fully explained and compared to the other approach with pros and cons. Since this approach is more drastic, Andrew also explains how to go about planning everything, from building to launching. He helps in making tough decisions like 'hard launch or soft launch?'
Systematising the Design
Once you've decided which approach you'll follow, you read about how you can successfully set up the system library with reusable elements. This chapter shows you the do and don'ts, advises you on which tools you can use (also for tracking and organizing system tasks), talks about naming conventions, and shows us a couple of basic truly practical SASS examples.
Even though this chapter comes after talking about how you create your design system, Andrew stresses that documenting your library should be dealt with during the process of building it. While first explaining the difference between a UI kit and a style guide, you get to know what a design system is compared to a style guide and why documenting everything is needed and is an important part of it. You read why it should be part of your 'design and build' process, and why you shouldn't leave it until the end, or as an afterthought. Andrew gives us practical examples of how you can properly document your design system library, and points us to what we should definitely not forget to include.
All the different aspects and elements are covered going from color, brand identity, typography, copyrighting, components, patterns... over to what tools or apps you can use and what factors to consider when choosing it, and the nice-to-haves. It's not an easy choice to make since there are so many options and there is always the designer's versus the developer's preference, and there is the important aspect of keeping it all up-to-date. How can we do that? Which (dynamic) tools are perfect, so we can keep the library always in sync?
In this last chapter Andrew shares some inspiration for documenting design systems. It shows a curation of great examples of brand guidelines and system documentation from companies who've placed these online. Ideal to lean from and to get a little insight. Some of the (many) examples are static design-oriented, and others are 'living' style guides and are set up in a more interactive dynamic way. Andrew gives you a whole range of real world examples where he analyses their strengths. By going into detail in each one of them he points us to some useful possibilities and best practices.
Brand Foudations help to keep everyone on the same page, speaking the same language, and working as a team — rather than a collection of individuals doing their own thing.
Maintaining a Design System
Maybe this is the most difficult, and also maybe the most vital part. Keeping things constantly in sync is challenging. Andrew stresses on the importance of having a shared library of assets and shares his experience of how you can set up a shared library in Sketch, using Sketch Library. Not being a Sketch user myself, I see that it's actually very similar to what you can do with Adobe XD using Components and other assets like colors and typography, which can be shared and synced. You could also work with a CC Library if needed so certain design elements (colors and graphics) can be dragged into any other Adobe application. Andrew also points out that keeping things up-to-date and keeping design and code in sync is vital and should always be part of the ongoing process.
Since this book is design-focussed, how to set up a dynamic system (living style guide) that pulls-in code from production or documentation that is generated directly from the code, is not part of the book. However, Andrew sheds some light into bridging the gap between designers and developers, sharing some real world examples of how Airbnb and GitHub approach this. Lots of tips & advice is shared in this chapter such as keeping a changelog of the updates and much more. Lastly Andrew shares some different strategies for establishing a design system leadership for making sure the design system is properly adopted and maintained.
After having read this book, I'm convinced that this is a must read for everyone who wants to get started with building a design system. Keeping in mind all the factors you have to consider, this is such big endeavor that any guidance in how to approach this and how to get started is welcome. This book is just perfect in this respect. It'll help you in getting a clear view in how to start, which direction to go, to which tool to use to set things up, and keep it maintained and in sync with the whole team. But it also goes beyond that as Andrew talks a lot about how you can work together as a whole team, each member with their area of expertise, designers, developers etc. on how to create the best experiences. Plus, the book is written in such a way that you don't feel like an idiot because you don't know the buzz words or typical jargon. I highly encourage and recommend you to buy this book if you are at a point of starting to build a design system. I'm sure it will inspire & empower you.