Open Social: adding a ticketing system to the event feature on a community platform — a UX/UI case study
In our final project at Ironhack we collaborated with Open Social who gave us a challenge to improve one of their core functions — events.
Open Social is an open-core software-as-a-service (SaaS) community engagement platform with a vision to create a pro-privacy, anti-monopoly and open web that inspires trusted connections and collaboration. Open Social’s software is used by over 1000 organizations which include some of the biggest international NGOs such as the United Nations and Greenpeace, to create their own customizable online community platforms.
While the payment process is available, the next step to improve our product is to add the possibility of buying tickets for events that are hosted on OS platforms. We want organizations to be able to have the whole event flow from start to finish on the product.
A responsive and well-integrated ticketing system designed for two flows that allows:
- Event Managers — to setup the tickets;
- Event Attendees — to purchase & access the tickets.
- Visual Design of both flows on a selected platform (desktop, tablet or mobile)
Duration of the project: 10-day design sprint
Setup: team of 3
Tools: Figma; Maze; Google Suite; Trello; Otter, Pen & Paper
We began tackling the challenge with planning 2 weeks roadmap on Trello while keeping the design thinking process in mind.
WHO ARE WE DEALING WITH?
Firstly, we wanted to find out how the direct competitors of Open Social (SaaS community building platforms) approach events to identify our ideal position in the market. It appeared to be rather challenging to find the exact features since the majority of the competitors are secretive about their products allowing to download demos on request only. From what we could find, we created market comparison chart based on two themes relevant to our challenge.
Hivebrite seems to have the most advanced ticketing system for events within the community which allows online payments, variety of ticket options, and enables the event managers to raise funds during event registration. Ideally, OS ticketing feature would be just as advanced with potentially even more customizable features relevant for each community.
Best ticketing practice feature comparison
Instead of focusing too much on the direct competitors which do not allow easy access to their products, we chose to research the general event management websites more in depth. We analysed the best ticketing practices both from the event manager and ticket buyer sides and made a feature comparison chart. Later in the design process it helped us decide which ticketing features to prioritize.
Quantitative & Qualitative User Research
Now that we had a rough understanding about the event creation and ticketing in general, we had to find the answer to the most important question — what do the actual users of events experience?
Since the challenge required designing two flows, starting from the user research we split each stage of the design process in TWO to empathize with both sides — Event manager and Event attendee. Let us begin with the former.
In order to get a more accurate understanding of the problem we wanted to focus on the experiences of the event managers who use OS platform for organizing events. Although due to the time pressure the number of survey answers received was not as high, seeing the answers to the open-ended survey questions combined with the qualitative research (3 interviews), still proved to be very insightful.
DEFINE — WHAT IS THE PROBLEM?
Once we had the data from the user research, we created an affinity diagram grouping it by themes and pain points. Then each of us voted on the pain point which we found important to solve and selected the following — event managers don’t have an overview who paid/attended the event.
From here we created a HMW statement focusing on that particular pain point.
As Open Social’s platform is used by over a thousand of different organizations around the world, we wanted to avoid representing only one type of community by creating the usual user persona based on demographic and psychographic data. For this reason, we created Tobias representing all the organizations and mainly focusing on his goals and frustrations instead of specific features.
Creating a storyboard helped us to clearly visualize what the event planning looks for the event managers when they need to use external ticketing platforms and do not have a clear overview in one place.
The current User Journey Map creation was the following step to even better empathize with the event manager because now clearly seeing the touchpoints, we could identify two opportunities — providing a dashboard for event managers showing the information about attendees, payments and tickets sold as well as customizable ticket options.
Using the value proposition canvas, we identified some of the main jobs to be done by Tobias and created job stories.
The user research on the attendee side was easier to conduct because we targeted any person who has ever purchased a ticket for an event.
After creating an affinity diagram, we again voted on the problems to solve. However, this time we found two of them equally important — the process of purchasing a ticket often takes too long and that the tickets can be difficult to access. We also voted for the lack of different payment options available but later agreed that it is closely related to first problem — slow ticket purchasing process.
From here we created the HMW statement for the event attendees.
Just like Tobias we felt that the event attendee user persona has to be more focused on the needs and problems instead of their character traits. Meet Lara a community member who wants to attend an event.
Again, we sketched a storyboard to better imagine what Lara is going through when buying a ticket.
Creating the current user journey map of Lara pointed us to a couple of opportunities — the variety of payment options which has already been considered earlier and only collecting the necessary personal details during the purchase. Without doubt, this would help to speed the ticket buying process as well.
Below you can see some of the job stories created for Lara’s case:
Bearing in mind that the main goal of OS is connecting communities and the lack of ticketing feature within one platform causes a number of pain points for both event managers and the attendees, we created the problem and hypothesis statements taking into consideration the both sides.
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 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.
We believe that adding a ticketing feature to the event platform within OS will create a clearer overview for event managers and give event attendees the ability to access and purchase tickets all in one place.
We will know we are right when we see more engaged members within the communities, and a higher revenue generated by events for the company.
IDEATE & DEVELOP — SOLVING THE PROBLEM
To clearly visualize where the ticketing feature would go, we created partial sitemaps only showing the placement of events within the platform. It must be noted that there are several paths where events can be created because the menu and structures of Open Social product are customizable per installation.
EVENT MANAGER’S SIDE:
EVENT ATTENDEE’S SIDE:
Which features must be added?
Now that we have defined clear needs and pain points of the users, we had to prioritize which ticketing features can solve the most user problems. We created MOSCOW chart by taking into consideration the features which are commonly used in the best ticketing practices and the ones mentioned in the user interviews. Note: some of the ticket features which attendee sees when buying the ticket depend on what is set by the event manager (customizable) while others may be integrated within the OS system itself. For this reason, we put (M) for manager and (A) for attendee next to each feature to be able to differentiate them easier.
Must Haves and Should Haves of the Moscow Method guided the establishment of the Minimum Value Product Statements.
MVP Statement — Event Managers
The ticketing feature on the Events of Open Social’s product allows the event manager to:
- Input: ticket type, price (free/paid/donation) & quantity
- Customize: payment method, ticket holder information,
community joining fee and downloadable invoice option
- Access an intuitive dashboard (event data) 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.
MVP Statement — Event Attendees
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.
User flows & Use Cases
Now that we decided which features will be included in the ticketing, we created the user flow diagrams with an intention to optimize the user’s ability to accomplish a task. Afterwards we employed use cases describing the main and alternative user flows to help us identify any potential errors and to better understand how our users will accomplish their goals.
Now that we had identified clear user flows, we could finally draw some low-fidelity sketches to clarify how we will approach the actual design with incorporating the most important features we agreed upon.
Then we proceed with the mid-fi prototypes for 3 devices — desktop, tablet and phone to show responsiveness of the design.
Testing and and iterating
After the mid-fi prototypes were ready, we conducted usability tests by Maze and also received some feedback from our stakeholder. As you can see in the heatmap most of the users could not locate the dashboard.
Below you can see the detailed feedback we received from the users during our user feedback sessions and several examples showing how we iterated on the prototypes.
Testing and and iterating
On the attendee side the usability score was quite high — 80 and we did not have to make as many iterations. Below is the main feedback and what we changed.
Design System & Style Guides
Finally, after all the iterations on the mid-fi prototypes we were ready to design high fidelity prototypes. In order to seamlessly integrate the ticketing feature in already existing Open Social product we were following the already existing design system in terms of typography and cards.
However, the colours of OS software are customizable per installation accordingly to the style of each community to make them feel at home. For our hi-fi prototypes we decided to use the colour scheme from one of the communities. At the bottom we showcased the buttons and elements which we created for the new ticketing feature.
We prioritized creating the visual design of both flows for desktop because we observed from the user research that it is the most commonly used device for purchasing tickets and creating events.
Below you can see the final result which was created by taking into account the usability test results.
The video walks you through the process of creating the tickets, publishing the event and checking the event data afterwards.
The video walks you through the process of buying the tickets for an event, and accessing them via e-mail.
- Implementing more features to improve user experience such as: Waiting List, Event Notifications, Ticket Cancelation & Refunds, Automated Event Capacity, Ability to set precise ticket sales dates, Customizable Ticket Design
- Evaluate whether implementing tickets in the main event creation flow would be more intuitive for the users
- Analyze more use cases such as community joining fee
- Design and test the high-fidelity prototypes for all devices
Insights and learnings
Throughout the project having several interviews with Open Social team (product manager, CSM, marketing consultant and web developers) was invaluable in terms of gaining an understanding about their clients, the functionality of OS platform and event management practices in general. However, I feel that due to a very limited time of the sprint, focusing on one side of the ticketing system more in depth could have been a better practice. A narrower focus could allow us to create an even more consistent and intuitive design for the users.
Overall, this project showed me how much I grew professionally and personally during Ironhack UX/UI Design Bootcamp — from collaborating efficiently with a team under time pressure to being able to employ design practices while working with a client. At the same time, I am excited to see that there is a lot to learn and improve. I am looking forward to all the discoveries that lie ahead of me in the career path of a UX/UI designer.
Thank you for reading!