Design Systems with Brad Frost (Amsterdam)
A trip report
On June 20th, I visited the workshop Design Systems with Brad Frost in the lovely Hermitage in Amsterdam. Here are my impressions.
Design Systems have become all the rage of late. Are they a new thing? Oftentimes great design manuals of the past like the 1970 New York City Transit Authority Graphics Standards Manual by Massimo Vignelli and Bob Noorda (recently re-issued on Kickstarter) are held up as proof that nothing is new. If you go by the following definition: “A design system is the story of how your organization designs and builds digital products” you can sense the distinction digital brings to forth. Which is not to say a design system can’t encompass offline guidelines. Design systems are – however – usually driven by digital and with a significant UX underpinning.
As digital transformation sets in more and more and almost all companies shift all their services to digital we have also seen the number of digital touchpoints increase and seemingly in an accelerating way. Without a thorough orchestration these has led to large inconsistencies between consumer-facing applications and accrued design and development debt. The public outing of some of the better known design systems seems to have spurred the interest by other enterprises to follow the ‘paved road’. Expecting a cake walk – however – would be sincerely underestimating this new endeavour.
InVision is renowned for their digital product design platform used by a fair number of – especially large – companies with a stake in digital products and services. According to their own account, they aim to empower teams to create the world’s best digital experiences. Part of that is taking up a serious role in the design community. Their subsidiary DesignBetter.Co fronted by Aaron Walter (@aarron) (from Mailchimp and emotional design fame) is stepping up to educate the industry and sharing the best practices in product design. They do so by means of books, podcasts, conversations and workshops by subject matter experts. A better expert for this workshop than Mr. Brad Frost, founder of Atomic Design would – IMHO – be hardly conceivable.
Brad Frost kicked off the workshop with a short introduction of himself, as would be expected. He then turned to the audience and asking us about our background. It turned out that a lot of the participants were from outside the Netherlands (countries like Norway, Germany, the UK, France, Spain and Italy). UX and visual designers made up the majority complemented by front-end engineers, product owners, design managers and the odd back-end developer. This opened up the dialogue and would continue throughout the day; participants could ask questions and bring in challenges from their own practice. Although the performance felt more like a reading than a workshop – save for a small exercise – the continuous dialogue surely made it feel like a team effort.
The workshop followed the structure of the Atomic Design book guided by the steps to undertake the establishment of a design system:
- Kick off
- Design & Build
Brad Frost has witnessed the withering of some of his design systems and the steps provide essential parts in diminishing those odds. His first effort failed for – in hindsight – obvious reasons. He was tasked with the project of redesigning a complex website and figured that creating a design system on the fly would make that easier. Especially with future maintenance in mind. However the focus of the client was still on the redesign as a website project and the design system was left to its own devices without any updates. Once that happens the system is good as dead.
So in future efforts he made sure to reverse the scope: it was made explicit that in order to undertake the design work a design system needed to be in place in order to guarantee consistent design and building practice of the work at hand.
In the Sell section Brad Frost made the important point that we shouldn’t conceive of a design system for only of what it is (e.g. UI kits, documentation, code repositories) but also for the process that goes into creating it: how it’s made. Thus a design system consists not only of the what – the designs system as a product – but should also include the operations (e.g. planning, tooling, customer support, governance). So where do we start? We start with people. We start with communication.
Now there are a number of things one might do in order to let the right people feel the need for a design system. One can point to accrued design debt by means of a board displaying the many seemingly haphazard shapes and colors of buttons that are in existence on several of the clients digital touchpoints. Or one can point to the time it takes the different teams to deploy updates with the dependencies on other teams and the effort it takes even to re-use existing patterns. In Brad’s words: the heartache of design at scale. Our managers need to feel the pain in order to see the need for a solution that is a design system.
The Kick off can de seen as the research phase. The objective here is to align designers, developers and stakeholders alike in order to establish what the design system should do. Think user interviews and workshops.
Start with a Design Brief based on business and user needs. Establish what exactly will be included and what are the guiding principles. A mature organisation should have well-researched and actionable design principles which should guide the design system nicely. Design principles lacking? Now’s a good time to get them right.
One great principle to strive for in order to get your design system actually used: Make the best thing the easiest thing. When the design system is seen as something complicated or something extra, people will gravitate to what they already know.
Plan pilot projects for testing (parts of) the design system in development. Good candidates use many components that can be re-used elsewhere or have patterns that can be re-used in other projects. Does it have marketing potential? Also a good thing. Last but not least: is there a champion available? Someone working on the product that sees it through and might celebrate/evangelize using the design system (and even contributing back to it)?
Design & Build
Start with the foundation: the basic properties that rule all components. Think of them as design tokens. Colors are not mere colors, they inhibit a structure with rules for which shades and tints can exist. This color system needs to be adaptable and extendable. Iterations are driven by the needs found in projects. Same for your type system and spacing tokens.
Have several brands to support? Make it themeable.
Your development teams use different frameworks? That is fine, there is no need to force one ‘right way’. They should – however – all work from the same tokens, for instance as a JSON file. From there they might need to make extensions specific to their framework, but the foundation is the single source of truth.
In the launch section I found the organizational dimensions the most interesting. Brad talked about governance: roles and team structures. You have design system makers (bird eye view) and design system users (ground view). A good article on structures is Team Models for Scaling a Design System by Nathan Curtis (@nathanacurtis). Brad raised an interesting point about the capabilities of people involved in the design system. According to Brad, some people are like ‘bricks’. They fit in the right place, are very good at what they do and like clear instructions on what do. Other people are more like mortar, they connect different bricks. Obviously a strong wall needs both kinds.
For some people a technical component library in and of itself seems like a design system. While it is true a good component library forms an important part of a design system, a design system is much more. As previously stated it is as much the why and the how as it is the what. A repository with several buttons and controls lacking a clear purpose doesn’t qualify as a design system by a long shot. So how do we maintain a system that is supposed to be adaptable and extensible without causing disarray?
Well, there needs to be a process in place regulating how and when a candidate component can be added to the system. A possible example of such a process is detailed in Design Systems: Why Snowflakes Are Counterintuitively Integral. Brad Frost was in awe of the accompanying flow chart.
While the usefulness of design systems for enterprises with a mature UX would seem unchallenged the becoming of a successful design system is not without struggles. While some of the participants seemed to see little extra in the workshop beyond what is already captured in the book, I found it very entertaining and enlightening in the unique angles Brad Frost would bring into the subject matter.
About the author
Nico ten Hoor (/nico-m-ten-hoor) is a visual designer with over twenty years of experience in digital design. He is attracted to the analytical side of visual design such as design language and design systems. He also takes a great interest in indie magazines and graphic novels.
Design systems (2), Events (22)