Project Management for Event Organizers
Company
Whova
Role
Lead designer
Duration
6 months
The Project TLDR
Whova is an event management platform used to run conferences end-to-end, with tools such as registration, attendee check-in, badges, an event app, and more. One of the biggest projects I worked on at Whova was designing a new project management feature for conference organizers.
We found that organizing teams were managing event-planning tasks and workflows through Excel spreadsheets. Managing a 12-month-long planning process using an Excel sheet sounds like a logistical nightmare.
But it makes sense why the organizers were doing this.
Organizers who use Whova aren’t professional project managers or event planners. They were company staff, association leaders, or committee members trying to organize a conference on top of their normal jobs. Most teams just needed something “good enough” that didn’t feel like another tool to learn.
To address this gap, we built an MVP of a project management tool with two goals:
Help organizers coordinate event planning without living in spreadsheets
Promote feature adoption across the Whova platform
As the lead designer on this project, my work centered on one question:
How do you design a PM tool for people who don't think of themselves as project managers?
Organizers loved the new PM tool, with 30% of active organizers trying it within 30 days of launch.
Final designs
Initial research: understanding pain points and existing workflows
The Problem: Event Planning Lived in Spreadsheet Chaos
Survey data showed 71% of organizers running events out of spreadsheets.
It wasn't ideal — but it was familiar, and "familiar" beat "learning Asana from scratch" every time.
Fewer than half of teams had a person in charge of managing workflows. Even among those that did, it was rarely a trained project manager, just another team member coordinating on top of their day job.
Spreadsheets and a lack of a project manager led to missed deadlines and little accountability. As one organizer told us:
"Catering just sat as 'in progress' on the spreadsheet, so everyone assumed someone else was taking care of it. No one actually followed up — and we only found out we missed the deadline when the vendor told us they were fully booked."
Whova event organizer
One other pattern showed up in nearly every team: admins had volunteers, interns, or committee members helping with event tasks. But those helpers weren't on Whova at all. Adding them to the full platform felt too heavy, so they stayed in email threads and shared docs. A lighter way to bring them in would make planning more coordinated and pull more people into Whova in the process.
What I had to keep in mind
Organizers weren't choosing between Whova's PM tool and Asana — they were choosing between Whova's PM tool and the spreadsheet they already had open. If it didn't feel obviously simpler than that spreadsheet, they wouldn't switch.
That set the bar: 💡 Make it feel lighter than the spreadsheet they already use.
A few other constraints shaped how I designed within that bar:
PM had to fit inside Whova's existing event structure, not exist as a standalone workspace
Engineering resources were reduced halfway through the project (we lost the lead and senior engineer mid-project), which forced ruthless prioritization
Event planning is cyclical — months of pre-event work, days of execution — so the design needed to serve both rhythms
Design challenges
A collaborator portal that admins would actually use
PM had two very different kinds of users — admins running the broader platform, and collaborators invited only to help with project work.I explored two approaches:
Admins
In charge of running the event
Paying Whova users running event logistics
Full access to event management platform
External collaborator
Pulled in to help with event planning/tasks
Typically interns, volunteers, event staff
Not added to event management platform
The harder challenge wasn't designing the collaborator experience itself. It was getting admins to invite anyone in the first place.
Admins already underused teammate invites across the platform. Adding someone to Whova felt like a heavy commitment — full account, full access — so helpers who were already part of the event team stayed off-platform.
If invitation felt simple instead of high-stakes, admins would invite people they otherwise wouldn't. So the collaborator portal was built around that:
one fixed role, no permissions to configure
focused only on the project the admin invited them to
visually separate from the admin platform, signaling "this is your workspace," not a stripped-down version of someone else's tool
Templates, pre-filled by an event quiz
Starting from scratch is hard for non-PMs — and exactly the kind of friction that pushed them back to spreadsheets in the first place.
I considered three starting points for the first-run experience:
1. Blank canvas
User sets everything up from scratch
Maximum flexibility, but high setup burden on the user
2. Template gallery
User browses and picks templates manually.
Assumes users know which templates they need, which non-project managers don’t yet.
3. Quiz, auto-populated templates (decision)
User answers a few questions about the event; system fills in
Cognitive work shifts from user to system
We went with the quiz. It shifts the cognitive work from the user ("which templates do I need?") to the system ("what does this event look like?"). Based on the answers, the dashboard fills with relevant projects — Speaker Management, Sponsor Management, Venue Setup, around 9 in total. The user's first action is editing a real plan, not building one.
Tasks and checklists, modeled around event time horizons
Organizers already separated these two kinds of work themselves — task lists for long-term planning typically lived in one spreadsheet tab, event-day checklists in another. They didn't think of them as the same thing, and they didn't manage them the same way. The separation was already in their workflow; their tools just didn't make it work very well.
Generic PM tools (Asana, Monday) go the opposite direction — they collapse both into one object type with optional fields. You can have a task with no assignee, no due date, and a parent that's also a task. That works for power users, but it forces non-PMs to figure out which fields matter for which kind of work. It's exactly the kind of decision-making that pushes people back to spreadsheets.
I built around the line users had already drawn instead of erasing it. Tasks and checklists are separate objects, each modeled to match the rhythm of work it represents. That made each easier to scan and easier to act on — and it gave us a clean place to expand into mobile later, since event-day work happens away from the desktop and checklists are the natural surface for it.
What I had to keep in mind
Research surfaced a real pattern: organizers experience informal dependencies (for example, the program can't be finalized until speaker bios are in). I argued for a lightweight dependency feature in v1: not a full graph, just the ability to mark a task as blocked and surface that to whoever owned the blocker.
PM and leadership disagreed. Their argument was that organizers transitioning from spreadsheets would find dependencies confusing — that the MVP needed to optimize for "looks easier than what I'm doing now." Dependencies got cut.
I shipped without it. The signal that would settle it: if users are consistently writing "waiting on [person/task]" in comments, that's data telling us blockers exist and the workaround is text-based. At that point the lightweight feature earns its complexity.
Outcome
30% of active organizers tried PM within 30 days of launch. That's the headline number, but it doesn't prove the bigger thesis on its own — the idea that PM would pull organizers into using more of Whova.
The metrics that test that are still in flight:
Cross-feature adoption among PM users vs. non-PM users (the direct test)
Return on next event — whether teams that used PM for one event come back for the next one (the cyclical-product version of stickiness)
Template usage patterns — what users keep, edit, or delete
Invitation acceptance rate — the signal for whether magic links are worth building
What I'd improve
Reduce collaborator login friction with magic-link invites, which would test whether the auth account creation step is suppressing adoption
Revisit lightweight task blockers if comments reveal users are working around the gap with "waiting on X" notes
What's next
Mobile support for event-day checklists
Re-exploring dependencies if usage data supports the case
