Permissions

Halfway through my time on EDS, we acquired Ticketfly. Not long afterward we learned that every ongoing project would be put on hold so we could swiftly migrate all Ticketfly customers to Eventbrite. This also meant making sure Eventbrite could support all the features Ticketfly were already offering their users. As it turned out we needed to build a lot of new products and tools to facilitate this in a way that makes sense for both companies.

My team joined the project after a few major stakeholders and a UX designer had hashed out the general plan of attack. The blueprint would involve existing feature teams working together yet on a different section of the new products we needed. My area happened to be permissions which lived within account settings of a newly formed entity called organizations ( not to be confused with organizers ). I would work closely with the designer who was designing the overall account settings structure to make sure we could achieve a cohesive and expected experience.

Permissions turned out to be the most demanding of all the new features. Considering that organizations were going to be a new model for Eventbrite, everything about it had to be thought through very carefully.

Invite users

Inviting users was one of the most basic things we needed for the integration, for obvious reasons. This view would simply allow an admin to invite a member via email address, specify a role or limit their involvement by searching for particular events within their organization. We constantly went back and forth around what was possible with this part of the experience as would not only have the admin add users but also consider what the user would see in an invitation email. New databases were being built in unison with myself designing this. Certainly not an ideal way to build products but it was the only way to do it under a deadline. This meant that the data points I thought I could show were being taken out almost on a daily basis due to the limits of the backend.

upleveling

As time went on, we discovered some use cases that were overshadowed during the kickoff phase. One was the need to account for users who were both on an old version of permissions that Eventbrite had and also for those who joined a new organization and wanted to switch. This is where EDS came in extremely handy and was very valuable for me to get some experience using what I had been working on, as a customer. I eventually came away from this project with a list of ideas on how EDS could be improved.

edit permissions

Another basic need that we needed to solve for was to allow admins to edit permissions for existing members. Thankfully we could re-use a lot of the same design that we had for inviting users.

home page

This was arguably the most important page as it gave the admin a birdseye view of all the members and roles that were associated with that organization. From here, the admin could invite and remove members as well as edit their current permissions and even create new roles. Roles were a collection of permissions that would be specific to a particular job within that admin's organization. A common example would be Sales. This role would have the ability to see various data points on dashboards but unable to post to social media, which could be a separate role.

edit permissions

Alongside inviting and having users, establishing roles within an organization was another must have. This view required me to put my design system hat back on as it turned out that we needed a toggle component to turn on various groups of permissions with one click. With some light user testing, we realized that this was not the preferred method as it meant admins would have to individually de-select every permission they didn't want.