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.
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)
For this project, we had 9 days in total.
Our team existed of 3 people. Dagija Kugeviciute, Maria Arranz Dominguez and me.
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?
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.
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.
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
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.
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.
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
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.
- 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).
- 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.
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.