Growing a Design System
Ready to grow a design system but you have no idea where or how to start? I want to help you learn from my mistakes so you can make something that goes beyond your internal design team.
When I joined the Zendesk Creative team in 2014, my colleagues were intrigued and perplexed about what to do with an engineering nerd like me. I poked around for a juicy problem to solve. The design team had a growing library of patterns and as I started to wonder about canonizing those as working bits of code, I knew we could be on to something: a system that could be used by developers to achieve intended designs with pixel perfection. I got to work.
It turns out the industry was getting to work as well. Google’s Material Design debuted and by the time large players like AirBnb, IBM, and Uber jumped on board – we collectively understood the movement to be encapsulated by the term “design system.”
A design system is a collection of reusable components, guided by clear standards, that can be assembled to build any number of applications. This helps organizations scale design and development with speed and consistency. In other words, we built the bits of Zendesk UI (buttons, tabs, menus, form elements) and help you choose when and how to use them.
And thus, Zendesk Garden was born (Zendesk Garden, zen garden, a garden of component zen, … get it? We think it’s clever).
Four years in the making, Zendesk Garden is now open source and I couldn’t be happier with the result. We packed our components with support for keyboard navigation, screen reader support, and right-to-left layouts. The same elements used by our internal teams to build product are available to the world.
However, we’ve done something a bit unique with Garden that makes us so excited to share it and eager to see what happens. We built our components so that the visual styling can be separated from complex behaviors—meaning you can leverage Garden for your own design system.
We didn’t arrive here in one go. Growing Garden happened as a series of fits and starts, and I learned a thing or two along the way.
We were ready to make Garden grow.
Embrace setbacks to make the system stronger
Garden was initiated during a time of hyper growth for Zendesk. This meant new faces on the team every month, new customers, and daunting things like an intense “tech review” process in order to legitimize any broad-sweeping technologies. This rigorous process helped to expose a major issue: Garden’s technical approach was diverging from Zendesk’s global frontend development architecture. Our design system was providing a gift that wasn’t giving.
We needed to pivot and dedicate efforts to build Garden via React – a JS framework ripping through Zendesk as the go-to for frontend development. Garden was set to grow on React without bounds, but our expectations were not reality.
We bundled all React components under a monolithic package. This meant that one patch to buttons could end up requiring major breaking version updates to other components (i.e. tables). Our development teams couldn’t stay up to date without making a serious time investment in Garden. Exactly not the goal of a good design system.
Today, each React component is published as a micro-package and depends on modular CSS (also bundled as micro-packages).
When building something great, it can take a long time to land on a suitable solution. Even though in retrospect it seems so obvious, let go of hindsight and welcome these mishaps. They get you to where you need to be.
Priority projects need to pass the bus test
In the evolution of Garden, I was operating solo – a lonely Garden team of one. As an engineer, I was working to codify the work already being done and shared by our product designers, focusing on user needs and experience, while asking for help with the flashier, visual aspects of design. We waited too long to staff the core team. The wakeup call came in the form of an engineering VP who commented, “Garden doesn’t pass the bus test. If JZ gets hit by a bus, the Garden dies.” Good point (also, I die, but whatever).
We needed Garden to survive those buses. Filling out a multi-functional team of designers and developers was an incredibly rewarding experience. While organizing the team under Zendesk’s Creative umbrella has its challenges, it affords us premium emphasis on design, design thinking, and deeper empathy with the end user. These are the essential qualities that inform the work we do – from sketches to pixels to code.
Garden was ready to grow everywhere.
Make it useful for others
About a year ago, I had a conversation about design systems with Zendesk’s chief creative officer Toke Nygaard. He wondered why the tech industry wouldn’t open common component assets that could be reused in a more generic fashion. At the time, I wasn’t convinced this was an interesting possibility.
The design systems I’d seen tended to be highly personalized – from visual styling to behavioral implementations, all the way through to end user rollout. When I attended a design systems presentation or conference, I walked away with, “wow, they built a beautiful thing – I wish we could have something like that.” But it wasn’t for me. It didn’t fit our branding or aesthetic and I couldn’t use it.
That’s why Toke’s comment stuck with me. When Garden was re-architected to leverage the Container pattern (via React’s render prop technique), I realized the notion around sharing was now a reality. True to Zendesk’s culture of taking on the burden of complexity to make things simple and accessible for other people, we had landed on an approach to design systems that isn’t just for us.
Zendesk team:garden is just getting started. We have a lot of work to do – more components to build and improved guidance around component usage. But I feel lucky to be working with a team like this. Join us on our journey with growing Garden. Be bold and get your hands in Garden dirt. Use it however you like, because now it’s everyone’s Garden.
