MediumUX Refined or Repeat Chaos?. Oasis, Ticketmaster, and the ‘25–’27… | by Zac | Oct, 2026 | Medium
Sitemap
Zac

Zac

UX Refined or Repeat Chaos?

Oasis, Ticketmaster, and the ‘25–’27 Ticket Buying Evolution

6 min readOct 18, 2026

--

Press enter or click to view image in full size
Banner image featuring phones with imagery from Ticketmaster, with a blurry concert photo in the background.

9:00 am, Saturday, August 31, 2024; I find myself fixated on my phone screen whilst walking the dog, navigating endless virtual queues and sudden error screens in a desperate attempt to secure tickets for the Oasis ’25 reunion tour. Like so many others after hours of waiting, I walked away empty handed, frustrated by a system which seemed stacked against the user.

Fast forward to the release of Oasis’ ’27 tour, and after going through the ticket-buying process first-hand again, I set out to investigate whether the system had meaningfully evolved. This case study considers whether the ticket-buying experience improved between the ’25 and ’27 tour releases, evaluating the end-to-end journey from a design and user experience perspective and proposing solutions to any prevailing issues.

The Process.

To evaluate the Oasis ’27 tour ticket buying experience, this study will follow a user-centred UX framework:

  • Understand context of use: Using the Jobs-to-be-done (JTBD) framework to define the functional and emotional needs of fans attempting to buy high-demand concert tickets.
  • Specifying user requirements: Observing users during the purchase process, gaining valuable qualitative user feedback and documenting key findings, and identifying pain points.
  • Design Solutions: Developing low-fidelity solutions that tackle any prevailing issues and enhance the user-centred ticket buying experience.
  • Evaluate against requirements: The proposed solutions would be put to users, assessing outcomes to see how well the designs perform.
Press enter or click to view image in full size
Image displaying the user-centred design process.
User-centred design process

This is an iterative process whereby the designs are continuously checked and redeveloped against the users’ context and requirements until a satisfactory result is achieved.

Evaluating the proposed design solutions are not included within this case study.

Understand Context of Use.

Jobs-To-Be-Done.

I will be using a Jobs-to-be-done (JTBD) framework to specify user needs and goals when addressing the ticket-buying experience via the Ticketmaster mobile website/app.

The following job stories have been based on my own purchasing situation, along with similar circumstances met by the users I conducted tests with. The jobs have also been partially shaped by the ticket-purchasing events from the previous Oasis ’25 tour.

Press enter or click to view image in full size
Image displaying the key for the areas that construct each of the job stories: Situation, Motivation, Outcome
Job story format key
Press enter or click to view image in full size
When I am navigating time-sensitive checkout timers and fast-moving queues, I want to see the upfront total cost (including all fees and tax) with zero surprise add-ons, so I can make a fast, confident financial decision without worrying about unexpected charges while managing my family budget.
Job story 1
Press enter or click to view image in full size
When I reach the front of the queue after waiting for hours, I want to buy general admission standing tickets at the advertised face-value price without sudden surges or compulsory “in-demand premium” markups, so I don’t feel coerced into overpaying under a ticking checkout clock or walking away from a transaction due to unexpected price inflation.
Job story 2
Press enter or click to view image in full size
When I am actively navigating the checkout flow on my mobile device, I want to seamlessly complete banking authentication and site verification steps without losing my cart reserve or being flagged as a bot, so I don’t lose a hard-earned ticket allocation to a technical timeout or false error state after waiting in line for hours.
Job story 3

Specifying User Requirements.

Test Criteria.

The stated Jobs-to-be-done formed the basis for the goals within the test phase. They evaluated the following under high demand conditions:

Press enter or click to view image in full size
Jobs-to-be-done evalute: Pricing transparency, queue-to-checkout reliability and payment security flows.

The test criteria was as follows:

Press enter or click to view image in full size

Test Methods.

I conducted a mix of moderated and unmoderated usability testing. Participants were recorded alongside their device (in view). I also interviewed participants remotely to gather their experiences.

I posed the following tasks to the participants prior to the sale going live:

