Bulk Edits.
Making complex changes intuitive.
Enterprise event teams were spending hours manually updating timeslots and tickets for their events. I designed a bulk-editing system that made it possible to edit the values of hundreds of timeslots and tickets in one flow, giving users time back.
90% Time Saved
Compared to individual editing flows, going from a process that took hours to less than 5 minutes.
88% Error Proof
By optimizing against user mistakes with intuitive error handling and auditable changes.
Promising Adoption
Showing users trusted bulk edits when committing more than 1 timeslot and ticket change per event.
Decreased Help Requests
Clients were more likely to commit their own changes than asking for help from Universe support teams.
Role
Lead Product Designer
Assisted by 3 others.
What i owned
Stakeholder management, design approach, usability testing, prototyping, release, and post-release support.
Team
Product Manager.
3 Frontend Developers.
Skills
0-1 feature creation.
Designing with incomplete data.
Cross-team collaboration.
Solution
Users could make changes to their event timeslots and ticket types, then audit those changes at any time.
This became possible without needing to configure each value at a time, preventing errors and hour-long workflows.
PROBLEM
Individual time slot editing led to errors that cost large-scale event organizers money and strained Universe’s customer support teams.
Users managing large‑scale events were hesitant to make updates because small changes often took hours and a single mistake could ripple across the entire event, creating errors like overlapping timeslots, invisible tickets, and improper pricing.
How might we design an intuitive, error‑resistant bulk‑editing feature that users trusted while meaningfully reducing time spent on timeslot and ticket updates?
Timeslot edits were chosen because they were the most error-prone of all editing flows. I discovered this from talking to our team and by evaluating user journey data, which showed trying to undo changes and re-editing values.
Stakeholder Management
I advocated for constant check-ins with our client-facing teams, as they were often tasked with actioning changes for our clients. I presented the problem framing, scope, and success metrics while taking feedback and looking out for details that may force a pivot.
Research
The biggest asks included intuitive hierarchy of changes, the ability to undo commits, clear auditing, reports, and improved error prevention.
We interviewed customer support, product ops, and sales teams at Universe. They flagged current pain points and gave us ideas on how to evolve the platform over time.
Challenge
This project was created as a “quick win”, leaving me with a short runway to do research. I chose not to push for client interviews, as they could take a long time to organize and conduct.
Solution
I chose to interview customer support, product ops, and sales teams. It wasn't perfect, but users often asked them to action changes on their behalf, leaving them with a good understanding of their needs.
before
Organizers had to update every ticket and time slot one by one, turning large events into hours of error-prone manual work and creating operational strain, delays, and churn risk as event complexity grew.
Stakeholder Management
Once I had a design approach laid out that was based on research, I teamed up with my PM to formally present this research with our senior leadership team. The goal was to ensure their values were reflected in our problem framing and proposed solution.
Design Decisions
We planned to release in milestones. I worked with my design team, PM and development lead to iterate.
I led iterations on my own, then came together with my design team once a week to test my approach, and had separate sessions with my PM and dev lead to get their feedback. I built publicly by posting on Slack, keeping updates visible for the wider org.
Trade-off
Our short runway meant I had to prioritize. I optimized for error prevention at the cost of making the product more rigid to use, so the user was less likely to action a big change by mistake. This created guardrails while we monitored feedback and addressed edge cases.
Challenge
Performance was a constraint. This meant I could not design with tables (a familiar pattern for bulk editing across various domains).
Solution
I focused on streamlining designs to the most essential actions, and testing internally to ensure key actions weren’t missing.
This is the first design I reviewed with the team. I decided to surface all actions at once, leveraging tables due to its a familiar pattern, but performance concerns and poor testing results inspired a pivot.
I designed with mobile in mind from the beginning. The goal was to make the designs responsive without changing them in significant ways.
User testing
Great User Feedback
During all stages of the project, my team was lauded for streamlining a high pain point workflow.
Less than 2 minutes
To action changes to multiple timeslots and ticket types.
77% Understanding
When we asked users about change hierarchy and preventative measures.
82% Approval Rating
When asked how they felt about our proposed solution, suggesting minor changes over time.
Stakeholder Management
Once I had final solutions in place, I demoed final prototypes with the entire organization in one of our bi-weekly all-hands sessions to showcase the work that we had done, and to capture any final feedback.
Future
Unlocking the ability to edit grouped tickets and automate pricing changes.
I continued to monitor feedback after release, and paid attention to roadmapped projects that could affect bulk edits. A future version would have to let users edit grouped tickets independent of individual tickets. One of the biggest asks included pricing change automations.
Major project milestones.
Proposed feature expansion.
Edit grouped tickets values.
Give all selected individual tickets their own values.
Schedule price changes (automation).
Keep track of automated changes.
TAKEAWAYS
I learned how to make hard trade-offs, how to manage multiple stakeholders, and understood the importance of thinking about future updates.
This was the first project where I faced a limited runway for research, inspiring a fast, iterative approach where thoughtful usability testing was key.
If I could do something differently, I would try to understand what potential future projects could affect my own work earlier in the process, as designs had to change in significant ways after grouped ticket edits became the focus of our roadmap.
Next up
