OpenSocial: adding a ticketing system to the event feature of a community platform

Events are one of the core functions of Open Social. While the payment process is available, the next step to improve the product is to add the possibility of buying tickets for events that are hosted on these platforms. Organizations should be able to access and personalize the whole event flow, from start to finish.

Role

I worked on this project as a UX researcher and project manager. Main areas of responsibility:

  • Project management
  • UX analysis (user flows, sitemaps, personas, wireframing etc.)
  • Lo-fi prototyping (basic flow and interactions)
  • UI Design (desktop flow)

Duration

For this project, we had 9 days in total.

Team

Our team existed of 3 people. Dagija Kugeviciute, Maria Arranz Dominguez and me.

 

The challenge

Open Social was designed for connecting people within communities so that members can communicate easily, create groups, collaborate, interact and have a seamless sharing of ideas, experience and expertise.

We have, however, observed that Open Social’s event feature is not creating an overview for event managers, and is holding back the attendee from being able to access and purchase tickets all in one place.

This leads to every community relying on different external platforms, and therefore induces less engagement within the communities, which for many is the main source of company revenue.

The main current issues with ticketing for the event manager side:

  • Unability to receive an overview of data and seller information
  • Usage of different tools to create an event, create tickets and handle the payment
  • Unability to create an overview of attendees being (non-)community members
  • Having to manually reach out to every attendee on its own

The main current issues with ticketing for the ticket buyer side:

  • The length of the buying process
  • Ticket accessibility after purchase
  • Requirement of too much personal information
  • Crashing or lagged website loading

This leads to the following How Might We statement:

How might we improve Open Social’s community platform, so that event attendees can purchase and access their tickets seamlessly; and event managers have an overview of all attendees in one place?

The solution

We conducted semi-structured interviews with 3 event managers, and talked to 4 people from the Open Social community (web developers, marketeers and product managers) collected survey answers from 5 event managers to understand the problem space and their overall experience of creating events and adding tickets. For the attendee side, we conducted semi-structured interviews with 5 regular event ticket buyers, and received 26 answers to our in-depth survey. 

This helped us to explore different problems and go deep down into a few major issues that they currently face.

User goals and jobs to be done

We then created two global user personas and user journey maps based on these faced problems and experiences. One for the event manager side, and the next one for the event attendee side.

Persona and user journey map – Event Manager side

Persona and user journey map – Ticket Buyer side

While this was very helpful, we still wanted to clarify specific Jobs To Be Done in order to get a clear overview of the user’s tasks. Since Open Social’s clients are very diverse in both demographical, personal as well as working position (CEO to event volunteer), we wanted to focus on tasks and goals instead of a “traditional” persona. 

Competitor analysis

To get a main overview of the current market and our competitors, we did a competitor analysis. Focusing on main features, the unity of the flow and visual features – we got a good overview of how OpenSocial’s ticketing system can set itself apart from the competition.

Minimum viable product

In the next stage, we first focused on the Moscow method to see what features we could focus on for the minimum viable product.

The ticketing feature on the Events of Open Social’s product allows the event manager to:

  • Input ticket type, price (free/paid/donation) and quantity
  • Customize: payment method, ticket holder information,
    additional community joining fee and downloadable invoice option.
  • Access an intuitive dashboard page that shows an overview of the ticket sales

This function should relieve event managers from having to use external tools for ticket creation, management and overview.

The ticketing feature on the Events of Open Social’s product allows the event attendee to:

  • Select the appropriate ticket type, quantity & payment method
  • Fill in the required information
  • Access the ticket in a form of QR code, downloadable PDF & receive the order confirmation

This function should allow event attendees to quickly buy and access tickets without spoiling the event experience.

Product structure

Afterwards we decided to make a sitemap so we could better understand the user’s paths and the future structure of our platform. Thereby, we created the main user flows to get a grip on the structure and user behaviour within our product.

Sitemaps for event manager and attendee side

User flows for event manager and attendee side

Prototypes and iterations

