PLATFORM
TIMELINE
TEAM
Over 95% of events on Whova use the Agenda Center to build or import their session schedules. For smaller events, it works well. But for events with hundreds of sessions, most organizers had a workaround: plan everything in Excel first, import into Whova after.
Whova lacked a way to flag when two sessions conflicted, so organizers were doing it themselves. That meant manually cross-referencing every speaker, every room, and every time slot across hundreds of rows. Color-coding, filtering, and hoping nothing slipped through.
Users — Save time, reduce errors
Cut the hours organizers spent manually checking for conflicts and catch what slips through without back-and-forth adjustments.
Project — Find the right scope
Identify the conflicts organizers run into most, and determine what's feasible to support within our timeline.
Business — Close the workflow gap
Strengthen platform stickiness by closing the Agenda Center's biggest workflow gap.
We turned a manual, error-prone spreadsheet process into a configurable conflict checker. Organizers set up the conflict rules that apply to their event and get a report flagging the exact rows that need fixing. Less time hunting, more time resolving.
21%
Adoption rate among events with 100+ sessions
26
Median conflicts caught per event
2X
Faster conflict resolution
Hundreds of events launch on Whova every month, so getting something useful out quickly meant we'd have real data to work with sooner. Before jumping into design, I wanted to get clear on what we were actually trying to solve. I synthesized insights from organizer interviews the research team had conducted, then ran competitive analysis across 4 platforms and did 2 production audits to assess feasibility. The research pointed to two clear insights:
01
02
70%+ of Whova users import their agenda from Excel
In-platform agenda building isn't their main workflow
The Agenda Builder page is already dense with actions
The new design shouldn't disrupt the core session management flow
Looking at what competitors had built, my first instinct was to go for something similar — in-platform scheduling with real-time conflict detection. But after seeing 70%+ of Whova organizers were importing their agenda from Excel, I realized that building that would mean asking most of our users to completely change how they work, just to use a new feature. That didn't make sense.
So I brought it back to the PM, and we scoped to something more focused:
Throughout the process, I had three principles to guide my work:
Setup approachability
Cut the hours organizers spent manually checking for conflicts and catch what slips through without back-and-forth adjustments.
Configuration efficiency
The conflict rules should be fast to be established.
Business — Close the workflow gap
Results should be easy to understand and act on.
Research and competitor analysis pointed to a clear split: double-booked speakers and double-booked rooms are conflicts the system can check automatically — no setup needed. Everything else requires organizer input.
01 Explorations
First two explorations put all rules in one view.
02 Follow-up survey
After presenting the initial two designs to the team and testing them internally, I had two key observations:
People spent significant time reading each rule description before understanding what it did.
They showed hesitation when facing all rules at once — unsure where to start or whether they could skip anything.
Combined with the fact that some competitors only offered the two basic checks, I started wondering:
"Was front-loading all the rules actually making setup easier — or just making it more overwhelming?"
So I proposed a mid-design survey to the team to validate my assumption.
The 60 responses we got from our organizers showed:
50%+
of them only needed double-booked speaker and room checks. That's it.
Turns out, I had been designing for the minority the whole time. The real question wasn't "how do I present every rule clearly", but “how do I let the majority get in and out quickly, while still giving power users everything they need”.
03 Flow adjustments & Final design
The final design added an onboarding step that lets organizers choose their path before they see any rules at all.
Save organizer's effort by pre-populating event dates
✅
The onboarding step segments users before they see any complexity.
50%+ of organizers get in and out without touching a single rule.
✅
Present the "Set up custom conflict check" option to basic users.
✅
Stronger visual indication that basic conflicts are auto-checked.
Once organizers chose to set up custom rules, each rule type needed its own configuration. The key goal is to get each individual rule to feel quick and intuitive to set up.
I went through rounds of exploration, testing each internally and presenting to stakeholders to validate the interaction against how organizers actually think about when configuring the rules for diffrerent types of conflicts. Each round surfaced a clearer picture of the right mental model.
V1: Specify speaker's available time day-by-day
❌
Time confusing for multi-day events.
❌
Point of confusion: Leaving a date blank meant nothing — unavailable? Incomplete? Couldn't tell from the UI.
V2: Save organizer's effort by pre-populating event dates
✅
Multi-day events represented automatically without manual entry.
❌
Input from stakeholders: speakers typically only show up on the days they're presenting. The real constraint was which days, not what hours ✗ No way to mark a day as simply unavailable.
Save organizer's effort by pre-populating event dates
✅
Matching the design with how speaker's availability is considered
Matches real behavior — select the days they're there, ignore the days they're not
✅
Present the "Set up custom conflict check" option to basic users.
✅
Stronger visual indication that basic conflicts are auto-checked.
Why we chose this
In this milestone, the fix happens back in the spreadsheet — not inside Whova. So the conflict report page had one job: make it as easy as possible for organizers to understand what's wrong and find the exact rows they need to fix in the file. I went through three structurally different approaches before landing on one that actually matched how organizers work.
❌
V1: The flat table layout crampped multiple columns made important content got truncated.
❌
V2: Still fragments by type first — a session with multiple conflict types still requires hunting across different sections.
❌
V3: The flat table layout crampped multiple columns made important content got truncated.
✅
Matches the unit of action — one session, one row in Excel, all conflicts together
✅
Colored left border visually distinguishes conflict types within each session at a glance
We didn't have direct access to organizers during the design phase. Instead of letting that slow things down, I leaned into what we did have: internal testing, stakeholder reviews, and rounds of back-and-forth that helped me pressure-test each direction before moving forward. It wasn't the most efficient path — there were moments where I had to go back to the drawing board after a round of feedback, or pause mid-design to run a quick survey. But those pauses were what made the final design better.
The speaker availability form is a good example. It took three iterations to get right, the real constraint wasn't obvious until I put the design in front of people and watched how they responded. No amount of solo thinking would have surfaced that.
That's something I'll bring to every project from here.
21%
Adoption rate among events with 100+ sessions
26
Median conflicts caught per event
2X
Faster conflict resolution
