Flypay

This case study details the two-week process our team went through to conceptualise, design and integrate a new, fun and engaging feature to help restaurant customers split their bill.

flypay_ux_project

The Client

Flypay; A mobile app that makes restaurant bill-splitting easy, targeted at casual dining restaurants.


PROJECT OVERVIEW

The Brief

Paying isn’t fun; design and develop a hi-fidelity interactive prototype of a fun and engaging game that will integrate well into the current app offering a third and more enjoyable form of bill payment.

The Problem

Paying isn’t fun and nor does it create excitement but it does provide some satisfaction. When it comes to paying the bill, restaurant goers all to often come across a contentious item that noone at the table owns up to. Unfortunately, the cost of this item is never split fairly.

The Solution

A game that integrates seamlessly into Flypay’s current quick and simple checkout process and screen flow. The criteria for the game was:

  • A quick, decision maker
  • Decisions made by the app
  • No skills involved (random selection)
  • Fun & engaging
  • Non-conflictive
  • Based on a widely recognised game that is quick and easy to grasp

PREPARATION

Duration

2 weeks, split into 2 sprints:

  1. Discovery Phase
  2. Design Phase

Team

A team of three, incuding Tony Vila, Oksana Pariy and Ollie Moser.

Flat team structure

The Tools

  • Pen & Paper
  • Google Forms
  • Sketch
  • Keynote
  • Invision
  • Trello

The Process

Design

  • Design Studio Method
  • Content Prioritisation
  • Sketching
  • Screen-flow
  • Rapid prototyping
  • Paper Prototypes
  • Digital Wireframes
  • Participatory design
  • Style Tile
  • High Fidelity Mockups
  • Clickable Prototype

Discovery

  • Usability Testing
  • Competitive Analysis
  • Stakeholder Interviews
  • User Interviews
  • Concept mapping
  • Survey
  • Feature Analysis
  • Task Analysis
  • User Journey
  • User Flows
  • Storyboarding
  • Personas

Testing

  • Paper Prototype Testing
  • Iterative Wireframe Testing
  • High Fidelity Prototype Testing

DISCOVERY

Stakeholder Interview

Flypay is a startup first launched in early 2014 with a pay-at-table mobile app that lets you settle your restaurant bill “waiter-free”, but has since added a number of other solutions targeting the hospitality industry. These include order and collect, order at table, bar tabs and customer loyalty features.

Flypay app is currently available for casual diners in over 100 restaurants and bars across the U.K., including Wahaca, Cabana, Gourmet Burger Kitchen, Jamie’s Italian, Burrito Mama, Dirty Burger, Chilango, and selected Fullers pubs to name a few with many more to be on aboard very soon.

Competitive Analysis

We soon realised that this was not going to be a typical UX Design project. Not only would we be attempting to solve a problem, but we were to design a suitable game to help us do it.

We started off by conducting a competitor analysis to get an idea of what similar companies might be doing. We needed to understand how other companies tackled bill splitting and whether or not they tried to make it fun, but also to look into what other fun and decisive solutions there might be to splitting the bill.

Direct Competitors

Direct competitors of FlyPay include Orderella and CAKE, both operating in London. These apps allow you to order food items, split the bill, and pay the bill all within the app. However, neither of them offered a fun or engaging alternative to splitting or paying the bill.

'Lightspeed’ and ‘E la Carte’ both companies operating in the U.S. offered the same service of paying and splitting bills, however these were services operated on table top devices and were not apps. Interestingly though they were both highly engaging, with both offering the option of a suite of games allowing customers to play while they wait for their food to arrive.

Bill Splitting apps

‘Plates’ by Splitwise is a well designed and fun app that allows users to quickly calculate and split total sums of money in different ways, between any sized group of friends. The only issue with this was that it needed to be operated by one user and there was still a lot of decision making needed on the part of the user. This was interesting because it gave us an idea of another option to bill splitting which was to randomise the total.

 

 

 

