How Zendesk planted the Garden design system

This post is based on a conversation between Allison Shaw, Senior Manager, Design Systems at Zendesk and Andrea Burton, Design Advocate at Abstract, about Zendesk’s Garden design system. Watch the video recording and check out the public Collection from the presentation. ‍

At Zendesk, Allison’s team is working to make the Garden design system, a best-in-class product that powers their application suite and serves as an open-source accessible foundation for outside organizations.

How did you get into the design system world? 

Back in 2013, I was working at Yelp. I was in the middle of redesigning the business page on the web property, which everyone knows when you go to Yelp, you go to a business page. As part of that redesign, we were introducing a whole new visual language. But the Yelp design team at the time was just me and one other person, so we really weren't able to scale up ourselves in order to help everybody get this really vibrant new visual language into the work that they were doing.

I was looking for ways to help the organization get to this new place faster so I sat down with one of my front-end engineers, Molly. We just went for it and over a week-long hack period, we came out with one of the first really modern design systems. It not only had design assets, but also code assets that any front-end developer at the company could place into the work that they were doing. That was the beginning of that for me.

What was your path to Zendesk?

After Yelp, I worked on the growth team at Twitter and on Thumbtack’s customer-facing application. At the time that I was getting ready to move on from Thumbtack, I asked myself, "When did I have the most fun in my career and where would I be able to add the most value in an organization?" I thought back to the time when I was working on what we called Yelp's style guide. At that point, we didn't yet have the language of design systems.

I started to look for jobs that focused on design systems and Zendesk was hiring. I knew a couple of folks who worked there and really loved the culture and loved the people that they were working with, so I went in for the interview and the rest is history. I've been focused on design systems for the entire three years that I've been at Zendesk.‍

What’s the story behind Zendesk’s Garden design system?

When I came to Zendesk, I was hired by and was working with Jonathan Zempel — the originator of Garden at Zendesk. He's an engineer who through an acquisition ended up on the creative team at Zendesk. The genesis of Garden is that as he was looking around for places that he could make a real impact at the company when he joined. He saw a lot of inconsistencies on the product in production, but also in the assets that the designers were creating. He felt that he could make an impact and really help the team through the creation of a codebase and some assets that were uniform and that could be reused all over the product suite.

He started the project in 2015 and I joined in mid-2017, so he had been working on it for about three years at that point. Over that time, he had worked with designers on the team who were interested in doing this work, but they weren't fully resourced to it. I was the first full-time hire.

Making sure that we have both design and engineering representatives at all times has helped the design system grow organically and also best positioned to help the rest of the organization as they start their adoption.‍

As with any good design system, it's not really a true design system unless there's that code aspect of it, right? It's one thing to be able to create a library for designers, but it's quite another for an entire product organization to be able to use the same language and the same assets as everyone else.‍

What does your design systems team look like?

We have both designers and developers on the Garden team. Organizationally, the designers report through design and the engineers report through engineering. But back in the old world where you could be in an office, we all sat together. 

Zendesk has been really strategic in their investment in the design systems team. Making sure that we have both design and engineering representatives at all times has helped the design system grow organically and also best positioned to help the rest of the organization as they start their adoption.‍

Let's walk through the Garden within Abstract Branches

We make good use of Abstract's organization features like projects, sections, and also starred projects and sections. Here’s a description of our projects. 

The primary project that we have for Garden is the Garden libraries project. We also have the Garden libraries contrib project, which is where people from the design organization at Zendesk can offer contributions to Garden. We created this project as a dedicated space for them to be able to work.

The next important one to mention is the Garden patterns project. If you think about a design system in the atomic way, atoms are your individual components and live in the Garden libraries project. The Garden patterns are more complex organisms,  your molecules and actual organisms. That's where things like page layouts or things that are meant to encompass a full interaction pattern live. A great example of this is our severe destructive modal pattern. If someone needs to delete something and the consequence of that action is very high, then we put our user through a modal flow that has them spell out and recognize that what they're doing could have severe effects. We have each step of that flow in a file.



We also have a Garden website project and a Site Documentation project, where all of our assets and work that we're doing on that site live. And we have a mobile libraries project, which is maintained by our mobile team. And finally, we have a product illustrations library project.

How does your team work within a project? Show us the Garden libraries project in Abstract Branches

One of the first things that I always like to point people to when I'm introducing them to Garden is our About section. This is an area for us to communicate what the project is about to the rest of the design organization. We add any relevant links that people may want to reference, links to our documentation, and links to our JIRA.

We also have a README that talks about how our master files reflect what is live on production/available to developers. This reflects that definition of a true design system and the reason why we ensure that our Sketch libraries match our developer codebases. If a designer uses something, they can actually know, without a shadow of a doubt, that it will be available to them as they start to go into the building phases.

