Screenshot of Eventbrite Design System

Eventbrite Design System

Scaling a design system through an acquisition.

Problem

The Evenbrite Design System had been bootstrapped by a small team, but as we acquired several large companies it became apparent that it needed work to scale.

Information was scattered between the website, Sketch, Invision, and Slack. Designers couldn't find the information they needed. There was also no set process for interacting with the newly formed design system team.

Team

I worked together with a PM, an engineering manager, and several engineers.

My Role

I was in charge of user research, user experience and interface design, and process creation.

The original team was bootstrapped and didn't develop a process for naming components. Because of this, some of our naming didn't align with industry standards and designers were having trouble finding components.

To solve this - we did an industry analysis of other systems, standard naming, and held conversations with the design team. This led to a new information architecture for our component and pattern libraries.

Screenshot of old dashboard

I knew we needed to consolidate information to one place, but I wasn't sure where or what information to provide. So, I sent out an internal survey, had 1:1 interviews with designers, engineers, and product managers, and researched other design systems.

Screenshot of prototype

Based on the results of that research, it became clear that the source of truth should be the web portal.

Historically, the web portal for the design system contained primarily developer documentation. It didn't give designers any guidance around how and when to use the component, which was showing up as a big problem. It also wasn't helpful for designers and developers trying to understand the ways our components could flex and be configured.

I designed an updated version that allowed us to provide more information to our users without the crowding that our previous pages had suffered from.

The key features improvements were adding in usage guidelines, explained below, and a configurable table for our components. Using this, users could create all possible configurations of the component and the code would update for developers to use in implementation.

Many problems with the system stemmed from our lack of documentation around when and how to use component and any specifics of acceptable use. This was causing a lot of small usage inconsistencies across our product and frustrating designers. It was also an issue when developers would build small features without design assistance.

To solve this, our team went in and wrote best practices for all our components along with visual dos and donts.

Screenshot of new inline response form

Along with the web portal overhaul - I identified many key processes that needed to be updated. This resulted in new Slack workflows for communicating with the design team, the creation of open office hours, and switching from stickersheets of components to a robust Sketch library using symbols.

Results

This work was fundamental to many large company projects done on almost impossible timelines after, including our future rebrand. We also gained greater adoption of the design system and improved our users understanding of the system, how to use it, and where to find information (as captured via survey).

Other

I led the creation of a native design system to align our mobile products to web and the overhaul of our design system to reflect our new brand pre-IPO - case studies coming soon.