Parsimony, and why the simplest solution in web design isn’t always obvious

The current Ronnie Scott’s website was commissioned many, many years ago, when the ecosystem for selling tickets online was much less developed. There was no Eventbrite or DesignMyNight or TodayTix back then, but more crucially — if you can believe it — there was barely even a Spektrix or a Ticketsolve. (When the current Ronnie Scott’s website launched, Spektrix only had one client.)

As a result, if you were a venue looking to sell tickets online, you either had to invest in an older ticketing system designed primarily for big theatres and concert halls, or you had to hand over the keys to a third party like Ticketmaster.

Or, like Ronnie Scott’s did, you could commission a custom website that handled all the ticketing directly, right there in the CMS.

That decision might seem bananas in 2022, now that we do have Spektrix and Ticketsolve and about a zillion other online ticketing platforms, all of which can be easily integrated into your own website. The sheer success and availability of these platforms has very much shifted the goalposts of this kind of discussion. In fact, our initial advice, when we were pitching Ronnie Scott’s, was that they should use one of those established systems rather than getting us to build a different bespoke solution into a new website.

That’s parsimony in action: the simplest solution is to use something that already exists, and that you know can do the job.

But the staff at Ronnie Scott’s were unconvinced. After all, they’d been using a bespoke system for years, and while it wasn’t perfect it had served them well. And more to the point: it was free of any per-ticket fees or commissions beyond what they owed their payment processor for taking the card payments. Hundreds of thousands of people go through the club’s doors each year, so compared to the ongoing costs of a third-party ticketing platform, the one-off project costs of a completely bespoke website-based system still seemed more attractive on paper.

So they challenged us to look at the problem in more detail, and work out whether, in 2022, a bespoke, website-based ticketing system could still be the right solution for them.

Enter parsimony, part two.

It’s a truth universally acknowledged, that a venue in possession of a ticketing system, must be in want of a website bodge.

Anyone who’s worked on a ticketing website will tell you this. Because ticketing systems have to serve hundreds of different clients consistently, when a single client needs something a little bit out of the ordinary, it usually means a complicated workaround behind the scenes. One client we work with, for example, runs classes that you can pay for at different intervals over the year — and they use dozens of different “memberships” within their ticketing system to facilitate these different intervals.

To make sure that workarounds like these don’t translate to confused customers on the website — i.e. “I’m not a member, why am I being asked to buy a membership?” — web developers usually need to conceal that kind of complexity with a bit of extra custom code. All of a sudden, using a prebuilt solution no longer seems so parsimonious: you’re using one system to do something it wasn’t designed for, and hiding the seams with another system you have to build and maintain yourself.

For most venues, the cost-benefit analysis here still makes sense. Yes, you have to bodge one thing, but in return you get all the other standard ticketing system features that otherwise you’d have to spend significant time and money rebuilding from scratch: seat pickers, and access control, and a method to render ticket layouts for printers.

For Ronnie Scott’s, though, when we really started to dig into it, we realised the cost-benefit analysis wasn’t so straightforward.

One of the things that makes Ronnie’s such a special, charming venue, for example, is the old-school, personal touch they still have. When you book, you never actually receive a ticket, nor do you have to wait at the door while someone fumbles around with a smartphone trying to scan a barcode. Instead, you just get put on a list — an actual, paper list! — and the maitre d’ greets you by name and crosses you off when you arrive.

Similarly, while you can pick from different tiers of seating when you book, the seating plan itself changes multiple times per day, as the staff split and squeeze together tables before each performance to accommodate different group sizes, or move tables around to account for different sight lines. A seat-picker function would never work with this mercurial system.

In short, when it came to all those standard features you get for free with a ticketing system… Ronnie’s didn’t really need them. And since that meant we wouldn’t have to build them ourselves, not having them suddenly stopped being much of a cost.

If anything, in fact, setting up a fully-featured ticketing system started to seem like the opposite of parsimony, drastically overcomplicating things when what we really needed had far fewer moving parts.

Would we recommend that every venue get rid of their ticketing system? Of course not! (We only think you should get rid of your What’s On page.) The circumstances of our project with Ronnie Scott’s are unique, and a bespoke system absolutely wouldn’t be right for everyone.

Still, we’re confident that for Ronnie’s, any costs are still significantly outweighed by the benefits we’re reaping from the bespoke approach. Setting up shows on the new system is simpler than any ticketing system I’ve ever used, because it eliminates all that extraneous ticketing stuff we don’t need. There’s no more defining venues, or seating plans, or pricing layers, or performance types, or ticket types, because we’ve largely been able to predefine those things based on the well-established patterns of Ronnie’s business.

We’ve also been able to make it much easier for the staff who have to sell tickets from the back end. Because the system doesn’t need to serve multiple venues or include complex features like a seat picker, we’ve been able to design the user interface the same way we would with a normal website build, streamlining it into a really slick checkout flow that works exactly the way Ronnie’s staff need to use it — because they are the only ones who need to use it.

Finally, when it comes to building out the front end of the website, we’ll no longer need to negotiate with someone else’s API that only gives us the information it wants to, in the format it wants. Instead, every piece of data we need, about every performance, ticket, and sale, will be stored right there in the same database as everything else — and we’ll be able to manipulate that data with the same freedom as we would any blog entry or e-commerce product on a normal website. As a result, there will be far fewer compromises around user experience based on how the ticketing system’s API forces us to work.

So if we’re not recommending you get rid of your ticketing system, what can you learn from all this? We’re glad you asked!

First of all, don’t be afraid to take the road less travelled. If there’s a potential option that you’re tempted to dismiss out of hand — as we were, initially, with Ronnie’s suggestion of a bespoke system — you should take the time to properly weigh the pros and cons of it. You might find it’s not as crazy as it first seemed.

Second of all, as you’re weighing up those pros and cons, make sure you give some weight to parsimony. Just because you can reach your goal with a fully-featured off-the-shelf solution, does that mean you should? If a really simple solution will serve 98% of your needs, adding layers of extra complexity to serve the tiny remainder might not be worth the effort.

And finally, if after all that you do decide to get rid of your ticketing system, make sure you take the time to properly research and scope out the requirements for whatever you replace it with. More on that next time.

Read part two: Why are people really using your website (and who are they)?