Additionally, we have a little emoji key that we use. We use emojis on every branch, so it makes searching a little bit easier. These are custom to us, but they serve as a good little reference point and just a quick check of like, "Okay, what exactly am I doing? What's the scope of what I'm doing?"

‍

Let's talk about naming conventions

When you look in the Garden library project, you can see we have quite a number of library files. We go through and ensure that what we're calling the design assets mirrors precisely what the developers would see in code. That's to reinforce that shared language for the product development team.

Show us how you set up foundational elements and files

Colors

We make heavy use of Sketch’s override capabilities. When you look at the colors file, each of the swatches is a layer style. They represent statefulness, different color options that are available, and they are fully integrated into the rest of our symbols as layer styles. The reason for this is that in the inevitable event of a redesign, it's going to be a lot easier for us to make global changes to the rest of our library.

As you saw earlier, we have about 20 different library files. It would be tedious to go into all of them and individually update everything and it's a recipe for human error. This also allows us to simplify and to see everything in one place and make sure that everything is looking and feeling uniform.

Does Zendesk use color names or design tokens?

On the code side, the Garden design system utilizes theming to make sure that everything is staying uniform. We do have some theming names available but the designer communication does tend to fall around the colors themselves. Our color system is really thoughtful but we have eight shades per color, so 100 through 800. We did that so that it mirrors the same way that CSS manages font weights — the darker the color, the higher the number. This color system has a lot of accessibility features built into it. Anything over 600 is guaranteed to meet a AA rating. Anything in the 800 range will meet a AAA rating. And if you put a 600 on top of a 100, that's also guaranteed to meet the accessibility constraints for AA.

Type

Similar to our color files, here’s how our typography files are set up. We have a lot of different base type styles. We also show how we represent our main color usage. Generally in typography, we're using default grays for most text, blue is for links and interactive elements, and we have some validation colors.

We've created custom and specific type styles to support particular kinds of elements, including monospace treatments, tags and badges, pagination, and  even some of the datepickers. The datepickers are using centered typography, which is not our typical and on our default, so we've created specific type styles that support each of those different components. This is to help us in the event that we ever need to make an update. We can just go through and update these, rather than having to go in individually and change everything.

Type styles applied in components

This is a good visual of how we bring in those colors and those type styles into an actual component. In this example, I've clicked on a field label and you can see over in the panel that the type has taken on that default bold style.

If someone were interested in changing that label to maybe default without bold or if they needed to customize it in some other way, they can get to those type styles from this menu.

In practice, when we distribute the system and people are going to be using a text input, we restrict some of the overrides. The systems team makes a huge use of overrides, but we only allow our designers to customize the things that they can easily customize in code. If they need to change the type style, that would be a customization of our code component and we don't allow it to happen in our default symbols. If they need to do that, they'll have to break the symbol and that is a signal to them that they are actually going off recipe.

How do we get people to not detach from symbol?

For me, the answer is to make a system that has the flexibility built in. Not just that it has the flexibility, but also that it also covers as many use cases as possible. That's why building a design system and building a UI actually takes a bit longer than maybe your typical product development cycle. When you're designing a system for as many products as Zendesk Garden supports (we have eight), we have to be very diligent in making sure that our audit is complete, that we're talking with all of the right people, and covering as many of our bases as possible.

A design system is never meant to build 100% of the user interface. There will always be places where it doesn't make sense to apply the system. That makes creating systems a real balancing act. It requires a lot of restraint because a systems designer wants the system to work for everything. But you have to be realistic about it.

We really like to make things as easy as possible for our designers. We don't have a single input symbol to rule them all. You could easily create one button symbol and have everyone adjust the overrides to make what they need. But in the end, that's not easy for designers to remember. It's not a great user experience as a designer to have to do that every time they place a button. 

The design systems team does the work of saying, "Okay, what are the most common variations that we need to support here?” Then, build symbols for each of those things. We also name things in a predictable way, so that the designers can find what they need quickly. We use Sketch Runner to aid in that process.

Tell us about unit tests for a design system

A unit test is a test that you run automatically, every time you make any changes to your code to validate against whatever you want to test for. We’re borrowing this terminology from the development world and applying it to design systems. In the example below, the file contains every single symbol in our Sketch library and we place it into a different file so that we can verify as we're working.

It checks for things like:

• Is the naming correct?
• Is the resizing correct?
• Have I completed all of the variations that I need to complete based on what I'm seeing from the other symbols and the family that I'm working on?
• Does the new smart layout feature work as expected?

It helps us catch a lot of tiny bugs or things that are really easy to miss. This prevents us from having to go through a branching and approvals process for something small. Catching these things in flight with the unit test is the best way for us to ensure that we are delivering on our quality promise right away.

