Book Notes - Design That Scales
06 Feb 2024I’ve followed Dan Mall’s work for a long time and I’ve enjoyed watching him share and teach what he’s learned about design systems. When I saw he was working on a book, I knew it would be filled with super smart guidance for design systems teams. If you haven’t already, go add Design That Scales to your cart right away. It’s 5 stars, two thumbs up, a must read. Anyone curious about Design Systems all the way to experts with lots of experience will enjoy this book. It’s a great overview of how a design system is built but it also gets into practical methods for team structures, workflows, and measurement that can help you refine your design system (DS) practice.
Highlights
Starting with product
Page 47 - Dan emphasizes the design system pilot strategy which uses a simple cycle of taking a product design, or concept and using that to extract components, then you use that draft system and apply it to more products. This becomes a flywheel where product designers produce experiences and the DS team extracts component back to the system over and over.
I’ve seen this process work much better than trying to create a system on an abstract level without clear product influence. A common shortcut for teams looking to get fast results is to use a generic or open source design system which are meant to kickstart your efforts, but those will be unable to address your particular product needs. At the start of a companies’ design system journey its better to have fewer, more tailored components than a more robust, but generic ones. Start small and make it fit your products specific needs. This will lead to greater adoption by product teams than something off the shelf that doesn’t fit your needs.
Contribution myth
Page 104 - Dan breaks down who does what with a key point: don’t expect product teams to do the contribution work, the systems team should do it for them. This bursts a bubble that many DS teams have. In their ideal world the product teams would contribute new patterns to the system and the DS team would focus on approving and maintaining things. But thats not the product team’s goal or their skillset, that is the DS team’s mission.
Flow week, system week
Page 105 - In context of a design system pilot Dan describes a cycle of flow weeks and system weeks. In flow weeks the product teams are solving user needs, while the design system team is supporting them with existing components, patterns, or proposing iterations to facilitate their work. The system week is when they take a break from support and they review new component proposals from the flow weeks, abstract the design and code to be reusable, and write documentation and specs and share with their wider user base.
This is an interesting structure that I haven’t seen practiced like this, but I like the clarity of the two different modes. I’ve had dedicated system time where we are in focus mode but not with a regular schedule. The predictable rotation could help better set expectations with collaborators.
What is canon?
All great books need a Star Wars reference :)
Page 110 - Star Wars has a set of immovable objects (characters, storylines, history) that everything must align to, like the first six films. Many of the alternate or offshoot stories and characters are considered part of an expanded universe which has much more flexibility and creativity. Dan says a design system is like Star Wars canon. The system contains all the official components, patterns, and processes that all teams should align to. Then the expanded universe is anything around and outside the system like product specific components, product flow templates, conceptual explorations. These parts may later become part of the canon or could remain in the expanded universe, depending on how your contribution workflows are setup.
Connections
Page 139 - As Dan described building a full service design system team this quote stood out: “Growing too fast or too slow puts this team out of sync with the rest of the organization, and thats the kiss of death for the design system teams. The more connected the DS team is to the rest of the org the more successful and serving it can be.”
Ive seen this first hand, when the DS team has a healthy relationship to product teams its more successful. Managing those connections across your org is so important. The DS team should have ambassadors (spies?) embedded across the various parts of your org so they know where the system continue to adapt and evolve to meet product and user needs.
Conclusion
After going through the important strategy and processes, I love that Dan pulls it back to the human side of our work.
Page 207 - “True collaboration takes the most advantage of the promises of great design system. You can serve people well if you understand what drives them”
Page 208 - “As designers, engineers, and product people—and especially if you’re a manager or a leader-your primary job isn’t to increase efficiency and drive innovative results. It’s to take care of the people you work with. Help them. Protect them. Make their work easy. Inspire them.”
Thats what keeps me engaged in design systems. Yes they exist to benefit a business, but the focus should be less about the product and more about serving the people of your organization. Efficiency, are great outputs but I like to think these are just to make people’s everyday work lives a little better.
—
Find more of my thoughts on DS collaboration over here: Fostering Collaboration in Design Systems