Food Panda in a Flash

Challenge Number 2: Build on Foodpanda’s existing app to allow for a positive seamless local dining experience.

Our storyboard

The first order of the project was to create some group rules, set up a group calendar, and share our personal goals that we hoped to gain from this project. Looking at the timeline, we knew we had to start with understanding our diners quickly before we could work on FoodPanda properly. After all, what is the app without its users.

We conducted an electronic survey with 64 respondents. In the crafting of this screener survey, we spent some time deliberating on appropriate questions that can shed some light on the contexts and behaviour of dining. Within a day, we closed the survey and found out that

  • 85% of respondents eat out in groups more than once a week
  • 71.9% of respondents eat in groups of 3 or more
  • 89.1% of respondents split bills
  • 75.0% of people split bills among themselves without the restaurant’s assistance.

This finding proved that dining in groups and splitting the bill after the meal was a usual occurrence among most people so we went to a restaurant to observe patrons split bills among themselves. We then asked the waitress if the restaurant offered split payment and she said it was easy for her to do it and promptly showed us how she did it.

We interviewed 6 of our respondents who had used some form of electronic means in splitting their bills or tracking payments or made dining reservations. User interviews were such fun. We simply asked “why” to the actions our interviewees took when dining and the answers came in the most unexpected and candid ways. Our interviewees shared with us their quirks and personalities that provided us with insight and a purpose to create a product that catered to their needs and would delight them.

We extracted their interview responses into stickies and coloured them by Pain-points, Pleasures, Context and Behaviour. Finding that it was difficult to organise them, we decided to group them by tasks first. This allowed us to, concurrently, see a task flow as well. We saw that most of the pain points arose from bill splitting. We created user stories based on what we had gathered thus far. This led to feature ideas and our storyboard.

After that, we rearranged the stickies by the essence of that behaviour, context or feeling. We discovered an interesting juxtaposition of 2 main characteristic diners. One person was the more conscientious and somewhat detailed diner who would make reservations based on group consensus and discussion then consolidate food orders, pay on behalf of everyone and then track the payments. The other was a more laid-back person who would follow the group’s dining decision then pay friends back. Our group concluded that the app would be most relevant to the first character who was our main persona.

Everyday, after meetings, we would collect information on competitors and comparative apps. We consolidated market information, feature information and app flows in a large document. With user analysis completed, we opened each competitor app alongside each other and did an analysis of the steps, features and heuristics of each app, with one member noting down all observations. We had our tasks ready. However, the apps on the market mainly catered to one task each, with none of them weaving all the dining processes together. Hence, we had to put together the various parts of competitor apps to create an entire flow. Our first draft of the flowchart was finally ready and that was the end of Week 1 of Foodpanda. Of course, we were a bit excited so we started on some experimentation ideas of our prototype for various screens. That was because, while doing the analysis, we also had our ideas so we quickly sketched them out.

Over the weekend, we started on a first draft of our presentation as the first part of our work which would lay the basis for the subsequent prototype was ready.


Adhering to the brand of FoodPanda and the overall layout, we ideated on the new screens of “Delivery, Dine-In or Reservation?”, “Who’s dining with you?”, “Who’s sharing this [food item]?” and split payment. In our paper prototype, it is interesting to see a mixture of old (printed cut-outs) and new (hand-drawn). We also felt that the input of names of diners might be something diners would like to skip so we created a prompt that ask “Are you sure you want to continue without inputting fellow diners? Listing their names will let you indicate food sharing preferences and get more payment options”

Through the usability tests on our paper prototype, we learnt that our reservation portion closely resembled other apps available so we decided to scope the rest of our project towards the dine-in and bill-splitting process. We also found that our testees’ real world understanding came very strongly. They thought that the bill page should show them a bill that looked like the real one with the splitting of GST and service charge and that the option to Notify their friends to pay via app was not necessary since their friends will be physically present with them. There was difficulty in comprehending our hand-drawn screens perhaps due to its novel concept and unfamiliarity to our testees. Overall, my main takeaway from the tests was that these new features would have made it such that a real-world waiter would not have been very necessary. It would be important for us to maintain a strong sense of human touch in our final prototype.

We created our wireframes using Sketch, synthesised them in Invision then conducted another round of usability tests. In our new frames, we made sure to ask our diners questions in a conversational tone. This time, there was no problem for our users to complete the tasks but they were left bewildered and in the lurk when we led them to the page with the individualised billing with a cramped display. What we had on that page was all the details of all the diner’s individualised payments. There was too much information for them so we decided to collapse each individual bill to progressively unravel other payment details. The call-to-action buttons were also inconsistently aligned, making users confused. We improved upon the problems and also included a confirmation dialogue for credit card payment.

The old flow of Foodpanda is in grey while the new portions are in yellow. The final prototype screens are inserted within the flows of Ordering and Dine-In Payment.

The interesting thing about our project was that we had to build on an existing app. There was a strong need to adhere to what the existing app was already doing well, and to leverage on its capabilities and database of content. In introducing new functions, we thought that it was important not to alienate the app’s existing delivery customers. The existing task had to be able to allow for continued operations. Nonetheless, a larger perspective of ensuring the new limbs of ‘Making Reservations’ and allowing ‘Dine-In’ and ‘Payment’ had to gel with the existing function. We decided to redesign the bottom navigation bar that FoodPanda may have been distinguished by, into a hamburger button at the top left corner. Had this been a real situation, I expect some management resistance to this redesign. However, in our project, the new Foodpanda would have so many features that the bottom navigation bar would be overcrowded. Moreover, the decision to remove the bottom bar was also to remove the many decisions a user would have to make and the process should be a straightforward one. We intended to guide the user along the steps with a persistent bottom sticky bar when they have placed an order, or to make payment. Users will not have to think, since they had earlier informed the system that they were either ‘Dining-In’ or requesting for food ‘Delivery’. The current search options were intuitive for a delivery customer but there were new users like those who wanted to make reservations or dine-in so the search capabilities would have to change to allow for the restaurant name or cuisine to be included on top of current location.

Should this app be further refined, we would have loved to include more animation to direct the diner’s attention to the sticky bars, including more help dialogues, and show the process of calculating the bill with a simple calculator effect that will make users’ feel pleasantly surprised and appreciate the feature more. Our group would have loved to conduct more usability tests to find out what type of phrasing works as our tabs were named “Bill to One” (bill page where one person pays) and “Bill by person” (individualised bill page).

I had a wonderful collaboration with Nate and Damian. I especially loved how we refined on ideas and elaborated on themes, even spending a thorough discussion on the best form of presentation to bring forth our user’s stories, our design story and the reconciliation of old and new in Foodpanda.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.