Ticketfly integration
Halfway through my time on EDS, Eventbrite acquired Ticketfly, and soon after, we learned that all ongoing projects would be paused to prioritize migrating Ticketfly customers to Eventbrite. This required building new products and tools to support features from Ticketfly while ensuring a smooth transition for both companies.
My team joined the project after the high-level plan was set. My focus was on permissions, which were now part of the new “organizations” entity (distinct from organizers). I worked closely with the designer managing account settings to ensure a cohesive, intuitive experience. Permissions turned out to be the most complex and demanding feature due to the introduction of the organization model at Eventbrite.
Inviting users
Inviting users was a critical aspect of the integration. The goal was to allow admins to invite members via email, assign roles, and specify event access within the organization. The challenge was balancing what admins could do with the user experience in the invitation email.
As we designed this feature, new databases were being built simultaneously, which led to constant changes to the data we could display due to backend limitations. It wasn’t the ideal way to build products, but under the tight deadline, we had to adapt quickly and iterate as we went.
Up-leveling
As the project progressed, we identified overlooked use cases, particularly for users on an older version of permissions or those joining a new organization and needing to switch. This is where EDS proved invaluable, giving me firsthand experience using the system I had been working on. By the end of the project, I had compiled a list of ideas on how EDS could be improved based on the insights gained from these challenges.
Edit permissions
Another essential feature we needed to address was allowing admins to edit permissions for existing members. Fortunately, we were able to reuse much of the design we had already developed for inviting users, which streamlined the process and maintained consistency across the interface.
Home page
This page was arguably the most crucial, as it provided the admin with a comprehensive overview of all members and their associated roles within the organization. From here, admins could invite and remove members, edit permissions, and create new roles. Roles were essentially a set of permissions tied to specific job functions within the organization. For example, a “Sales” role could have access to various data points on dashboards but wouldn’t be able to post to social media, which could be assigned to a different role.
Edit permissions
In addition to inviting users, establishing roles within an organization was another key requirement. This view prompted me to tap into my design system expertise, as we needed a toggle component to enable various groups of permissions with one click. However, after some light user testing, we found that this approach wasn’t ideal. Admins would have to individually deselect each permission they didn’t want, making the process cumbersome.
