Case Study: Open Social
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:
• 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.
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.
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.
Reflections and conclusion
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.
• Ticketing settings are currently decoupled from creating the event settings, which could also be linked
• The current design shows both ‘member’ and ‘non-member’ options, but the system already knows due to log in.
• We have to think and iterate further on distinguishing between different prices for different roles on the platform.
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.