Eventbrite Design System

Creating consistency, clarity, and accessibility across platforms and brands to empower feature teams

  • Lead Designer. In addition to design, research, strategy and process creation — I helped define our product roadmap and goals, in partnership with my Product Manager and Engineering Manager.

    • Cross-functional leads

    • 4-6 engineers

    • 2 mid-senior level designers

    • 2 junior designers

Overview

After working on the re-imagining of Eventbrite’s consumer experience, I joined a team focused on empowering Event Organizers through our event management and marketing tools. I quickly realized how the disjointedness of our web product, in terms of the codebase and design patterns, was slowing me and other designers down. We all wanted things to be consistent across the board for our users, but the lack of a central authority on this meant there was no way to achieve or resolve this. As a self-proclaimed process nerd, I decided to take advantage of a company reorganization following the acquisition of Ticketfly to join the newly sanctioned Design System team on a quest to make building quickly and accessibly easier for everyone.

Getting Started

I approached getting started with our system as I would with any design problem — by trying to figure out what we knew, what we didn’t know, and what we didn’t know that we didn’t know. Most of this information could be found in one of these three places:

Our Code

As designers, we had sticker-sheets but that didn’t map 1:1 to components available in our codebase. I went through and documented all the components that were available in the code and noted their current status, including accessibility, to understand what we already had to work with. I also began grouping these into categories of like items for future navigation.

Our Users

I sent out surveys and did 1:1 interviews with other designers and front-end engineers to understand the pain points they were encountering with our existing processes and tools in their day to day and to understand what their understanding of the current system and components was.

Other Design System Teams

I had been part of the Designer Fund Bridge Fellowship program, and I utilized that network to meet with and learn from colleagues that were working on design systems in various stages of maturity. I also joined the design systems Slack community and took part in co-working days with other systems designers.

The Jump from zero to one

From the research I’d done, two clear next steps for the team emerged. To gain momentum as a team — we began addressing inconsistencies and accessibility issues in our components themselves, which were triaged and assigned amongst engineering and design.

The more glaring (and ambiguous) need was for a central source of truth and an alignment of language to create a shared understanding between design, product and engineering. Our users weren’t sure what existed in the system and a lack of shared language meant things that already existed were being rebuilt.

I took lead on this workstream with the following goals:

Create a clear central hub

We had stickersheets. We had core layout files. We even had a little documentation …but these were spread throughout Dropbox and it was clear nobody knew where to look for current information.

Create a shared language

The language designers used to describe traits or variants didn’t map to the properties engineers used. We needed a way for these languages to come together.

Make designing well accessible

Some teams didn’t have dedicated design support, so we wanted to empower product and engineering leadership to make good design decisions themselves when necessary.

I started by thinking through the information architecture of our design system to inform the UX of our design system site as I set out to solve the pain points discovered in my research. I went through several iterations based on feedback from our users and ultimately ended up using a tabbed design within each documentation page to cleanly enable all our users to access the information they need in the same location. Through testing and collaboration with engineers on my team, we were able to create an interface that allowed users to visually configure our actual components live using their React properties to enable designers and engineers to communicate using a shared language.

Filling in the blanks

As engineers began building the core of the site, I realized this documentation wasn’t going to write itself. I used this as an opportunity to continue building relationships between the design system team and other designers. We held guideline writing workshops, with snacks of course, where we’d guide designers in researching and writing best practices for common UI components.

Adoption

Having well documented components doesn’t mean much if nobody wants to use them, so we focused on creating tooling to meet our users where they are as we simultaneously designed processes to make sure we were in conversation with designers as they explored new patterns and use cases as the product grew. While some things shifted during my time there based on what else was happening in the company (we acquired Ticketfly and IPO’d!) a few tenants were clear and consistent.

Tooling needs to be robust and up to date

Due to a lack of better options, components had previously been shared through files that did not receive live updates. As design software began offering library capabilities, we moved quickly to get our resources in libraries that we could push updates to and utilize plug-ins that would make using these clearly easier and more efficient for designers. We still provided stickersheets for convenience, but these were utilizing our nested component structure.

& It should be easy to collaborate with us

While there are many reasons to love a design system, it’s easy to understand why individual designers fear additional friction in their design process as the systems team pushes towards consistency. We wanted to make it easy for designers to integrate collaborating with us into their process, so we set up weekly office hours for anyone to come in with questions about designs they were working on or about our tools or processes and advertised them with posters around the office.

…But we need to have clear protocols and processes

We wanted it to be easy, but we also needed to ensure designers knew when they needed to share with us and at what level. We created frameworks to define when and how we needed to be involved, including when we would let teams diverge and experiment with the system, along with clear ways of tagging us in from a quick Slack message to a more formal meeting.

Defining process isn’t just for users in the org

As the system and team continued to grow, we also had to reflect on our own internal processes and priorities. It’s easy for a systems team roadmap to be entirely in service of other teams in the org, but we needed to make sure we were also creating space for our own objectives and goals. Through feedback sessions with the team, we created planning methods that enabled us to determine and communicate our own priorities to organization while retaining time and space for assisting other teams.

Impact

By the numbers, design users that felt confident in and comfortable using the system went from 40% to over 80% in the six month period during which most of our documentation and tooling was released — an increase made even more exciting by the fact that the team had also grown. We’d also successfully resolved almost all accessibility issues on our website. But the thing that felt most impactful to me was our ability to integrate Eventbrite’s rebrand into the product for its debut in less than a month.

This was made possible by the effort of many individuals, but most importantly, by the processes and systems we’d put in place. An important part of the process was that as the new brand identity started to solidify, I began sitting in on brand team meetings to understand the feelings and aesthetics they wanted to bring into the product and discuss how to achieve them. From these insights, I mapped the new brand language onto the core tokens and styles in our system. None of that would have mattered if our system wasn’t set up in a way to easily accommodate these changes though. Because we’d done the work of making sure tokens and styles were nested correctly throughout the system, we were able to do simple value swaps that enacted large change.

Before and after images shared in a post by an engineering colleague

Also and onward

This page is focused on Eventbrite’s web system, but I also led an effort to unify our native mobile app designs with each other and ultimately with the web system — including integrating the rebrand. I partnered closely with the mobile engineers on my team and the designers that owned those features to created share base components and address accessibility issues.