Bill Splitting Games

In terms of games people use to split the bill we discovered a whole range of different ones. Such as Dice rolling, Paper Scissors Rock, spoof and card roulette. These were good examples of decision making games and were often used to help people split bills.

 

 

 

Contextual Analysis

In order to position ourselves well before speaking to potential users and understanding their frustrations, we needed to get to know Flypay a bit better, how it works and the context in which it operates. To do this, it was ‘vital’ for us to pay a quick visit to our favourite Mexican restaurant Wahaca to test out the app ourselves.

We were blown away; a quick sign-up and set-up process, easy bill-splitting options, easy to grasp design and interactions, coupled with the pleasure of being in a friendly and fun environment. What’s more, the waiter seemed to really enjoy the app too! We had a great experience.

So, why do we hear the phrase ‘paying isn’t fun’ and why and in what context do people use it? Ours was clearly a fun experience. We needed to establish the real essence of the problem here. More in-depth user research would be our answer.

Survey

To begin the user research, we needed to construct a survey. The aim of the survey was to learn a little bit more about our user types and try to establish patterns amongst them. Who were they, what their dining habits were, what their gaming or gambling habits might be! what their attitudes to this concept might be. We wanted to find out when people would play a game, and what type of game if any they would play to help them decide a bill and what items they would usually play for, this would help us focus on the right solution.

The results were interesting. We found that 87% of respondents are used to paying for other people’s food and drink and 38% of those respondents do this on a regular basis (two times a month or more). This was great news for us. Generally speaking, people are happy to take a hit on something like paying for food for friends — So, if this is the case, the stakes on playing a game over food items (with people you trust) are really not that high.

We also discovered a whole host of games that people play to help them split the bill or decide items on the table.

But interestingly 61% of respondents told us that they would never play games to decide a bill. We needed to talk to these people to find out why they wouldn’t whether it was at all connected to the fact that paying isn’t fun. Maybe this was the clue — the majority of people did not have a fun solution to bill paying? In terms of those who did play games we needed to find out more about when and with whom they played the games and why.

Interviews

Now that we had our target users, our aim with the interviews was to find out what kinds of problems people might be having at restaurants when the bill arrives to make paying something that is ‘not fun’ and whether or not a game would help to solve this. We also wanted to find out why many people tended to play games, what types of games and what is usually at stake when they play them.

We soon realised that when we mentioned the word ‘gamble’ or ‘betting’ for food, people were not so interested. But, when we re-phrased the question: “Would you play a game to decide who is paying for items on your bill?”, the response was much more positive.

We found that people liked the idea of playing a game over food items, but the type of game and the conditions surrounding it needed to be right. This was especially true as we clearly had a range of user types of all character levels, financial standing and gambling and gaming skill levels, wanting to be involved. We needed to find a solution to satisfy them all.

Skill based games were used a lot, and they tended to be used by individuals with a history of gaming and/or gambling. We found that not only was it unfair to have these experienced gamers up against less skilled gamers, but also we found that these games, required an element of aggression and bravado to succeed, which is what put a number of our interviewees off them in the first place.

Game Criteria

  • A quick, decision maker
  • Decisions made by the app
  • No skills involved (random selection)
  • Fun & engaging
  • Non-aggressive
  • Based on a widely recognised game that is quick and easy to grasp

Personas

We used the data from the interviews to build out three key personas that represent the people we interviewed. These personas would help us to imagine who it is we are trying to speak to and what their needs an frustrations might be.

 

Of the three personas, we identified Rosie as our primary persona, who we felt represented the largest user group and was also a middle ground between the other two. We felt that if we focused on solving Rosie’s problem we would be able to provide a solution to Mark and Margaret’s needs too.

Frustrations

  • People taking advantage of her good nature
  • Paying for more than she had
  • Lack of honesty amongst friends