How do you manage governance for the Zendesk Garden?

On the Garden team, we have a really special and unique working relationship with the rest of the company. Because we're supporting all of the different products, we have relationships across our entire global product development organization. We hear about requests in a variety of different ways. Sometimes, through design critiques, sometimes through Slack. We have a number of Slack channels where developers and designers can ask us questions and surface needs.

We also have Garden Syncs, which are regular meetings that the Garden team holds with the design and engineering teams in every office. We have eight international product development offices around the world. We meet with them on a regular basis and that's how we can learn about the things that we need to build.

Once a designer or an engineer surfaces a need, we go ahead and start to assess the effort and priority of that potential new thing. We use t-shirt sizing (small, medium and large). In this table, you can see a small communicates, "Hey, something's not working the way that I expected it to, is it correct?" Maybe there's an accessibility bug we need to look at, or a new icon. Medium tends to be “This pattern works for me most of the way, but I need it to hit a specific use case.” Large tends to be a net new component, something that we don't have at all in the Garden ecosystem yet.

At the bottom of this table, you’ll see the review and deployment process. Auditing does tend to happen at the beginning, but it's a continual process of showing the work to the rest of the organization and asking, “Does this fit into any of your flows that you need?” Validation and testing all happens toward the end of the process, but it's best to do that in a continual way. You don't want to design something and have this beautiful thing, and then realize you can't get it through the door.‍

How do you track activities related to your design system? Do you use a ticketing system in combination with Abstract Branches?

Yes, we base all of our project work in JIRA. We have a product manager who helps us prioritize and make sure that we're aligning the work that we're doing with the rest of the organizational priorities. The rest of the engineering organization is on JIRA, and so are we.‍

What metrics, do you have any way of measuring so that you understand your work is being used, it's effective?

Metrics are something that we care about and we have mechanisms in place in our code components to understand when and how they're being used. Design systems are notoriously difficult to track in terms of usage because a product is huge. In our design system, we only create react components right now. So we can only track the areas of the product that are in react. It's a little bit of a challenge, but it is something that we care about and it's something that we're always looking to improve as well.‍

Do you have an accessibility person or team that sits on your team or do they come in as a consultant?

I represent the design expertise on accessibility for the team. We have a number of folks who are training themselves up and really digging into learning about it as well. Accessibility is an area that Zendesk is really focused on improving right now, so we have a number of ways that we're going about that.‍

What do you use to publish your design system? And how do you push it out to the devs? Do you use a website or react based website?

We publish all of our engineering information and documentation at garden.zendesk.com. We are open-source, so anyone who wants to contribute or fork us can do that on GitHub. But in terms of how a developer actually gets their stuff into their codebase, all of our open-source repos are up on NPM. And that's really the primary method for deployment.‍

What are some challenges you're facing at Zendesk around design systems?

I don't know that we have anything that's particularly unique in terms of design system challenges. The scale of our system and the scale of the products that we support certainly does present an interesting challenge for us. We have a large number of products and building something that every product could use and find useful is always a challenge. ‍

Are you using the same code based components for all of those eight projects?

There's a universal visual appearance, which is probably a lucky thing for us, but we do support the customization of things through our theming. So if they need to make a change they can.

Design systems challenges are always interesting for engineering because products come into being at different points in time. They ask the questions:

• Are the frameworks the same? 
• Is the development language the same? 
• Are their bundle size requirements? 
• If this is going to be something that a customer puts on their page and they need to have it be very small. Does Garden fit into that equation? 

These are all challenges we do have to think about.‍

How do you deal with one-off solutions or designs? 

Generally speaking, we won't bring anything into Garden unless it can be immediately useful in at least two of Zendesk products. We tend to not want to bog down our system with things that may only work for one of the products because again, we're building this as a universal starting point for everybody else.‍

How do you onboard new designers to the Zendesk design team? 

The Garden Syncs are really important for this and help new designers start to have a personal relationship with the Garden team so they feel comfortable asking questions. Anyone who starts on the design team gets an onboarding buddy. Those folks are all really familiar with Zendesk and with Garden and so there's a lot of person-to-person learning. We also have a one-on-one presentation that we give every couple of months as well.

How do you communicate to your stakeholders and the rest of the business about changes or updates to the system?

This is definitely an area for us that's evolving. Zendesk's product development org has grown significantly in the last few years, so communication challenges have changed over time. All new work that comes out is updated on the Garden website and the Garden Syncs are where the designers learn about things that are happening. We also broadcast our change log and new releases in our Slack channels. Back in the old world, we used to travel to our international offices once a year to spend time with the product development teams so we could do user research, ask about problems they’re encountering, find out what they need the most help with, and how we can provide value. We're always looking for ways to tighten those feedback loops, but especially now.‍