One of my first major initiatives at Eventbrite was to unlock the repeating events market by building a powerful new way for organizers to manage and sell tickets for repeating events on the platform. After extensive user research, we extended the existing event management tools to give organizers dynamic scheduling, independent inventory and attendee management, and more powerful reporting.

My Role

I was the sole UX architect on this project. I led all research and design, from start to finish.

Goal

To design and build scheduling and key event management tools to match the needs of organizer when managing events that have not a single date/time, but rather occur repeatedly over a specific, usually-regular schedule.

Initial Research

I collaborated with an excellent Product Manager partner, Chanel Edwards, to conduct hour-long interviews with a large number of organizers of repeating events, focused on discovering how they define "repeating events" and what their core needs are when managing such events. Chanel and I worked together to identify relevant users, plan research guidelines, and lead interviews. We then distilled our notes into meaningful requirements that would inform what we could build (long-term) and what we should build immediately. This resulted in two operational definitions: "repeating events" are events that have repeating schedules, but all other aspects of the event remains the same; and "series events," which might vary significantly in title, venue, description, attraction, price, and more, but are strongly related by theme or by some common attribute.

Based on this research, we decided to focus initially on "repeating events" in order to enable a wide variety of organizers across markets and verticals to set up their schedules and sell tickets more efficiently. Specific processes for managing classes might be different from tours or film screenings, but general needs and behaviors for scheduling and ticketing were often shared.

Design

Before even thinking about specific UI solutions, I made sure I had a solid grasp of the tasks and scenarios we intended to address. This meant making sure I understood the important users would place on having the ability to create irregular schedules, for example, or managing attendees separately for each instance.

Once I had designed an initial solution, I also worked very closely with the engineering leads to understand the constraints of the existing system, and what we would feasibly be able to build and support. This led to several rapid iterations on the designs, especially to improve the scheduling interface. Eventually, we landed on a system that would allow users to create the schedule according to simple rules like "Weekly, every Monday and Wednesday, until March 3" or "On the 3rd of each month, for 10 instances," and then allow users to add or remove dates one-by-one (or en masse) from the schedule. The schedule could also dynamically reshuffle itself into new logical groupings based on simple pattern recognition in the schedule.

I gradually refined the scheduling tool as the engineering team built out the services and front-end components — informing each other's decisions along the way. My designs expanded to account for how organizer would manage repeating events, including how we would expose the vast event management tools to either the top-level event dashboard or at the level of each instance.

I also crafted the basic displays and interactions for the consumer-facing product: how should a person select a date/time instance from an event? Should each instance get its own dedicated event listing, or should they share a single unified listing? Should sharing an instance direct people to that specific instance, or to the general event? What if the shared instance had passed before the shared link was followed? Ultimately, the consumer-facing experience was limited to a bare-bones scope, but I explored and designed several richer experiences that have more recently been picked up with keen interest.

Validation

During development, we shared designs in informal settings with organizers and internal stakeholders to ensure general direction and to avoid major user experience flaws. However, given the complexity of the interactions for scheduling, which was by far the most significant change in the end-user experience, we decided to build a quick MVP and release it to a group of hand-picked alpha organizer. This allowed us to recruit as we would have for usability testing, but then to put the real working product in users hands and get structured feedback and observation from them over a longer period of time. This sort of quasi-diary study was a fantastic way to validate the solution.

Before the alpha could begin, my product management partner left the company, which left me to plan, recruit, and run the alpha research and roll-out solo. (Of course, I still worked closely with our marketing and engineering teams to recruit and release!) For each of the 12 or so alpha organizers selected, we kicked off with a formal round of user testing, and then introduced them to the tool and asked them to check back regularly (usually weekly) to give us their impressions. During this period, I worked with the engineering team to adjust the solution and get fixes out as quickly as possible.

Reflection

The repeating events product was met with much excitement from event organizers, when it was finally opened up for general usage, and has proven to be one of the most impactful single "feature" to Eventbrite's bottom line over the years. While not the most glamorous projects in its user-facing interactions, designing the system and logic that would empower countless organizers and unlock entire markets for the company remains a point of pride and a fond memory for me.

Repeating Events