I’m in huge favour of prototyping and iterations for a lot of people to test.  For this project, we first drew low fi’s to get aligned on the structure – after which we created mid fidelity prototypes in Maze to validate our ideas. Most feedback came on the manager side, but we also got some interesting points on the attendee side – mainly focusing on limiting extra steps and clicks. For the manager side, it was mainly focused on the structure and naming: on where to find what.
First feedback was on the dashboard. It was not clear where it could be found, and it was not clear that the attendee list was moved to within the dashboard. When we asked people to go to the dashboard from manage tickets – we saw them click anywhere but the details section. We therefore moved ‘organizers’ to event details, and created a separate space in the menu for the dashboard, which we named “event data” to clarify.
Second, we removed the select button from the event attendee side. First, people had to click twice: first select the amount, and then click select. We removed this button to reduce extra time for the user, since the change can be already seen in the number and in the total amount below.

We adjusted the way a manager can add tickets and make them definitive. First, we had no clear way of adding the tickets and then finding a way to give a cue to the user that the task was succesful. After this user feedback, we changed colors and added a toggle after adding the ticket, and the add button changes to edit and delete.

Last example: we added a publish event button to the event manager side. To ensure that potential attendees cannot see events that aren’t ready yet. With this extra check button to put live, managers can first review whether they added all the tickets and important settings correctly.

Mid fidelity

Below, there’s a few examples of the mid fidelity prototypes as we used them to test and iterate with.

Lastly, we created a flow overview for mobile for the event manager side – to clearly see how the flow is when you make it flat and you keep it to the basics.

The results

After many iterations, our final mid fidelity prototype for both sides (and 3 formats: desktop, mobile and tablet) reached a direct success rate for our user goal during testing that we were very content with.

  • For the event manager side, the direct success rate went from 53% to 89% (15 people)
  • For the event attendee side, the direct success rate went from 67% to 98% (4 people)

This is why we decided to go with the high fidelity prototype, in the style of one of Open Social’s biggest clients: the Greenpeace community.

High Fidelity Prototype – Ticket Buyer side

High Fidelity Prototype – Event Manager side

Reflections

Looking back at the project and the product itself, there are a few points I would have done differently now or that I would improve.

Manager Side
  • The current design shows both “Member” and “Non-member” options, but the system knows who the user is since he/she/them is logged in to the community. Hence, only one option should be shown. There are no settings for this yet when creating the ticket type.
  • Ticketing settings are currently decoupled from creating the event settings, which could also be linked. For example, in the event creation phase you can set a maximum amount of attendees, and in the ticket creation phase you can create more tickets than maximum amount of attendees allowed. Since this could create confusing for an event manager, we should bring this more closer coupled.
  • We have to think and iterate further on distinguishing between different prices for different roles on the platform. For example, a non-member pays €100, a corporate organization member pays €80, and an individual organization member pays €20. Besides, we should think about different tickets for different access levels for an event (for example: only watching a Zoom stream or talk to the main speakers afterwards).
Attendee Side
  • Currently, on desktop, the purchasing flow requires scrolling for every step. This is caused by the event details and progress bar that take up too much the screen. In a next phase, I would test with making this more compact.
  • If the event is a free or donation-based event, there’s a different call to action than “buy tickets” – which on mobile is moved to the spot of the “follow/unfollow content” button. This may create confusion for the the ticket buyer who uses the system for all types of events in terms of costs.

Conclusion

Creating two sides of a flow (both the ticket buyer and the event creator) for three different devices (mobile, desktop and tablet) made the project really ambitious and maybe the scope was too big for the given amount of time. But, on the other hand, that is also a really good learning for me and us as a team to evaluate on project time and the amount of work.

However, to end on a positive note: while there are a lot of improvements that can be made, I am very proud of what our team accomplished within this short amount of time. I’m also very glad with everything I learned from this project, and looking forward to using my improved skills for my next projects.

Category:
Scroll up

No posts were found for provided query parameters.