Last2Ticket — building a new e-ticketing experience
During a 5 days design sprint, we worked with Last2Ticket to help them improve their e-ticketing buying experience.
Date: April 2018
Client: Last2Ticket
Team: João A., Prashant K., Imran R., Sarthak V.
My role: UI/UX Designer
Background
The story begins in April, when The New Digital School launched a Call for Problems, inviting companies to partner up with designers from the school to work on UX projects. Last2Ticket applied and we got the chance to work together for a week. Last2Ticket is a ticketing platform that empowers event organisers (partners) and attendees with flexible e-ticketing tools. They develop a widget that allows their partners to sell event tickets online. This widget can either be on Last2Ticket’s website, or on the partner’s website, powered by Last2Ticket.
They challenged us to reduce the friction on the user login process, when buying a ticket through the widget on a partner’s website.
Understanding the challenge
It was crucial for my team to fully understand the challenge and its implications. It was a new business for us, so we enrolled in a discovery phase to better understand Last2Ticket and their needs. They have a big customer journey that can start on their own website or on a partner’s website. We needed a well-defined scope.
It was not time to jump to the whiteboard and draft solutions — we were far from that. First, we needed more insight into the product and into Last2Ticket’s business.
Exploring the widget
To gain that insight, our team gathered and followed the journey a user would go through to buy a ticket using Last2Ticket’s widget. More specifically, we went through the process of buying a ticket on one of Last2Ticket’s partners.
We explored the product to learn more about the login process mentioned in the brief and what usability patterns we could improve.
By going through the buying experience, we found out that:
- The user must login or register to buy a ticket
- The registration page had input fields we could not understand the need for
- Unexpected popup alerts came up in two situations. First, when the user logged in through Facebook and then when the purchase was complete
- The payment section has a pre-payment screen. We could not understand the purpose of the screen.
Decisions are not random. We believed Last2Ticket had good reasons to include these points listed above in their widget experience. Yet, we needed to know why.
The Last2Ticket team were the best people to answer our questions. They promptly accepted to set up a meeting with us, to for us to get to know each other and give better context about the work ahead.
We then spent the whole day before the meeting understanding what we needed clearance on. We crafted a script with questions for the client, to be presented on the first point of contact with them. We wanted to gather as much information as possible.
Visiting the client
At 10 AM the next day our team was in UPTEC, Porto, where Last2Ticket welcomed us in their office. We met the whole team there. They booked a meeting room for the morning, where we had the chance to talk to Emília Simões (CEO), Tiago Martins (Software Developer), Ana Mendes (Customer Success) and Cristina Lopes (Software R&D), generating discussion about the business, their goals and expectations.
The fact that we were working with the client and not for the client allowed us to stay on track with their objectives. By having this point of contact with the Last2Ticket team, we could better understand how we could help them improve their widget.
From the Q&A session we found that the the login/registration process was causing trouble for users. In fact, Last2Ticket partners had already asked them: “do you really need to have a login for my users?”, because they believed it was hurting their business.
Last2Ticket was also concerned about the current registration process. Partners could build registration forms as they saw fit, resulting in lengthy pages. Last2Ticket worried that a large number of input fields could decrease the rate of registration.
It was also important for our team to understand what the client envisioned as the final result for this project and its impact on business. Emília (CEO) wanted insights. She and her team trusted us to research about what was blocking users in the buying process and present a prototype solution to solve those problems. They wanted to increase the number of users who complete the buying process by 5%.
Last2Ticket did not impose assumptions on us about their users or solutions. They gave us the freedom to explore further and learn more about users on our own. That’s what we did.
Testing with users
For this test, we assumed credit card payment was the main payment method chosen by users.
We had explored the widget on our own. We met the client to get more context about some of the decisions that went into building that same widget. It was time to bring other key stakeholders to the game — users.
We wanted to see the widget in action with users using it, from the moment they would add a ticket to the moment that ticket would fall in their e-mail inbox.
What we expected
We were not a blank sheet up to this point. Meeting the client and interacting with the widget created expectations for us regarding how users would behave. We were expecting to see:
- Frustration: when users would be blocked by the login/register step, before proceeding with the purchase
- Confusion: when users would face popup alerts and a pre-payment screen during the process
The test would be a good exercise to validate these assumptions, but also to encounter the unexpected. It was our job to keep our eyes and ears open to user behaviour, looking for other pain points they would face during the session.
Testing sessions
We built a live website that embedded the Last2Ticket widget. The goal was for users to buy a ticket for a fake tech event. We wanted to recreate a real buying situation where users would behave as naturally as possible. We offered free food as incentive for the test at The New Digital School. In the end, we recruited 6 users to test the widget with, all of whom:
- Were familiar with tech (dealt with laptops and smartphones on a daily basis)
- Had experience buying tickets online
- Were using their own laptop (to keep it as real as possible for the user)
During tests, users had points of low emotional state, triggered by interface issues that resulted in a slower buying process. These manifested in:
- Users feeling frustrated when they found out that they had to login/register to proceed with their ticket purchase.
- Users feeling surprised with the number of input fields on the registration page. They described them as being “too many”. They also felt uncomfortable when the widget prompted them to share their phone numbers.
- Users feeling anxious about the popup screens and the pre-payment screen. When they popped up, users felt something urgent was happening that required all their attention. After reading the popup content, they felt it was not as important as they thought it was.
As regards the option to register with Facebook, users expressed a lack of trust in doing so. They refused to register through the social media platform. The reason they voiced was the recent scandal involving Facebook and Cambridge Analytica.
“I would rather just buy without the need to make an account”
– User during user testing session
Our team focused on solving problems surrounding the friction around the buying process. We wanted to increase the speed of that journey by working on the login/register stage, the popups and the pre-payment screen. These problems came up frequently during user testing. This had been previously reaffirmed by the client during our meeting. For those reasons, we prioritised these problems as mentioned above.
The lack of trust on Facebook could lead to less registrations through Facebook, and more registrations through the widget. That highlighted the need to work further on the registration process.
Mapping the information architecture
Although we had defined the problems we were going to focus on, we could not jump straight to designing wireframes. We were dealing with a complex widget, composed of many sequence steps and different types of actions inside those steps.
To gain understanding about its complexity, we mapped the information architecture of the widget.
By combining the findings from research and the current information architecture, we reached a solution to improve the widget buying experience.
When taking decisions, we had two assumptions in mind:
- It is totally legal and compliant to offer a “Guest Checkout” kind of experience.
- It is perfectly legal, compliant and possible for the Users to request the VAT Invoice, after making the payment.
Prioritising user actions
There is a lot of actions that users can do while buying their tickets. They can select the tickets, pay for them, ask for an invoice and download them. Yet, these actions fall into different levels of prioritisation during the buying process. The order in which these actions appear to the user matters.
We organised the information architecture of the widget, defining what would be primary and secondary actions. We did it based on the information we gathered from the Q&A with the client and the user testing sessions with users. That helped us prioritise the way we would restructure the information architecture and, consequently, the buying process.
Our research made it clear that the login and registration process needed our attention. As of today, users must login or register before proceeding to pay. This worries Last2Ticket, their partners and the users themselves. On top of that, partner’s can create their own registration process. Even if their intention is the best, they can hurt their own business by creating lengthy pages with a large number of input fields. The level of friction can grow to an alarming level.
We decided to classify the login/registration as a secondary action. Logging in or registering does not help a user buy the right ticket. It was in fact slowing the buying process down. We proceeded to put actions into the two categories.
Primary actions ensure that the user buys the right ticket. Under primary actions we included:
- Ticket selection
- Payment
Secondary actions give the user access to extra information that does not involve buying the right ticket. Under secondary actions we included:
- VAT Invoice request
- Ticket download
- Login/Registration
Thus, we moved primary actions to the beginning of the buying process, leaving secondary actions to last.
Introducing Guest Checkout
By agreeing on a sequence of primary followed by secondary actions, we implemented a Guest Checkout process. Users would be able to proceed with the purchase without having to register on the widget. After the purchase is complete, users can perform secondary actions.
Our goal was to decrease the frustration felt by users, by not forcing them to login or register. Facebook has a negative impression on users, so we removed that login/register option.
Yet, for the seller, it is crucial to have a way to contact the buyer. Not only to guarantee they get the tickets, but also to alert the user in case of any changes to the event. Thus, we added an e-mail address input on the Payment Details page. This ensures that the tickets will be sent to that address.
We wanted to move the option to request a VAT invoice to the end of the flow. To allow for that, it is required to have access to the user’s country. We added a new input on the payment screen, where the user must enter a country, so that it becomes possible to request the VAT invoice after the purchase.
We also removed the popups and pre-payment screen. We wanted to reduce anxiety on these steps thereby creating a clearer, more trustworthy payment process.
Users can now perform secondary actions after completing the primary ones. This keeps them focused on what matters the most thereby reducing friction on the widget.
Apart from our team, other teams in The New Digital School were working to solve problems in the widget buying process. They were focussed on dealing with the desktop environment and we saw the opportunity to have an impact on the mobile version. Owing to shortage of time, we adapted and applied the findings from the desktop testings to the mobile context.
When building the new screens, we also tackled usability issues found in the widget. We applied mobile best practices of usability patterns, bringing important actions to the front.
Going beyond — improving the experience for users and event promoters
After finishing our prototype, we saw room for improvement. We went beyond and analyzed the buying experience from a broader spectrum to understand what we could improve further.
This led us to develop a new refund process for Last2Ticket and their partners.
Refunds can be an awkward topic to discuss with a client that sells tickets for a living. “You will lose money by accepting refunds”, one would think. Refunds usually aim to delight the customer experience but end up hurting the business. Therefore, the key question here was:
“How can we provide a refund process that benefits users and the business?”
We wanted to create an impact on many levels of the business:
- Help event promoters understand more accurately as to who is going to the events. Event promoters don’t want empty seats. We wanted to help them get a better sense of who is attending an event and who is not.
- Increase the revenue per ticket sold. Tickets go back to the Last2Ticket marketplace when they are refunded. This means they can be resold and, therefore, generate more revenue for the business.
- Increase ticket sales. Buying a ticket is no longer a big compromise. Having the refund option gives the user more confidence when buying a ticket. If something goes wrong, they can get money back.
- Increase brand confidence. A business that understands the legitimacy of a refund is a business that cares for the user. When a user refunds a ticket it is never a happy moment. This new flow provides, at least, a painless process to do so.
Getting more context
We decided to focus on refunds after doing research. We went to the streets of Porto and did guerrilla interviews, trying to get as much from users with the time we had.
This exercise helped us widen our perspective on the customer journey. We found out that people do sell their tickets when they cannot attend the event they booked for. Facebook groups are one of the main marketplaces to exchange tickets online. And to sell a ticket, people need to post an ad, find a buyer, meet the buyer (or send the ticket via mail) and receive money. It can be quite cumbersome.
At the same time, we didn’t lose touch with Last2Ticket; we kept in close contact through Slack for further communication. We found that Last2Ticket does provides a refund option, but only for two of their biggest clients. [Data from the refund process, prices and conditions has been redacted owing to client confidentiality].
Our team saw the opportunity to create a better experience for the user who wants to refund a ticket, while making it relevant for the business.
Solving the problem
Creating a user journey helped us understand how the refund process could work. It also highlighted user behaviour and emotional states throughout each phase.
We built a refund process that allows users to get back some of their money when they ask for a refund. On top of that, this process puts the ticket back into the Last2Ticket marketplace for it to be resold.
We created the screens for the refund interaction, respecting the user journey. It starts from the moment the user gets an e-mail with tickets to the moment the user gets the refund. The refund option will be accessible not only from the e-mail, but also from Last2Ticket’s website or the partner’s website. This is important to respect other user journeys that don’t start from the e-mail.
Delivering it to the client
For 5 days we followed a design process that was, at its heart, iterative. It was also a collaborative one, courtesy of Last2Ticket’s availability to answer our questions. Our team outlined what our vision for that week was, but nothing was set in stone. However, one thing was agreed from the beginning — we wanted to deliver our work in the best and most impactful way.
On the last day of the week, the Last2Ticket team attended The New Digital School for the final presentation. We did not present a bunch of dribbbled slides with interfaces, but actually guided them through the prototype, explaining the decisions we made. It was important for the client to see where each decision came from.
“The experience [of Last2Ticket] with The New Digital School was amazing! The challenge was well executed and the dynamic between teams created new and unexpected results.
The TNDS methodology and the dynamics applied to the challenge resulted in valid, valuable, attentive and business oriented inputs. Also, they allowed to go even further, bringing disruptive ideas and processes.”
– Emília Simões, CEO of Last2Ticket
Learnings
The process should be flexible
Throughout the project we had to change methodologies and we introduced new ones. A set-in-stone process would not allow for this. Sometimes, plans change and that is OK. The important part is bringing more value to the process.
Broadening the perspective
To get to the refund process, we were forced to increase the scope of our perspective. Doing regular checks on how broad our perspective on the project is, can uncover new findings. In this case, we tackled a pain point the client was already considering, which validated our work.
Fidelity is a marathon, not a race
Working on exciting solutions can make us jump from research to a working prototype in a matter of hours. That can hurt the project, because moving too quickly can lead to taking decisions without understanding the full-scope of the problem at hands. When we realized we were moving too fast, we tried to keep the team in check, reminding us to respect the hierarchy of fidelity we defined at the beginning.
The delivery is an experience
Don’t limit the client presentation to a bunch of slides with iPhone screens. We went through the prototype with the client, presenting research findings, assumptions and our process. It was not a presentation, but an experience, with the client acting as user.
