So you want to grow a design system
Originally published by UX Booth
So, you want to grow a design system but you have no idea where or how to start? Looking to learn from my mistakes? Or for inspiration on how to make something that has legs beyond your internal design team? Come along as I share our journey with you.
In the beginning…
When I joined the Zendesk Creative team in 2014, my colleagues were somewhat intrigued and perplexed about what to do with an engineering nerd like me. I poked around for a juicy problem to solve. We noticed the design team had a growing library of patterns. As I started to wonder about canonizing those as working bits of code, I knew we could be on to something awesome: a system that could be used by developers to achieve intended designs with pixel perfection. I set to work.
It turns out the industry was setting 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.”
What’s a design system anyway?
If you are unfamiliar with the term, 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. I like to say, we build the bits and bobs of Zendesk UI (buttons, tabs, menus, form elements) and then help you choose when to use a bit and how to use a bob.
And thus, among the primordial soup of design systems, 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’ve packed our components with support for keyboard navigation, screen reader accessibility, and right-to-left layouts. The same bits and bobs used by our internal teams to build product are available to the world.
But here’s where it gets interesting: we built our components so that the visual style is separate from complex behaviors — meaning you can leverage Garden for your own design system. Using Garden as your foundation, you can apply your own personal styling and get all that behavioral goodness (keyboard navigation, WCAG AA assistive technologies, and RTL layouts) for free!
We definitely 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.
Embrace the setbacks: they make your system stronger
I had the pleasure of initiating Garden during a time of hyper growth for Zendesk. This meant exciting things like new faces on the team every month, cool 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 front-end development architecture. Our design system was providing a gift that wasn’t giving.
So, we pivoted and dedicated efforts to build Garden via React — a hot JS framework ripping through Zendesk as the go-to for frontend development. Now Garden was set to grow on React without bounds! (Not.)
We ended up bundling 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.
That leads us to where we are today — each React component is published as a micro-package and depends on modular CSS (also bundled as micro-packages). Happiness.
My point is that when you’re building something great, sometimes it takes a long time to land on the ideal 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 should always 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. I focused on user needs and experience, while asking for help with the more flashy, visual aspects of design. I won’t expose the dates for when we got around to staffing the core team; we waited way too long. The wake up call came in the form of an engineering VP who commented that “Garden doesn’t pass the bus test. If JZ gets hit by a bus, the Garden dies.” Good point. (Let’s just ignore the fact that I would also be dead in this scenario.)
We set about getting Garden to survive those wiley buses. And filling out a multi-functional team of designers and developers has been an incredibly rewarding experience. While organizing that team under Zendesk’s Creative umbrella has its challenges, I believe it affords us premium emphasis on design, D-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.
Make it useful for other people
About a year ago, I was having a conversation with Zendesk’s chief creative officer, Toke Nygaard, around the topic of design systems. He wondered why the tech industry wouldn’t open common component assets that could be reused in a more generic fashion. Back then, I wasn’t convinced this was an interesting possibility.
The design systems I knew of were always highly personalized — from visual styling and behavioral implementations, all the way through to end user rollout. Usually, when I attended someone’s design systems presentation or conference, I’d walk away with one thought: “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. And 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 wasn’t just for us anymore — it’s for you, too. And isn’t it just better that way?
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’m super lucky to be working with a team like the one I have.
Check us out at garden.zendesk.com. 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.
