Project Management
Whova is an event management platform that helps organizers plan and host conferences. Within a single platform, Whova provides everything the organizer might need, from attendee registration and management to badges, networking, and an event app.
I led the designs for a new project management tool to help organizers assign and track tasks within their planning teams. By creating a tool that organizers would use from the start of their planning process, the goal was to encourage earlier adoption of Whova and increase use of other core features.
Company
Whova
Role
Lead Designer
Duration
6 months
The problem
Planning an event can start up to a year before the event actually happens. Organizers typically finalize things like the venue or attendee registration well ahead of time, then shift their focus to attendee-facing experiences (such as the event app) closer to the event.
Whova supports the entire event planning process, from early planning through event day. However, many organizers only start using Whova near the end of the planning process, primarily for attendee-facing experiences.
Whova was entering organizers’ workflow too late.
Early planning tasks like speaker coordination, sponsorships, and registration setup had already happened elsewhere, limiting opportunities to discover and adopt more of Whova.
This mattered because multi-feature users renew at 2.5× the rate of single-feature users. So helping organizers discover more of Whova's capabilities was critical to long-term retention.
Our hypothesis: by bringing organizers into Whova earlier, we could create more opportunities for them to discover and use more features throughout the planning process, increasing adoption and retention.
Why solve it with project management?
We needed a way to deliver value before organizers would normally turn to Whova, so we targeted one of the earliest moments in every event planning cycle: task delegation.
Every organizing team needs to coordinate tasks, owners, and deadlines, yet most were managing this work in spreadsheets that weren't built for collaboration.
Rather than competing with tools like Asana, we built a lightweight MVP to help teams coordinate tasks and timelines. The goal was simple: provide enough value for organizers to adopt the workflow and help us learn what they actually needed.
Research findings
We interviewed organizers to understand how they planned events today. Three findings shaped the product strategy:
Spreadsheets were the source of truth
71% of organizers relied on spreadsheets — often a mix of tabs, docs, and trackers — instead of dedicated planning tools.
Event planning happened in two distinct phases
Early planning focused on long-term projects and ownership. Near the event, work shifted to checklists, confirmations, and final preparations.
The biggest challenge was visibility, not complexity
Tasks got buried, ownership became unclear, and follow-ups slipped — creating coordination problems rather than a need for advanced PM features.
Real example of an event planning team's project management spreadsheet
This made the strategy clear: we didn't need to replace tools like Asana. We needed to create something lighter than a spreadsheet and built around the way organizers already worked.
What the design had to do
The MVP would succeed or fail on adoption. Organizers wouldn't switch from a working spreadsheet to a heavier tool — and if they didn't try Project Management, the broader hypothesis (that planning on Whova would drive multi-feature use) couldn't be tested at all.
Looking at the work in retrospect, three barriers to adoption shaped the strongest design decisions:
Learning curve
Too much new complexity would push users back to spreadsheets.
Time to first value
A blank canvas wouldn't compete with an existing spreadsheet.
Team coordination
A tool only works if the whole planning team can participate.
All of this had to happen inside an MVP. Engineering capacity was reduced halfway through (we lost the lead and senior engineer mid-project), so whatever shipped had to be small enough to ship and good enough to learn from. Every "we should also have…" was deferred to be revisited with real data.
💡 The bar wasn't "the best PM tool. It was "better than the spreadsheet they already use."
Key decisions
Tasks and checklists, kept as separate tools
Months before an event, planning focused on larger projects like registration, speaker management, and sponsorships, typically owned by one person and broken down into tasks with deadlines. As the event approached, work shifted to shared checklists for final confirmations and preparations.
Spreadsheets struggled to support both workflows. Long-term tasks could slip through the cracks without reminders or clear progress tracking, while shared checklists became harder to manage as multiple people edited the same document.
Many PM tools treat both as the same type of task, but organizers already saw them differently. We kept that distinction and designed each tool around its purpose: tasks for ownership, deadlines, and progress; checklists for lightweight team coordination.
Why it served adoption: The tool matched how organizers already worked instead of forcing them to learn a new process.
2. Templates pre-filled by an event quiz
The hardest part of planning isn't managing tasks — it's knowing what tasks need to happen in the first place. A blank spreadsheet forces organizers to build a plan from scratch, which is especially difficult for people managing events alongside their day jobs.
To bridge this gap, I designed a short event quiz that turns setup into personalization. Based on their answers, organizers start with relevant projects — like Speaker Management, Sponsor Management, and Venue Setup — instead of an empty dashboard.
Why it served adoption: The quiz reduced time to value by replacing "figure out what to plan" with "refine a plan that's ready to use." The data on which templates users keep vs. modify will tell us where the quiz fell short and what the next iteration should solve.
Designing for 2 access levels
As we kicked off the project, our CEO shared a challenge she'd observed across Whova: planning teams weren't fully represented on the platform. Because admins viewed Whova primarily as an event app, they typically invited only teammates whose work touched the attendee experience. Roles like social media, sponsorship, and volunteer management stayed off-platform, despite Whova offering tools that could support their work.
The Project Management MVP was a natural place to address this. By letting non-admins access PM without access to the rest of Whova, we could bring more of the planning team onto the platform and create opportunities to introduce them to relevant features.
💡 The design challenge: if admins were going to invite a wider team, the cost of inviting had to feel low.
Adding someone to Whova meant creating a full account with broad access, so teammate invites were already underused. Rather than designing a separate experience, I focused on making access lightweight:
The same Project Management interface as admins, with the rest of Whova hidden
Full project visibility, but editing limited to assigned tasks
Why it served adoption: Lowering the friction to invite teammates increased the likelihood that admins would bring more of their planning team into Whova.
What I'd ship next
The MVP shipped without lightweight dependencies — the ability to mark a task as blocked on another. I argued for it because the research showed informal blockers were the most common coordination failure ("waiting on Sarah to confirm catering before we can finalize the program"). Leadership cut it for scope. We shipped without it.
I still think it would matter. The signal I'm watching: comments containing "waiting on…" or "blocked by…" patterns. If users are recreating dependencies in unstructured text, that's data that lightweight blockers earn their place in v2.
The other v2 candidate is mobile — specifically for event-day checklists. Day-of work happens away from the desktop, and checklists are the natural surface for it. The desktop MVP was the right call for validating the working model, but mobile is where event-day adoption lives.
Outcome
Within 30 days, ~18% of active organizers tried Project Management. For a new feature, getting users to take the first step is the hardest part, so this showed that the onboarding flow was approachable.
We also saw early signals that Project Management was encouraging users to use more Whova features. Organizers using Project Management adopted other key features 32% more often than those who weren't. They also started bringing teammates into their workflows.
Since we now know organizers are willing to try it, next we'll be focused on whether Project Management creates lasting habits: do organizers keep and customize their suggested projects, do teammates stay engaged, and do teams return to PM for their next event?