Spencer Goad
Developer & Product Designer

Events for Everyone

Redesigning event registration for multiple personas

Image alt tag

The Problem

The event registration system of Novi AMS was originally designed with one persona in mind. It made life easy for the office assistant who needed to register dozens of employees at once for a simple event. While this advantage helped set the software apart from competitors in the MVP phase, a growing user base & more complicated events quickly highlighted the shortcomings such as -

  • Double, triple, or even quadruple entry of information for attendees

  • Difficulty registering "just myself" for a conference

  • Opportunity for tighter integration with member database

My Role

For this project I stepped back from the code and into a product designer & team lead role, the code would all be up to my team!



We had some ideas on the basics of our problem and some possible solutions simply from reading user feedback. But in the research phase of this project, it was time to get more formal. My product owner & I met 1 on 1 and in groups with users from multiple types of associations - the trade associations with their company only memberships, the societies with their individual memberships, and the hybrids that might have a mix of both.

We quickly learned that while societies largely had no love for the existing solution, trade associations still felt like it had a special magic for the members. Going with a more traditional event registration approach for trade associations could result in hours of more staff time as their members would wind up calling them rather than registering online. Armed with this knowledge, we set out to try & solve this problem for both sets of users.


Based on our interviews we had two major personas -

The Office Assistant

This was the user the legacy system worked well for - they've got dozens of other staff in the office and it's their responsibility to get them all registered for the event. This user wants to login, tell you how many tickets they are buying, quickly fill out their staff information, and then move on. This user might also need to buy tickets without even knowing which staff would be coming!

The Individual

This user would quickly get fed up with our legacy system. When they went to register for a conference that involved multiple tickets (pre-workshop, full conference, dinner, after party, etc), they would have to enter their information over again for each ticket they purchased. This user just wanted to tell us their information, choose their tickets, and be done!

Mobile - Attendee First Flow

Mobile - Attendee First Flow

As we started to design, we sketched out possible user flows as solutions for both personas. Ultimately, we discovered that with our user base & the various event types in mind, we needed to provide admins an option of how the registration flow worked. For simple events - a ticket first flow, similar to our legacy system, was designed. For complex events & individuals - a brand new attendee first flow was designed. For each attendee, users would enter their name, select their tickets, and then the configured attendee information fields would appear just once even if the field appeared on multiple tickets.

For the both approaches, I mocked a couple rough wireframes and then jumped into Figma. I designed re-usable & responsive components to introduce consistency between the two flows. We settled on a multi-step process with an intent on minimizing the information presented to a user at any given time. I designed Figma mocks for desktop, mobile, & even our registration confirmation emails.

One of my favorite touches was to bring in our user's profile images into the registration process. For the office staff persona especially, this brings in a new level of personality and the ability to see at a glance who all is coming!


Where we landed with this project wasn't exactly where we thought we'd be going. We started out trying to reconcile two different ways of working, only to discover our user segments were well enough defined that we could offer two separate approaches. Ultimately this led to a simpler and cleaner solution for our end users that catered directly to their needs. No more double (or triple) data entry!