Retrospective 3 — Foodpanda mobile app
An app tailor made for two: Foodpanda 2.0
So this week we were given the task of picking a mobile app and redesigning it however we saw fit. My team and I chose Foodpanda after exhausting a couple of options. Sgtransport had too little to change and Qoo10 had too much to redesign in a mere two weeks. We took heed from the other groups and chose an app with a single clear objective: food delivery.
This time, i used our business goals as the main motivator for any changes we were going to make. They are namely to retaining existing user base, encouraging increased usage and convert users over from other similar food delivery apps. To do so we introduced a feature that we felt were sorely lacking in other delivery apps: ordering from TWO restaurants in ONE receipt. This feature we came up with after interviewing 4 users of food delivery apps. Their common gripe was being unable to order from more than 1 restaurant per trip. Going forward this was the most obvious feature to include in the redesign. But on top of that we wanted to make sure the current app was “upgraded” to meet the three business goals i mentioned above. As such, some simple UI changes were in store.
The rationale being: users are not using the app because some basic interface design heuristics aren’t in the current app, which causes frustration, therefore we can fix these UI issues and assumedly have users hop back into using the redesigned app.
Backtracking just a bit, we had to create personas for the sake of this redesign. Somewhat like a target audience, but more nuanced and with issues. Meet Jon and Jane:
Jon is adventurous but not bold. He wants to try a new dish every day but still wants to order his usuals. He rushes home from his hectic work every day because he hates his colleagues. He wants his food at his door when he arrives home so orders on the go.
Jane is a fresh graduate and is currently enjoying her late nights playing Dungeon and Dragons with her close equally unemployed friends. Cost savings and order variety are her main concerns.
Both “Doe”s have their respective journeys when it comes to using food delivery. Called customer journey maps, it lays out a users entire user flow of using the app. From deciding if he/she wants to order food delivery and the motivations that are involved all the way until the end when they receive their food and their thought processes and satisfaction with the food delivery service. It looks something like this:
Notice how they both have emotional levels below neutral at the same stage of their journey. That was where we focused most of our redesign efforts on.
We made the filter button more obvious and cleaned up the titles of some of the filter categories. For example previously “chicken” was listed under cuisines, and unless they meant that an actual rooster prepared my meal, “chicken” should not be under cuisines.
We increased the size of food pictures and included information that we found — through user interviews — were pertinent to users’ decision making on the summary thumbnail. Such as last order time and estimated price per person. This addressed the uneasy and frustrating evaluation process both personas’ experienced.
Finally we revamped the status update page to include a map with riders’ GPS, phone number(proxy) and full progress meter. This helped address the Jon persona’s uncertainty when it came to the delivery process.
Our prototyping process this time round was incredibly tedious. Version one was done on Axure, with very rudimentary interactions in place, untested UI changes implemented and our new feature haphazardly thrown in one of the screens. Naturally, after subjecting Foodpanda 2.0 to user testing, results were less than stellar. Users couldn’t find the new filter function, couldn’t properly test the interactions between pages and entirely looked past our new feature’s CTA button.
We decided to then hop over to using Sketch and Flinto for version 2.1. Buttons were put in place accordingly, colour schemes were pleasant and the call to action button now was larger. Still users c0uldn’t find the call to action. So for our final iteration we added a tutorial page from the start so users were aware of this new function and would interact with it accordingly.
We tested a third time with our users to validate the new feature and wrote usability test reports to document their responses. Finally, users were able to see and interact with our new feature.
By this time, it was 9 hours to our presentation. We frantically uploaded our documents and arranged transportation home to rest as much we could. I woke up the next morning like a bear out of hibernation. Adrenaline fueled by my enthusiasm to showcase my completed project.
I opened up the presentation with and introduction of my amazing team, brought the audience through some business goals before handing the attention over to my teammate for subsequent parts. Toward the end i hopped back in to do a live demo of our prototype. We used Airserver to stream Doren’s phone screen onto the projector as i moved about wirelessly with her phone. When greeted with the tutorial messages, in order for the audience to clearly understand what i was demoing, i did an exaggerated left swipe to show that the tutorial screen changes with a swipe. No, seriously, i swiped left harder than a guy would after finding his mom on tinder. Q&A and applauses after, we concluded project 3 with a cheery group photo.
Til next time,