Get Zac’s stories in your inbox

Join Medium for free to get updates from this writer.

Task 1:

Scenario: You manage to successfully get to the front of the queue and are presented with a list of available dates. You are wary that ticket numbers are limited, and thousands of other people are traversing the site at the same time.

Task: Review your ticket selection and proceed to the payment step. Observe the pricing breakdown carefully before entering payment info.

Task 2:

Scenario: You are expecting face-value standing tickets at £170.50 each. After waiting in line, you reach the selection screen, select the general admission options and see various ticket options under time pressure.

Task: Select your chosen tickets at standard face value, ensuring no automated “In-Demand Premium” or dynamic surges have been applied without your consent.

Task 3:

Scenario: You are completing checkout on your mobile device. Your bank requires you to switch to your banking app to authorise the payment before returning to complete the purchase.

Task: Complete payment using bank authorisation within your mobile device.

Users should experience the following flow of events in order to successfully acquire tickets:

Register interest via website, Receive email with unique code, Log into Ticketmaster, Follow link within received email, Join Ticketmaster waiting room, Pick a date, Join virtual queue, Select area of Knebworth venue, Select ticket type, Apply unique code, Add tickets to basket, Proceed to checkout, Payment authorisation, Purchase confirmation

User Feedback and Key Findings.

After analysing and sorting the responses from the participants, I listed the the most frequent areas of friction users met whilst purchasing their tickets:

Press enter or click to view image in full size
Pain points: User is forced to make a difficult decision on whether to stay in the current queue or leave on the advice of the site. The user is not presented with any warning about having to queue again if they leave the current queue. The user is unhappy about having to join a fresh queue.
Press enter or click to view image in full size
Pain point: User didn’t realise they were in a pop-up window. There was no obvious “go back” button/option for the participant to follow.
Press enter or click to view image in full size
Pain point: The display of the 2 options causes cognitive overload, trying to understand what the “unlock” button and offer code perform.
Press enter or click to view image in full size
Pain points: The window prompting the user to enter an offer code is presented, but with no additional information. User does not know if this is their only chance to use the code. If something goes wrong, is it still valid?
Press enter or click to view image in full size
Pain points: User was misinformed by the original email.
Press enter or click to view image in full size
Pain points: User is not presented with any warning when leaving the current selected date. User is not presented with any warning about having to queue again.
Press enter or click to view image in full size
Pian points: Insurance is offered during checkout, but you don’t feel you have time to read the details, leading to a potentially unnecessary addon generated due to time pressures.

Design Solutions.

With testing complete, we can develop solutions that address issues users still face when purchasing tickets in high-pressure scenarios.

Based on our participants’ pain points, low-fidelity design solutions will focus on keeping users better informed as they navigate the site, along with UI improvements to reduce confusion.

Queue Warnings.

Press enter or click to view image in full size
Low-fidelity designs that warn users when leaving a screen.

Ticket Picker UI.

Press enter or click to view image in full size
Low-fidelity designs for the ticket picker.

Unique Code UI.

Press enter or click to view image in full size
Low-fidelity designs for the offers code screen.

Tackling Dark UX.

Press enter or click to view image in full size
Low-fidelity designs for the checkout screen.

User Wire flow.

This user flow displays enhanced interactions, as proposed in the low-fidelity designs. The flow can be fully viewed here.

Press enter or click to view image in full size

Conclusion.

The study found no dynamic pricing; tickets were consistently priced as advertised, and participants experienced no checkout issues. Compared with the Oasis ’25 tour, there was no evidence of technical glitches — largely because ticket purchases were limited to dedicated sale windows. In fact, I completed my own transaction within 15 minutes of the sale opening.

However, opportunities for UX improvement remain. Additionally, initial communications from Oasis management could better manage expectations by clarifying why users might not secure the four-ticket maximum and where to enter the provided presale codes.

To address these insights, we will next present low-fidelity designs to users for feedback before developing mid- and high-fidelity prototypes.

Share your experiences purchasing tickets for the Oasis ’27 tour in the comments below!

--