Made with Protopie

Show video description

Projects

Scalable permission management

This page focuses on outcomes, decisions, and tradeoffs. The full process is documented separately.

View process

This page focuses on outcomes, decisions, and tradeoffs. The full process is documented separately.

View process

This page focuses on outcomes, decisions, and tradeoffs. The full process is documented separately.

View process

This page focuses on outcomes, decisions, and tradeoffs. The full process is documented separately.

View process

Permission management that scales with large events

Team:

Event producers

My contribution:

🎯 Problem framing

🔍 User research

🎚 Flow diagrams

🖌 Design iteration

🔬 Handoff & QA

⚡ TL;DR

As events scaled to hundreds of roles, permission setup became slow and error-prone, creating a bottleneck for event teams. I redesigned permission management using bulk editing and event-based defaults, reducing repetitive work and enabling faster, more consistent setup at scale.

📊 Outcome

~90%

reduction in configuration time

Measured using a regular task that event producers perform

Before

Manual role-by-role editing

28 minutes

New design

Bulk editing and event-based defaults

3 minutes

Qualitative feedback

Senior event producer

" I used to manually edit roles when they were created by clients, to make sure they don't have too much permission. The new solution works for me like a dozen times easier."

Senior event producer

" I used to manually edit roles when they were created by clients, to make sure they don't have too much permission. The new solution works for me like a dozen times easier."

Senior event producer

" I used to manually edit roles when they were created by clients, to make sure they don't have too much permission. The new solution works for me like a dozen times easier."

Senior event producer

" I used to manually edit roles when they were created by clients, to make sure they don't have too much permission. The new solution works for me like a dozen times easier."

Event producer

" This is really helpful for my setup of roles. So much easier to navigate and understand "

Event producer

" This is really helpful for my setup of roles. So much easier to navigate and understand "

Event producer

" This is really helpful for my setup of roles. So much easier to navigate and understand "

Event producer

" This is really helpful for my setup of roles. So much easier to navigate and understand "

Why did I choose those signals?

⚖️ Constriants and decisions

This project was scoped as a quick-win initiative, which required changes to work within existing infrastructure and not touch other features.

This project was scoped as a quick-win initiative, which required changes to work within existing infrastructure and not touch other features.

This project was scoped as a quick-win initiative, which required changes to work within existing infrastructure and not touch other features.

This project was scoped as a quick-win initiative, which required changes to work within existing infrastructure and not touch other features.

Decision 1. Keep the default permission set

Underlying issue

Every event inherited a comprehensive default permission set, which resulted in a long list with many permissions that were irrelevant to a given event.

Underlying issue

Every event inherited a comprehensive default permission set, which resulted in a long list with many permissions that were irrelevant to a given event.

Underlying issue

Every event inherited a comprehensive default permission set, which resulted in a long list with many permissions that were irrelevant to a given event.

Underlying issue

Every event inherited a comprehensive default permission set, which resulted in a long list with many permissions that were irrelevant to a given event.

Initial proposal

Only show permissions for features that are actually turned on to reduce cognitive load and scanning effort.

Initial proposal

Only show permissions for features that are actually turned on to reduce cognitive load and scanning effort.

Initial proposal

Only show permissions for features that are actually turned on to reduce cognitive load and scanning effort.

Initial proposal

Only show permissions for features that are actually turned on to reduce cognitive load and scanning effort.

Constraint

We did not have an existing system that linked enabled features and their permissions. Creating that mapping would have expanded backend scope beyond a quick-win project.

Constraint

We did not have an existing system that linked enabled features and their permissions. Creating that mapping would have expanded backend scope beyond a quick-win project.

Constraint

We did not have an existing system that linked enabled features and their permissions. Creating that mapping would have expanded backend scope beyond a quick-win project.

Constraint

We did not have an existing system that linked enabled features and their permissions. Creating that mapping would have expanded backend scope beyond a quick-win project.

Decision 2. Preserve flexible role creation

Underlying issue

Events accumulated many custom roles over time, often created with the same set of permissions or arbitrary naming, making permission management harder.

Underlying issue

Events accumulated many custom roles over time, often created with the same set of permissions or arbitrary naming, making permission management harder.

Underlying issue

Events accumulated many custom roles over time, often created with the same set of permissions or arbitrary naming, making permission management harder.

Underlying issue

Events accumulated many custom roles over time, often created with the same set of permissions or arbitrary naming, making permission management harder.

Initial proposal

Integrate role creation with permission assignment so that users are alerted when a new role matches an existing one, reducing duplicated roles.

Initial proposal

Integrate role creation with permission assignment so that users are alerted when a new role matches an existing one, reducing duplicated roles.

Initial proposal

Integrate role creation with permission assignment so that users are alerted when a new role matches an existing one, reducing duplicated roles.

Initial proposal

Integrate role creation with permission assignment so that users are alerted when a new role matches an existing one, reducing duplicated roles.

Constraint

Role creation lived in a separate, legacy flow outside the project scope, and touching it would have risked breaking the infrastructure.

Constraint

Role creation lived in a separate, legacy flow outside the project scope, and touching it would have risked breaking the infrastructure.

Constraint

Role creation lived in a separate, legacy flow outside the project scope, and touching it would have risked breaking the infrastructure.

Constraint

Role creation lived in a separate, legacy flow outside the project scope, and touching it would have risked breaking the infrastructure.

📌 Key learning

Roles were originally introduced to control menu visibility, without accounting for how they would affect other role-related areas like permission management. While this worked in isolation, the gaps became visible once those features intersected. At that point, fixing the root problem became much harder, both technically and strategically, especially when changes required touching legacy flows or risked breaking infrastructure.

Quick wins can deliver high ROI, but they should not remove the option to address root causes later. Teams also need to leave room for high-impact, higher-effort work that keeps the product adaptable as it scales. As a designer, my responsibility is to surface these system-level risks early.