Apps World 2015: OpenTable’s user-centred mobile payment design

OpenTable logo

A lot of the big app platforms are more than just a consumer application on your smartphone, coupled with a website. Repeatedly at Apps World and elsewhere, I would hear speakers talking about these magic platforms that didn’t augment so much as capture the end-end experience. 

The big example lauded at the moment is Uber. Uber manages the whole private driver experience. From booking the ride, to seeing the progress of the driver as they are driving to the pickup point. From its driver management tools, such as offering point-point instructions and realtime traffic information. The post-ride review system to reward good drivers and passengers. The tiering of car services available. Its partnerships, such as the current Spotify trial in the USA, where passengers can pre-request and play their Spotify music in the car.

OpenTable is a similar platform. Ostensibly a restaurant booking app, the platform actually is an end-end reservation, dining management and table management platform. Not only does it allow diners to book a meal at a restaurant and advise special requirements, events and the like, but from initial design the platform has also allowed restauranteurs to manage their tables within the restaurant. It’s a great example of the sort of disruptive experience that Toby Russell was talking about in his session earlier in the conference.

The next evolution of the platform is about simplifying and managing the payment experience. In their talk at Apps World, Jocelyn Mangan and Alexa Andrzejewski ran through the process they’ve gone through to design the first step in this phase: new mobile payment functionality.

To give a brief overview of the final product, OpenTable have put together a video:

https://www.youtube.com/watch?v=YTXDXggWMjQ

The first step in designing this payment functionality was a broad sketch of what OpenTable thought the dining payment experience was currently like. This allowed the team to get a strong sense of what their assumptions were, and what they thought they already knew.

In my experience, most companies will stop at this point and proceed with initial design. They may or may not check the design with user testing before proceeding with initial high-level prototype development.

Alexa presenting an example of the sketches they put together initially when thinking through how users would typically pay a bill

In OpenTable’s case, the design process was not started until a good chunk of user research had occurred, with interviews undertaken with both key user groups (hosts/servers and diners). Alexa and her team interviewed servers and hosts, but rather than explicitly qualifying their initial assumptions by taking users through the timeline they had in mind, they had restaurant staff map out timelines of dining experiences, talking through the highs and lows of waiting on a table.

Similarly, Alexa’s team had diners sketching timelines of the dining experience.

I love this step for so many reasons.
First, they didn’t present their own assumptions and thoughts – but instead, got users to start from their own knowledge and sketch them into a timeline of a dining experience.
Second, by placing it on to a timeline rather than setting it up as a question and answer session, there was a strong visual cue for interviewees to talk to and visualize what they were discussing. (As anyone who’s worked with me knows, I like to sketch these things out a lot to get consensus before deep-diving).
Third, OpenTable didn’t just focus on the happy path – the research sessions specifically focused on what happened when the dining/serving experience was great, and what and when it could go wrong – and how it can be handled.
Finally, it meant the user mapped out their own journey themselves, making it easier to see where there were issues within typical experiences while they were doing so.

Having mapped out the dining and serving experience from the users’ perspectives allowed OpenTable to have a discussion about whether adding mobile payment functionality would improve the dining experience.
There were three principles Alexa and the team came up with to evaluate this potential functionality:

  1. The functionality must be worth it for all users. Feedback suggested that typical credit card payment processes were solid and easy for all involved.
  2. The new functionality must honor the ‘invisible script’ that underpins the dining experience. That meant that any new mobile payment process needed to include the opportunity for the server or host to say goodbye to diners.
  3. The functionality must support the key players (in this case, diners, servers and the restaurant infrastructure).

The third principle did mean that there would be additional work for OpenTable. Restaurants typically already have their own table management infrastructure, and although pushing a new infrastructure onto them would be the easy technical solution for OpenTable, most restaurants wouldn’t care about the overheads of transitioning to the platform. 

Alexa presents a timeline diagram OpenTable used for developing the mobile payment functionality

The next step was to map out the flows for each of the actors involved in the payment process. Four concurrent timelines were mapped on a whiteboard – one each for diners, restaurant staff, the restaurant point-of-sale system, and for OpenTable. Various (system and user) actions were written up on post-it-notes and stuck onto the relevant timeline. Edge cases identified from the user interviews were also included in these timelines.
The result was a bit like an orchestration, Alexa said. Certain actions from one actor would flow onto another system or actor timeline.

I’ve used this approach in the past for different clients and companies I’ve worked for. I find that it gives a really strong cue for all stakeholders, not just technical or design teams. It’s the sort of artifact that executives love to see and comment on.

Once the flows and process timeline had been established, it was time to move onto the interaction design. The team designed the experience with an emphasis on cueing restaurant staff and diners at the relevant points in the dining timeline.

There were several options Alexa’s team worked through, but the final solution they decided upon follows the current typical flow for the dining experience. After all, it was already determined in the user research stage that it was well established and easy for everyone involved.

Alexa presents feedback from servers on the initial iteration of the opentable mobile payment functionality

A prototype of the payment process was put together and then tested in restaurants. OpenTable staff would undertake user observation by sitting with diners as they would eat in restaurants, and then iterate based on their observations of diners’ and servers’ behaviors. There were a few interesting observations that came up from this stage:

  • A small population of diners are not comfortable saving their credit card details on the platform, and will continue to pay with their credit card regardless of the functionality being available.
  • Another set of diners will automatically add their credit card details when registering for OpenTable
  • Remembering to open or view the app to pay the check was a hurdle for diners.
  • Setting up a notification on diners’ phones when the bill was ready often didn’t work – many users didn’t look at their phones or notice the push notification.
  • If there were any issues with the payment, diners would automatically hand the phone to their server. This set up an interesting conundrum. 
    • In the initial testing, server training had only focused on understanding the restaurant application.
    • Servers would attempt to solve the technical issue as part of their waitservice.
    • If the server couldn’t solve the problem, then the experience was marred for both servers and diners.

This resulted in a number of iterations of the payment functionality before proceeding. Alongside training materials for servers that focused on both the restaurant and the diners’ apps, stickers were given to restaurants, and Apple Pay functionality was built in. Unexpectedly, adding Apple Pay increased the mobile payment usage dramatically.

There are still some kinks to work out. For example, Alexa told me after the session that they are working on bill-splitting functionality. The issue is not with the technology — her teams constantly tell her that it’s very easy to implement — but more around user experience. The truth is that the current standard in the US (where diners all throw in their credit cards and the restaurant automatically splits the bill for them) is simpler than attempting to do something similar with the app itself. She assures me that there is some splitting functionality coming up, but for the moment it will only allow one diner to pay the unpaid remainder of the bill from the app once everyone else has paid their share.

I loved this approach to designing, building and testing new functionality. It took in practical technological concerns but focused primarily on users – the research was undertaken in a manner that allows the relevant user’s voice to be heard rather than to qualify existing prejudices. The observational dining experience was a nice difference to lab-based approaches to user observation. Finally, and I have such a great respect for this approach, I love that the team had a strong timeline and flow to work to that allowed them to focus on special UI elements. I’d love to see what the next innovation in dining experience management is for OpenTable.

Sidenote: after the talk, I realized Alexa is also one of the co-founders of Foodspotting, an app that I loved when it first came out. If you’re a bit of a foodie, and/or love bragging about what and where you’ve eaten it, I highly recommend checking out the app.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.