Eventbrite Design System
Creating consistency, clarity, and accessibility across platforms and brands to empower feature teams
Overview
At both…
why/how i got involved
systems are both building and communication tools, legos and language
problems with accessibility and usability most easily solved at the core
allows IC designers to be more impactful
nerd about tooling/code/documentation
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.
Team & Role
Cross-functional leads
4-6 engineers
2 mid-senior level designers
2 junior designers
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.
system failures were slowing down IC designers, not able to reach potential
More context:
a team had existed but wasn’t a funded/core team
multiple code frameworks (new system old styleguide native on it’s own)
Process
Audit: figuring out what we have across frameworks, what they’re called, accessibility, flexibility
from audit, documentation and roadmap
interview and survey designers for their understanding of systems and tools
document document document
interactive documentation site - shared language and understanding of variables
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.
Audit:
figuring out what we have across frameworks, what they’re called, accessibility, flexibility
interview and survey designers for their understanding of systems and tools
from audit, documentation and roadmap
interview and survey designers for their understanding of systems and tools
document document document
interactive documentation site - shared language and understanding of variables
getting on the road
roadmap
prioritization based on audit & team urgency, accessibility, ease of win
Needed more documentation yesterday, led entire design org in writing
Roadmap, interrupted
reprio of engineers for integration, PM blessing to lead design & push forward roadmap
finished design of system site, collab with eng in downtime to build
designers worked on components & tooling
rebrand
Started collab w brand team to bring new brand into system
Used new brand as opportunity to update native systems, shared language, accessibility
Integrated into both actual system and old codebase styleguide
Outcomes
Increase in a11y, greater understanding and adoption of the system (from survey), office hours and other processes
Asana
I was brought in to kick off the newly created design systems team at Asana. During my time in this role, I:
audited the product and created a list of components and interactions currently used
created a prioritized list of high-impact components and inconsistencies
reviewed the accessibility of the product and created an action plan for addressing issues that could easily be addressed while also creating processes and frameworks to prevent future inaccessibility
created a Figma library for components
designed a documentation site for designers, developers, and product folks to use as a source of truth
worked with cross-functional team members and designers throughout the org to refine existing patterns and create new ones
updated our color system to improve accessibility
helped develop processes for communication and ownership between feature teams and the design system team that balanced slowdown/friction with consistency and visibility
After switching to a feature team, I remained a stakeholder in the design system and took part in strategy meetings, continued to advocate for and help with accessible design, and built new patterns for the system as I designed a new product area (reporting).