Why every UX/UI designer should attend a masterclass with Brad Frost
By: John Lee Hagen
At the Hatch Conference 2023 in Berlin, I met my idol Brad Frost for the first time. As a UX/UI designer, Brad Frost has been accompanying me for many years, teaching me a great deal about Atomic Design and Design Systems. In this blog post, I’ll introduce you to his work and share why designers should attend one of his masterclasses — and how his insights can influence our craft and the value we add to companies.
An Introduction to Atomic Design
Every UX/UI designer is familiar with this image and knows its significance. 10 years ago, Brad Frost published his book Atomic Design and introduced us designers to the functionality of pattern libraries along with the world of developers.
Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. Each of the five stages plays a key role in the hierarchy of our interface design systems. (Source: 1)
A brief overview of the Atomic Design structure and its components
The atoms of our interfaces serve as the foundational building blocks that comprise all user interfaces. These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional.
Molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule.
Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface.
Templates are page-level objects that place components into a layout and articulate the design’s underlying content structure.
Pages are specific instances of templates that show what a UI looks like with real representative content in place.
By defining a page’s skeleton we’re able to create a system that can account for a variety of dynamic content, all while providing needed guardrails for the types of content that populate certain design patterns. (Source: 1)
Despite being well-versed in pattern libraries from my computer science studies, I was still oblivious to pattern libraries that are crucial to UX/UI design. I learned about these from Brad Frost, who broke them down and visualized this complex topic clearly and transparently. He also elaborated on other important aspects relevant to UX design and interfaces and integrated them into the mental model, the Ecosystem.
Building up from molecules to more elaborate organisms provides designers and developers with an important sense of context. Organisms demonstrate those smaller, simpler components in action and serve as distinct patterns that can be used again and again. (Source: 1)
Patterns to underpin consistency within a system are hugely important. Without patterns, the consistent use of organisms or even templates is not clearly given and the system collapses. How does a search box behave? How does this template stack up?
Without the definition of patterns within the design system, the components look the same on every page, but the functionality, behavior, and scalability do not.
Hatch Conference: Design System Masterclass
A Masterclass with Brad Frost and a deep dive into the Atomic Design theme to become a Design System Master.
Since the Hatch Conference fixates solely on the participation of senior designers, I expected the speakers to cover complex topics and a deeper dive into pitfalls, mistakes, and lessons learned within the discipline.
The masterclass, however, focused more on the topics described in the book and on Brad’s blog without the inclusion of any deep impressions or pitfalls.
Nonetheless, it was a perfect summary of a design system in the complete framework, which covered some important topics like:
- How do I sell a design system?
- What are the components?
- How do I govern a design system?
- How do I maintain a design system?
Even though I was informed about most of the topics discussed within the Masterclass, certain points resurfaced and grasped my attention, which compelled me to revisit them.
One of the most important ones being an additional sub-level of atoms: design tokens. Despite being a prominent topic within pattern libraries, Frost’s presentation, as well as his knowledge in the field of development, highlights the application in the design system ecosystem.
With the introduction of variables in Figma (Source: 2) and several plugins — such as Tokens Studio (Source: 3) — as well as the almost indispensable use of Dark Mode in today’s world, the application of design tokens and abstraction in themes has become vital.
Brad showed the interplay of design tokens in design and development, along with the pros and cons of plugins, and connected this to his past experiences. These impressions were an absolute added value of the Masterclass.
Another key aspect of the Masterclass was recipes as well as smart components, which Brad placed in the components section. Both are part of the Design System Ecosystem:
While this depiction is true, it ignores the complexities many organizations wrestle with day in and day out. Over the years, the digital product landscape has become vastly more complex, the responsibilities of design systems have grown substantially, tooling has evolved and matured, and processes & organizational structures for managing digital products have grown up. (Source: 4)
To be and remain scalable in today’s world, design systems must also scale. The core design system as a base can also be sufficient. Other topics were marked as optional and not part of the base:
Core design system layer — which contains the common, organization-wide UI building blocks for both design and development.
Optional technology-specific layer — which contains framework-specific and native implementations of those common UI components.
Optional recipe layer — which contains composed UI components to be used consistently across specific contexts (like a product or product family), but aren’t reusable across the entire organization.
Optional smart components layer — which contains UI components wrapped in logic, functionality, or other smarts to make the integration of common components and services easier for product developers.
Product layer — the actual websites and apps that we ship to customers (aka the whole reason we’re doing all of this!) (Source: 4)
In development, the goal is always to work as little as possible, repetitively, and as granularly as possible. Structure is the way to go. In design, this approach is not yet fully known. Let’s compare Adobe XD, a tool where we have a single page per project to map all areas of a project.
The masterclass was insightful in this area because Brad connected and linked the different topics of his book and even his blog.
The connection of the design system ecosystem with the world of developers and the question of when to create a component — When is something a design system component, a recipe, or a snowflake?
Brad splendidly sums up these topics with this sentence:
In my view, this is really cool: we separate out where things live to provide some clarity for what belongs to the honest-to-goodness, publishable design system component library, and what belongs to the product. (Source: 6)
The flexibility within the projects and consistency within the core design system in one ecosystem is made graspable by Brad, along with some tools and examples provided by him.
Design library — Figma team library or similar
Design file — Figma project file or similar
Code repository — the source code home — GitHub or similar
Front-end workshop — a tool like Storybook to build, view, test, review, and document coded UI components
Code package — a code library packaged up and published (on npm or similar) in order to be consumed as a dependency by other applications.
Reference website — Zeroheight or similar (Source: 4)
The last topic that stuck in my mind and surprised me is the topic of governance and how to keep a Design System intact and well-managed over time. Determine whether a component fits into the core, recipe, or is a snowflake, or even if it should be a part of any of it. But as we all know, a Design System is never done and we continuously iterate on it. Therefore, you can’t just say “Set it and forget it”.
Design Systems are built (quite) fast and are then ready to use but over time different projects, products, and requirements influence the structure and the Design System.
This leads to a problem since there are two types of Design System participants: the Design System Makers and the Design System Users. This brings us back to the topic of governance and how to keep the Design System Users creative as well as keep the Design System Makers not losing their minds whilst being the “Design System Police”.
Product teams’ primary concern is getting work out the door, not to uphold the integrity of the design system. Teams get creative and will find ways of getting things done, which may involve hacking styles, creating a slew of one-off components, or abandoning the design system altogether. As Jeff Goldblum quips in Jurassic Park, “Life, uh, finds a way.” (Source: 7)
I thought and talked about this topic multiple times and also saw great examples of Design System Governance, eg. from Decathlon (Source: 8), yet Brad combined the topics of Design System Ecosystem, component types, and governance, and set the frame differently.
Most examples I saw were focused on the “Police” part and the Design System Makers that forbid everything and don’t even think about detaching an instance!
However, there are also the Design System Users who are sitting in front of a blank artboard and requirement and should also be allowed to create snowflakes or their own recipes for their project.
Is Atomic Design dead?
In addition to the masterclass, Brad also held a keynote on the conference day at the HatchCon with the catchphrase title: “Is Atomic Design dead?”
After shortly going through the last ten years since his book was published and showing what was developed when, which tools were introduced or new features were added, he concluded that, obviously, Atomic Design is not dead but it has its catches.
He also showed some examples of how enterprises benefitted from their Design Systems:
- Lloyds Bank’s design system saves around £190,000 per project and has helped save an estimated £12.7mil over two years.
- Westpac’s design system increased user interface design velocity by 100%, and reduced production effort by 1,600%.
In the keynote, Brad mentioned that every one of us has built his 25. accordion doing the same as every other accordion existing to date and we should think about a Global Design System.
This leads me to the catchphrases mentioned earlier as well as the insights I gained during my studies in development: Do not be repetitive in your work. Everything that is repetitive can be automated in some way.
Every company has its own Design System, every designer at the HatchCon has at least built one Design System or was a part of it.
But what about having a Global Design System that can be used by anyone and can be themed to the desired purpose?
At first, I thought we already had this — you also showed it at the beginning of your keynote Brad: Google Material, Bootstrap, AntDesign.
But there is a huge difference between a “vanilla” Design System like basic <html> tags that create a rough base and a Material Input with a “funny” floating label as Brad mentioned in his masterclass, referred to as Web Components:
Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilize them in your web apps. (Source: 9)
What really surprised me was a topic that is often being ignored or not integrated properly: accessibility.
Brad showed the idea of a Global (vanilla) Design System in combination with W3C.
The World Wide Web Consortium is the committee for standardizing techniques on the World Wide Web. (Source: 10)
Which leads us to what Brad also shared within the masterclass:
Instead of delving into the boring parts, designers have the opportunity to focus on topics they may not have had time for before. Two topics that I believe are important but have been overlooked by myself are sustainability and inclusivity. These topics were brought to my attention during the HatchCon.
At a roundtable session hosted by Thorsten Jonas from Sustainable UX Network, we discussed how to shift our design paradigm from user-centered to environmental and humanity-centered. This shift is important because it allows designers to consider the impact that their designs have on the environment and on the people who use them.
In another keynote, Luke Murphy from ZeroHeight spoke about systems of exclusion and the ways in which our designs can create discriminatory spaces. He urged designers to look at their work through different lenses to ensure that they are not contributing to negative aspects of our world unintentionally.
Summing it all up
The Hatch Conference was a great experience to learn, be aware of what’s happening around you, and for networking. The masterclass with Brad Frost was a win from the beginning. Meeting my idol was as awesome as I imagined it, but what I found even more impressive was how he connected all the different aspects of his work to present a bigger picture. I would gladly join another masterclass hosted by him.
His keynote highlight on the past and emphasis on what could or should be the next step completed the whole circle of the Design System Ecosystem.
To date, I have built 3 Design Systems on my own using 3 different tools (Sketch, Adobe XD, and Figma), with the help of third-party Design System Kits from Google Material 2&3, Bootstrap, and AntDesign.
As attested by Brad, it is crucial to be vanilla and focus on more interesting tasks instead of building an accordion or checking the size of a button. I have dealt with the same issues in my 6 years of working with Design Systems. I have either built them from scratch or wasn’t provided enough time and budget to include important topics like accessibility. This led to the same loop of boring tasks or theming the sh*t out of a third-party Design System Kit that ended up looking similar to every other website today. You can compare it to everyone owning the same Ikea furniture (No offense, Bilgi Karan, I loved your sessions at the HatchCon).
To sum things up, I’d like to quote Brad:
Here’s the fun part: you can craft all of these layers and assets and the whole thing can still fall to pieces. Design systems are less about assets and their relationships to one another, but more about people and their relationships to one another. (Source: 4)
Read more about the business benefits and the hidden ROI of design systems here.
References & Sources
1: Brad Frost, https://atomicdesign.bradfrost.com/chapter-2/
2: Figma, https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma
3: Tokens Studio, https://tokens.studio/
4: Brad Frost, https://bradfrost.com/blog/post/the-design-system-ecosystem/
5: Dev.to, https://dev.to/larswaechter/how-i-structure-my-react-projects-jii
6: Brad Frost, https://bradfrost.com/blog/post/design-system-components-recipes-and-snowflakes/
7: Brad Frost, https://bradfrost.com/blog/post/a-design-system-governance-process/
8: Decathlon, https://www.decathlon.design/726f8c765/p/195920-contributing/b/04a4ff
9: Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/Web_components
10: W3C, https://www.w3.org/
