At last month’s Ticketing Professional Conference, happily convened in my home town of Birmingham, I presented a talk entitled Reimagining Mobile First.
It’s strange to think that I’ve been talking at ticketing conferences about mobile for the best part of ten years now.
Whilst many ecommerce brands are finally getting to grips with mobile purchasing in 2018, the world of ticketing still has a way to go
The iPhone celebrated its tenth birthday in 2017. I presented mobile Select Your Own Seat work for Sage Gateshead at my first Tessitura conference in Orlando back in 2010. We’d built our first mobile site for Birmingham Hippodrome the previous year. After all this, obsessing over mobile design seems anachronistic. However, the design of mobile experiences still needs exploring. Whilst many ecommerce brands are finally getting to grips with mobile purchasing in 2018, the world of ticketing still has a way to go.
The phrase ‘mobile first’ has its origins in the web design community as an extension of responsive design, with Luke Wroblewski coining the term in 2011. The point at which mobile use would outstrip desktop users was visible on the horizon, and forward thinking designers realised that we should start designing the mobile elements of a responsive design before we worried about the desktop version. It’s harder to design clear, concise UX on a smaller screen, so it makes sense to tackle that challenge first, rather than attempting to cram complex, desktop user experiences into small screens. In 2018, we’re way past that tipping point. If we look at a typical client 81% of users are on mobile phones or tablets. But only 53% of transactions happen there.
The subject of my talk was not really about HTML and CSS frameworks. It was about recognising that mobile has changed our fundamental relationship with digital.
These days most ticketing platforms are responsive. And for many vendors and site owners, that means that the pesky mobile-friendly box is checked. But the subject of my talk was not really about HTML and CSS frameworks. It was about recognising that mobile has changed our fundamental relationship with digital. For many of us, this change may represent an existential challenge. Using my home-screen as an example, I noted that most of our interactions on mobile are based around apps rather than the web browser. And these apps are platforms rather than destinations; platforms which represent Convenience, Simplicity, Recognition and Trust. In contrast, most of the organisations with whom Made work are destinations. They’ll never own that hotly contested place on a home screen, and arguably they are providing mobile experiences that fall short in each of those four attributes. We need to think about how our clients address each of these areas, and what that looks like in a truly mobile-first experience.
If you want to look at a convenient booking experience, you should look at the truly mobile-first app Hotel Tonight. Whilst you’re at it, you could compare it with the .com era, responsive era, booking.com. Hotel Tonight can take me from opening the app to booking a hotel in literally two taps and a press. When I open the first screen, I’m presented with a selection of hotels (for tonight!) based on my location. No search, no clicking on the ‘hotels’ section, no wading past a mission statement or marketing feature, no ‘navigation’ to, well, navigate. I select a hotel on my first tap and I’m given everything I need to know about the hotel on one screen. I make my second tap to book, and I’m given a single-screen confirmation, offering me a chance to switch payment method or accept an upsell. With ApplePay preselected, I place my thumb on my sensor to make payment, and my hotel is booked.
In contrast, the booking experience on some websites we’ve built have at least twelve decisions or taps to make. And those are decent websites. We support guest checkout and Facebook log-in. We remember your addresses and your payment details. And still it’s too complex. Because these are destination sites. Not trusted platforms. I’ll come to trust later.
In order to achieve simplicity, we need to drop screens from the purchase process, and make some intelligent presumptions. Here are a few ideas about that:
1. Two tickets
It’s two tickets, 80% of the time. So let’s default to that, instead of defaulting to zero. If I need 3, it’s one tap. If I need one, it’s one tap. If I want two tickets it’s no taps, but most websites require two taps for that default choice. This is a simple example to ease us in.
2. Select Your Own Seat
Perhaps we should just put the best available seat into the user’s cart, and then allow the user to check the view and change the seat afterwards if they really want to. Maybe even after they’ve checked out? Maybe even as an upgrade? Like airlines do.
Select your own seat is a widely expected feature in a ticketing website. Website designers get excited about it, because it’s quite a serious app to design and polish. But I’d argue in a mobile-first experience it has to go. It’s just too many taps to do the work of a computer (picking the best seats), but also it provides too many options, too many opportunities for premature buyer’s remorse and indecision. Think about a future voice-driven interface, how do we fold seat selection into that? Also - it might just be me - but I hate putting navigational forks in the road: You are alone in a forest, do you wish to select a seat or choose the best available? This particular choose-your-own adventure may have a certain retro charm for viewers of Stranger Things but it has no place in mobile first UX. OK, killing Select Your Own Seat is controversial, especially when we’ve all exhausted so much effort on making it work responsively, but at least we could think about making it an optional step. Perhaps we should just put the best available seat into the user’s cart, and then allow the user to check the view and change the seat afterwards if they really want to. Maybe even after they’ve checked out? Maybe even as an upgrade? Like airlines do.
The process of checking out is not just about taking payment, it also collects address data and user data. The thing is, the modern checkout technologies including Paypal Express Checkout, ApplePay and AndroidPay can provide all of that information to you. OK there are a couple of clicks for the user in those environments. But users are much more likely to be motivated to maintain that data because they are platforms used for paying on various destinations.
Most clients miss the point of payment gateways like ApplePay and PayPal. They’re not just alternatives to paying by credit card, they are alternatives to entering Registration, Billing, Shipping Addresses and credit card details. They can take over the entire checkout process, with a couple of clicks. The data you need is sent back to your API by the checkout provider, there’s no need for the user to key it into your website.
4. The Cart
Why does the cart exist at all in a typical ticketing checkout? Tickets are not heavy items in real life, or virtually. The purpose of the cart is:
- To serve for the 20% use case where a user is buying tickets to more than one show in a single session.
- To serve as a ‘holding area’ in which to propose upsells, from add-ons to donations.
- To act as a buffer before launching someone into a checkout experience which is predicted to be traumatic.
Because we removed the trauma from checkout in our previous deletion, that final reason no longer holds water. Remember buying tracks in iTunes? (Back when you downloaded tracks, in the Dark Ages). There was no cart necessary, even though you might make repeated purchases, because ‘checking out’ was painless. The same is true of single-click purchase in Amazon and eBay.
If you shift your understanding of upsells, then you don’t need to do them in a cart. Most ticketing systems consider the time between checking out and attending to be dead from an e-commerce perspective. Airlines, in contrast, use this time, and various touch-points to encourage upsells from seat-upgrades to food and beverages to luggage. One advantage of this approach is that it encourages users to focus, at the point of transaction, on the additional cost of the upsell, rather than the total cost of the cart.
You can do upsells via email, or using the ticket and account management pages in your website or application. To make this work you should use token-based links to effectively keep the user’s session open. If I’m sent an upsell email, I shouldn’t need to log-in to take advantage of it. If you want to see how smooth that action can be, skip tipping your Uber driver in the app next time, and watch how easy it is to action the tip the next day via the follow-up email you receive.
In a mobile first world, it might be more appropriate to SMS your user an appropriate upsell or upgrade rather than by email. Consider the case that you have a show on tonight with spare capacity. You can target the users attending tonight for whom you have mobile number and payment details on file with a tempting seat-upgrade offer. Due to this pre-qualification, the link you text can contain all the information you need to execute that upgrade. So the user can accept it with a single click.
Here we are wandering into a world of what I like to call ‘transient apps’. Single use, mobile-first screens that exist in the right place and right time to process a unique and pre-qualified user need. Airlines are getting proficient at building these, you might find yourself using one to check in. Are they an app you install? Probably not, they’re just a couple of well targeted HTML screens. Did you log into the user portal on the website? Not necessarily. Do you even perceive them to be a website? Probably not, if anything you may perceive them to be an extension of your email app. You don’t really think too hard about what they are, because it doesn’t matter, they’re a couple of screens that fulfilled a need and popped up just when you needed them.
Festivals or organisations with a large subscriber base might genuinely need a cart. For other organisations you may be able to replace the cart altogether with something more akin to a confirmation screen.
5. Paper Tickets
Lots of elements and clicks in the ticketing path exist to facilitate the delivery options around tickets. Maybe we should just kill those in favour of e-tickets, or even COBO. Maybe we really don’t need to know someone’s physical address at all in a Mobile First world. Whilst we’re at it, the delivery experience around tickets is an opportunity to add value. Whether that be upsells, ratings, directions or dress code, a tickets wallet is the ideal place to provide need to know information post-sale. Mobile first sites bring you the information you need when you need it, rather than expecting you to hunt and peck around a site hierarchy.
Why do you hate being asked to think of a password so much? It’s because you know you won’t have a chance of remembering it.
Smart apps like Hotel Tonight know who you are, and don’t ask you to log in on every visit. In fact, you might barely notice you registered.
Users hate registering and if you’re in doubt about that think about how you feel every time you’re asked to register on a new website. If you feel like you’re being asked a lot of unnecessary information, still the case in many ticketing workflows, that’s part of it. But what’s even worse, is having to think of a new password.
Why do you hate being asked to think of a password so much? It’s because you know you won’t have a chance of remembering it. You don’t really want to use the same one that you use for your bank. And even if you did, the validation rules on this ticketing site will be subtly different. That means you’ll use one that is slightly different. Which means you know you’ll be tussling with the forgotten password feature.
Users hate the forgotten password feature. Research shows that users will attempt to guess a password three times before resorting to a reset, and many users will simply prefer to give up. In a mobile first context, the classic password reset can be particularly problematic. For many people mobile means fun, and email means work. Many users are not particularly email focused on mobile phones, so sending a password reset to email could be particularly off-putting.
Instead of expecting people to register their identity specifically with you, maybe you should use one of the platforms that users interact with on a daily basis. Platforms like Google, Paypal, Facebook and Amazon can all be used to log-in to third party websites.
Alternatively, many new apps are starting to dispense with the password altogether and instead email or text you a unique code each time your cookies expire. This is the de-facto authentication method for Dice Tickets.
Maybe in a Mobile First world, it’s time to re-think how loyalty works. Hotel Tonight does a wonderful job of this. It simply tracks how much I use their app, and rewards my profile with a ‘level’. Levels unlock special rates for certain hotels, which are clearly shown to me on the listing screen. This works brilliantly when you have constrained inventory whether that be cheap hotel rooms or premium seats. You can simply offer it to your best customers.
Note what I don’t have to do here. I don’t have to remember a loyalty number. I don’t have to log-onto a portal to check my point balance. I don’t have to trawl through pages of chotchkies looking for something worth spending my balance on. I’m just rewarded for loyalty effortlessly on the screens I already use. Yeah they show me a little trophy icon, and that makes me feel pretty special…
As a destination site, you are not to be trusted with people’s passwords. You are certainly not to be trusted with people’s credit cards, and you are probably not to be trusted with people’s personal data. Think about that for a second.
You’ve probably put in place all of the right features to encrypt and protect user passwords, even though much larger, internet-first companies are regularly breached. The thing is your users don’t know that. We’re rapidly heading toward a future where trusting random websites with your passwords feels like a very old-fashioned thing to do. Instead, you trust your identity to a small selection of identity providers. People like Facebook, Amazon, Google and Paypal. Luckily, it’s quite straightforward to integrate log-in with these organisations, so that you can confirm someone is who they say they are, without ever having to store their password, or ask them for it.
2. Credit Cards
You might be the kind of organisation afflicted with an IT department who consider PCI Compliance a worthy challenge. If you are, then well done: you have earned your right to foist your ugly, unusable credit card form on unsuspecting users in return for a slightly reduced processing fee, that might conceivably justify the lengths you’ve gone to. As well as the terrible user experience and compliance headaches though, you suffer from the same fundamental trust problem. You may be 100% confident that your credit-card data will not leak, but why would your users share that confidence? A natural side-effect of the balkanisation of e-commerce by Amazon and eBay, is that entering credit card details onto random websites feels a bit off in 2018.
3. Personal Data
What with GDPR and the latest news about what Facebook have been up to, you might feel that harvesting lots of unnecessary personal data is a risk that’s just not worth entering into. How much information do you really need to sell someone a ticket? Maybe less than you think. And remember that marketing intelligence doesn’t count as personal data if it’s anonymised. If you can target the right message to the right person and measure the ROI on that, is it really important to match that activity up with personally identifiable data? If not, why collect it?
You may feel that the likes of PayPal, ApplePay and Amazon are not immune from security and data privacy concerns. You would be right. But the thing is, in the case of a major breach of one of those major players, your own brand is likely to come-off relatively unscathed. It brings me back to my key point. You’re not a platform, you’re a destination. Let platforms deal with platform problems. You do not have any value to add here.
Although I expect a lot of what I say here causes pangs of recognition, I can also sense the scepticism penetrating your screens:
- This will never work for our subscription model.
- We can’t do this because of our legacy membership model.
- What about Mr Forsyth, who’s always calling Audience Services, this is never going to work for him.
- We can’t do this because we’re truly unique!
Happily, as was the case with my talk in Birmingham, I’m out of time (or column inches) to answer those points. But believe it or not, I do have some suggestions. Tune in next month, and I’ll share some ideas for changing our cultures, and even our audience’s culture, to operate successfully in a mobile first world.
Subscribe to the
Sign up now to our utterly private, spam-free and occasionally insightful newsletter.