Why I have (some) sympathy with the people behind the Olympic ticketing website
It seems that like most of my Twitter timeline I spent a good deal of last night pounding my fists on my laptop keyboard trying desperately to get any joy out of the London 2012 Olympics ticketing website. After a while, hypnotised by the queue animation graphic, I got into a zen-like state where I began to ponder how you could possibly end up designing a system that worked this way.
Now, I’ve probably got more sympathy than most with the people who built it, because I’ve spent much of my career working on big websites in the public eye that need extremely elastic capacity planning for high load spikes, and which are going to cause a media incident if they fail for any length of time. I’ve also, with @solle, had more than my fair share of abuse and complaints over the ticketing system for London IA, where demand out-strips supply.
It struck me that there a few interesting factors that might or might not be at play here:
The power of the risk register
On the assumption that a seven year project run mostly by the civil service, NGOs and other public servant types means the system was designed and built in a waterfall fashion, I’ll bet you that somewhere amongst the lengthy SLAs and contracted agreements there is a risk register, and that one of the top items on it is “The ticketing website infrastructure might collapse under heavy usage, and cause negative publicity for LOCOG and the Olympics. Likelihood: High. Impact: High”
If you view the system through that prism, at every step you would prioritise resilience over dynamism. The current set-up allows information to be heavily cached - the search results pages and the pages where you “request tickets” require minimum real-time processing of information or personalisation. It is only at the “request” stage that the ticketing engine has to kick in at all and really do its thing. That strikes me as an approach you would take if at some point you’ve decided you would rather serve a potentially inaccurate pages about ticket availability rather than no page at all.
No, not the legacy of what comes after, but the legacy of what went before. I’d wager that, just as with airline ticketing, somewhere deep in the ticketing system the suppliers sold to LOCOG, it ends up having to touch a gnarly old transactional database running on a 1960s mainframe, with a programming interface into it that requires COBOL. Or something eye-widening like that anyway.
I’d also wager that the technical architects running the system have been arguing for years that they need to do the nine months work to retire and replace that bit of the system, but that their bosses can’t see the value of clearing tech debt, because it doesn’t add new features or appear to have an immediate cash ROI.
Events, dear boy, events
The ticketing system design has been swept up by events. I can’t imagine that the original scenario planning for it factored in that a media storm about empty seats on days one and two of the Games would lead to the constant releasing of tickets overnight for events scheduled in the next couple of days.
Remember, until the day before the Games started, we all thought, with the exception of the football, that the events were all pretty much sold out, and that everybody would actually turn up. I bet the team maintaining the system were expecting to have a very quiet couple of weeks, with only progress by either of Team GB’s soccer teams driving demand, and a few returns by people who had sudden family or business commitments on the supply side. They can’t have expected to handle more than a trickle of new tickets becoming available.
Having said all of the above, some of my favourite ever comments on the Guardian website were the ones that tried to diagnose some technical problem with the site on the basis of no knowledge whatsoever of our systems or process, and, there you go, I’ve just done the exact same to the Olympic ticketing people. Ho hum.
There are, I think, three specific lessons for UX designers in here though, whatever the underlying technical causes and managerial decisions.
Your user experience is not your deliverables
I bet there are some great wireframes and final designs somewhere that explain how that “Reserving tickets” countdown clock and animation works. And I’m sure they have lots of reasoning behind them, like disguising the background page refresh whilst still showing the user something is happening.
But I wonder the extent to which they tested the actual user experience of sitting in front of it for twenty or more minutes, only to have no tickets at the end. The user experience is not your beautiful design, or carefully thought through deliverables. There is a case to be made that you’d have a better user experience if the page just said “Sorry, we can’t process that request at the moment” any time the queue was over ten minutes, rather than putting you into a queue where fulfilment is unlikely.
Copy is king
As far as I can tell there have been no major or minor revisions to the copy as you go through the ticketing prices since either the Games started or since the situation with the resale of empty seats became a live media issue. Getting an error message that says you might not have been able to buy a ticket because tickets don’t go on sale until <% some date in the past %> is sloppy. Services need to adjust their copy to reflect the experience users are having. In this case, even a message as you enter the ticketing process along the lines of “Yesterday, 120,000 users applied for 3,200 available tickets” would help manage user expectations.
A unique design problem
One of the great things about UX is watching your designs in use, iterating and improving them, and then measuring success (or otherwise). That is hard to do with a system like Olympic ticketing - you only really get one shot at it.
And it isn’t as if the team in Rio can learn a lot from the London experience - the technical landscape is very different from when tickets went on sale for Beijing, and will be when Rio starts selling tickets again. I’d imagine that the focus on designing for Rio has a much heavier emphasis on mobile than London 2012’s digital presence did - after all London won the bid some 18 months before the first iPhone was announced.
As I basically said last night on Twitter, SWEET JEEBUS I JUST WANT TO GO TO THE OLYMPICS.
“Keeping the Torch Burning: Terror, Protest and the Games” is an alternative history of the Olympic Games, one that focuses on the social and political events that have defined each competition. Nationalism, separatism, feminism, racial equality and human rights ring loud in this Guardian Short, written by Martin Belam and uniquely told through first-hand reporting from the Guardian and Observer.
“Keeping the Torch Burning: Terror, Protest and the Games” - £2.99 on Kindle
You're bang on about the copy and this is something I'm planning to blog about too. That 'tickets will go on sale at 11:00am on 08 June' message is sloppy. There's absolutely no excuse for it. I bet they could fix it today, if they wanted. And I bet they won't.
I've noticed the system seems to have a lot in common with Ticketmaster's standard ticketing process for gigs. It follows a very similar process of checking for and allocating tickets only once you've gone through a CAPTCHA - and actually, the same thing can happen with popular gigs. You search for tickets, only to find there aren't any left to allocate to you.
Just goes to show that what works ok when selling tickets to the 20,000 capacity dome isn't necessarily the right approach for a multi-session, multi-venue event where tickets are released unpredictably and demand is astronomical.
John M beat me to it. I was going to say that the most likely cause for this scandal is that Ticketmaster have tried to shoehorn the Olympics into their existing system (gig = olympic session), but it doesn't scale. It really doesn't look like a system designed from the ground-up and it wouldn't make any financial sense for Ticketmaster to build a new one. The pitch was probably that they already have a system that already does more-or-less everything that's needed ("we just need to tweak a few things").
To have sympathy with an organisation, because they way they do things (assumed waterfall, the shortcomings of which is very well documented) - is flawed - kind of misses the point.
They clearly didn't take key things into account, such as UX, and selling tickets in real time during the games; and for that the site can be considered an almost total failure.
With the budget they had - this isn't rocket science.
ref - my blog post on this
Thanks for popping over to comment Nick - I think your blog post is a fantastic exposition of everything that is wrong with the usability of the site, no doubt about that. I think I was coming more from the angle that I went to bed last night thinking "How could you have possibly got yourself into this mess? If I'd designed the system, what could possibly have been the constraints that would have left all my good intentions by the wayside?"
True, true and true again. Any of us who have built websites knows the deep truth of this. We want things to be ace. They often are a bit rubbish for reasons we didn't foresee at the time.
My advice re: tickets - get yourself some for the Paralympics. I picked up tickets for two families (4 adults, 3 kids and a senior) this morning for an evening of Athletics on 3rd Sep, all finals, for £100. Result! :-)
I disagree. I think getting websites like this is quite hard. Which is why they are so often not very good. Maybe it's not *rocket science*. But it's not easy either.
Sorry Tamsin which large websites are not very good?
Facebook? BBC? Google? Amazon?
It's not 1999 - generally big websites work reliably these days.
Sure in political situations, with legacy technology & vested interests there can be things that stifle a website. But this was a greenfield project; there's no excuse for screwing it up.
"It really doesn't look like a system designed from the ground-up and it wouldn't make any financial sense for Ticketmaster to build a new one."
And at the same time, Ticketmaster one of very few organisations with the in-house experience to run it. Captive markets correlate fairly highly with problematic UX, especially in this case, where there's not much space for iterative improvement or rapid deployment.
I had the pleasure of seeing the booking screen for tickets in an Olympics box office the other day. It was like the ones you used to get in travel agents in the 80s. Text based interface, so probably does a mainframe - hence the batch processing and lack of real-time availability. Powered by Ticketmaster... Software seemed to run in an emulator called 'PCI'.
Yes but at any point over the last few weeks there will have been only a few thousand tickets at most for sale. That is not difficult to manage at all. It is as if the system was built to issue tickets for a lottery and then do bookings offline and nobody even thought about how to deal with real-time tickets and returns.
Damn you, Belam. I come to your blog expecting to read an excoriation of the ticketing site. In fact, your name was first to mind as I tried to get tickets to synchronised swimming earlier this month. And then I discover this: a well-reasoned, fair-minded useful explanation of why things go wrong.
Looking back, it did seem like a game of "hunt the ticket" on the site. :)
It seems like a lot of the UX comments on the topic have mentioned the reliability/stress-testing of the system. I'm inclined to think that it's much more to do with the communication of the availability of tickets. I think I'm right in saying that much of this trouble was with the elements that were bespoke to the Olympic site, rather than Ticketmaster's system overall.
On the whole, it seems that it's the ticket hunting that has caused users to perceive the site as unreliable.