Goals

  • Taking part in fun activities
  • Impress friends
  • Quick & Fair decisions

So what was Rosie’s problem? She loves going out with friends and getting involved in activities with them, however sometimes one or two friends are often unfair when it comes to owning up to food items they had.

User Journey Map

We mapped out Rosie's journey to determine the points of frustration during a typical bill-paying process at a restaurant with friends.

 

 

Story Board

By creating a storyboard of the scenario we were able to convince people of this typical situation that many of us find ourselves in. The storyboard allowed us to convey our story easily and communicate the problem not only to our stakeholders, but also to remind ourselves of who we are trying to solve this problem for but what it is we are trying to solve. 

I think its safe to say, we can all relate to this story...

Rosie and her mates are having a great time at Wahaca. The food was good and as always, it was great to catch up with friends. But now, it’s time to think about paying…The bill arrives…everyone can see that there is a contentious item on there! …but no-one owns up to it…people pay for their own items, one by one…yet, somehow that one item still remains!…With everyone else having paid, once again, it falls on Rosie to pay the outstanding amount!

This is a problem for Rosie and many people similar to her.

 


DESIGN

Design Studio

Now we know Rosie’s problem and who and what to design for, we also know the criteria for which to base our game design on, we were ready to start designing a solution!

In order to design the game, we utilised a design studio session. This is a great technique which encouraged collaborative design and thinking and it was ideal in this instance.

Based on the criteria from our interviews, we came up with a whole number of games ideas.

Game Criteria

  • A quick, decision maker
  • Decisions made by the app
  • No skills involved (random selection)
  • Fun & engaging
  • Non-aggressive
  • Based on a widely recognised game that is quick and easy to grasp

Several rounds of sketching were conducted and after each round, as a team, we used a system of up-voting the design solutions, functionality and screen flow that we liked. The most voted for designs were then refined again as a team.

We slowly narrowed down the games selection through a process of up-voting and discussion.

Finally, with the handful of games and features to choose from narrowed down, we designed the final version.

This was an amalgamation of all criteria squeezed into one simple solution.

 

User Flow

We created a user flow to help us and our stakeholders to understand exactly where the feature fits in to the current flow. With the task analysis in mind and now understanding what type of game it was going to be and what was at stake and where the pain point really is, we felt that the best solution would be to design almost a diversion from the bill screen, that allows users (if they need to) divert away from the screen to handle the issue of the game and then to come back, once the game had decided the outcome.

Paper Prototype & Testing

We started our paper prototype by working on the screen flow. Our early sketches included a six-step process in the lead up to the game.

This was then reduced down to fewer screens after testing to increase efficiency and enhance the game build up. Especially as the current Flypay Screen flow is so quick and efficient, we needed to ensure that we didn’t slow this down or hinder it anyway.

 

 

Iteration 2

Our second round of changes, based on feedback from our testers was to do with the functionality of the game and the build up to the game itself.

People needed clarity to enjoy the game and they felt that playing for single items with one winner or loser made more sense. We made the changes to a low-fidelity Wireframe mock-up, using Sketch.

 

 

Iteration 3 - Low-fidelty digital Wireframe

We used Marvel to help us test the low-fidelity wireframe. This enabled us to really show off the interactivity of the game itself. Feedback after this round of testing, was largely focused on adjusting the terminology. But most interestingly, we kept getting requests to add a button on our summary page, just before the game starts! We realised that people just couldn’t fight the urge to want to press something! …So naturally we gave the people what they wanted! 

Additional feedback at this stage was noted and used to help us build out our hi-fidelity design

…So Let’s take a look at it in action!

 

Test our prototype

We used Invision to create the Hi-fidelity digital clickable/tappable prototype.

Test it out here:

Future Steps

Our next steps will include:

  • A feature that allows users to track the wins and losses in their user profile
  • A points and rewards scheme
  • Addition of sounds and animations, to increase the ‘game’ atmosphere

Thank you for reading.