Case Study
Architecting a Modular Event Management System
Product Designer - Stratly
June, 2025
Product & Problem
Stratly is a multi-tenant enterprise B2B fundraising and financial data platformfor enterprise nonprofits. Originally, event management was built as a secondary, hard-coded feature tied directly to fundraising campaigns. As organizations scaled, this single-event architecture broke down. Clients needed to run multiple concurrent events, variable ticket types, and complex seating arrangements within a single campaign. Because the legacy system was too tightly coupled, extending it caused severe logic conflicts and UI breakdowns, creating a massive friction point for users and internal support teams.
My Role & Contributions
I led the product design and architectural uncoupling of the event management system from initial concept to production. My objective was to strip event data out of the campaign monolith and rebuild it as a system of flexible, scalable modules capable of handling complex enterprise workflows.
Key Design Decisions
Architectural Uncoupling
Research revealed a core structural flaw: the platform treated an event as a static object. Users actually needed events to behave as repeatable components to reuse global campaign settings while customizing specific details. I redesigned events as standalone, repeatable modules. Users can now generate multiple independent events inside a single campaign, manage details in isolated contexts, and scale their fundraising activities without triggering backend conflicts.
Standardizing the Interaction Model
To keep cognitive load low as complexity scaled, I established a strict, consistent interaction model for every event object. I restricted the architecture to seven predictable states: Overview, Settings, Tickets, and Attendees. By standardizing this data structure, I created a predictable UI framework that prevents users from getting lost in deeply nested configurations.

Ticket Mapping Logic
To solve widespread ticketing confusion, I restructured the data mapping logic in the UI. Tickets now live strictly inside their parent event rather than floating at the broader campaign level. By enforcing this parent-child relationship, the system completely eliminated attendee assignment errors. Campaign-level tickets remain optional for organization-wide access, but isolating event-specific tickets made the data hierarchy obvious and immediately reduced configuration mistakes by event organizers.

Engineering Workflow & Handoff
To ensure accurate implementation of the uncoupled event architecture, I maintained tight collaboration with the front-end engineering team. I utilized Figma Dev Mode to provide code-ready token documentation and exact CSS properties for the proportional seating grids. We held weekly design QA syncs to review the updated data models, ensuring the new modular UI components mapped perfectly to the updated backend endpoints before they were merged into production.

The Impact & Outcomes
The outcome of this project created a completely decoupled foundation that removed hard-coded system constraints, allowing enterprise organizations to scale their active events dynamically without any platform degradation or UI redesign
By turning a rigid feature into a system of predictable components, the redesign delivered immediate results:
90%
Less Engineering Support Time Spent On Events
Eliminated the need for manual database workarounds to support multi-event campaigns, reducing engineering support time spent on events by over 90%.
75%
Cut In Event-Related Support Tickets
Restructuring the ticket and attendee flow drastically reduced user confusion, cutting event-related support tickets by 75% within three months of launch.
95%
Decrease in Overall Time Spent To Create & Launch An Event
Decreased the average time it takes a user to configure and create a complex, multi-day event with custom seating and take it to launch state from hours to under 10 minutes.
Challenges & Trade-offs
The most significant challenge was migrating legacy user data into the new modular framework. Because old events were hard-coded to campaigns, we could not simply flip a switch without risking data loss for active fundraisers. I had to design a transitional UI state that allowed legacy events to function alongside the new modular events. This required strict version control in the interface, ensuring users could still manage ongoing campaigns while forcing all new campaigns to adopt the upgraded decoupled architecture.