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