Make segments and take actions for your events

Before I join the team, nearly all features were developed straight out from product requirements. Having become the first full-time designer on the team means there's a lot of UX issues to investigate. In the early days, I was sitting next to my Customer Support colleague. Anyone could see her answering clients' questions that flooded on email or phone call, whole day non-stop.

While there were so many unsolved problems of the existing product, I got delegated to work on a new product instead. When I look back, I think I should do the followings better:

Assist in verifying the new direction. At the same time, be vocal to point out what are the existing problems, find time to ground myself with actual user feedbacks, and find ways to influence the product priorities just so these unmet needs are heard.

‍

A fews months gone by, the team got the chance to address problems from one of the key feature of the platform - the attendee list.

‍

Attendee list is vital for event organizers, especially in helping to oversee and run event logistics. Collect data, make segments and take actions.

This is how the old design used to look like:

‍

My PM and I had a chat with CS. We also asked our clients for feedback through phone calls.The old design can only perform one filter at a time. The concept of "Group" is hard for users to understand. The overall layout were not leading them to take actions. Literally, organizers can't really look at this list from the angle that they want and take action from there.These feedbacks became our insights. I translated them into below "jobs".

‍When organizers take actions to their attendees, like sending RSVP invitation, approving people from waitlist, preparing for the onsite check-in counter...
‍
...organizers would want to rely on a single source of truth which contains finalized attendee data,
...organizers would want to respond to unexpected changes quickly, e.g. update attendee on the venue changes,

so that organizers can make sure their attendees can fully enjoy the event experience they originally registered for.

‍Having these understandings, I started to create wireframes and prototypes for user test. Below are some examples of redesigned elements.

‍

During the test, I will record their reactions and feedbacks.

Finally, handed off to Dev team to bake the real solution. Since PM & Dev are involved in the design review, we can ensure the design direction is technically feasible. If the development scope is over our expectation, my PM will still prioritize design first and try to make it happen.

Even though I am the only designer there, I've found supporters who can back me up.

After launched, we measure the amount of export request and the filter usage. These were some of the success metrics we defined in exploratory stage.

First, export request reduced to zero. In the old design, user can only apply one filter at a time. So when they need to see certain view, they will ask us to export for them. This was very primitive and highly against the purpose of the product. We are glad that our users can have that ability now.

Second, filter usage were not very good at the first two months. CS told us that, the filter with conditions are certainly a stronger feature, but users find it hard to adopt. Especially when the filter menu has no categorisations and the filter name can be vague or not applicable to certain users. Two months later, we look at the numbers again and it increased.

Maybe the users learnt how to use it. But this is certainly a great example to proof the importance of iterations after launched.