UX Designer based in Vancouver, BC


Mobile food ordering for university foodies

More and more people are using their smartphones to order food. With so many mobile-ordering apps out there, FanDine wanted to combine the best features out there and to help restaurant-goers save time and get the most out of their lunch breaks.

Together with a team of developers, sales associates, and stakeholders, I helped focus our target audience and reimagine our product for university students.

FanDine is a food-ordering mobile app that allows consumers to order take-out from their phones. Our company direction was constantly changing, so it was necessary to adapt by thinking ahead in order to make pragmatic decisions. My assignment was to redesign the user interface and improve its usability. The main methods I used included personas and journey mapping.

Re-defining the target audience

Because our company direction was constantly changing, our target audience had never been defined. At the time of this redesign project, our mobile app was packed with features, many of which were unused and cluttering the interface. So finding out who we are building our app for was what my main focus at this point.

Because [our sales/marketing team] were often interfacing with restaurant staff and students, they already had a wealth of knowledge I could tap into with minimal effort.

Our sales/marketing team at the time were working with restaurants located at and near a university. Because they were often interfacing with restaurant staff and students, they already had a wealth of knowledge I could tap into with minimal effort. Seeing that our UX budget was limited, it seemed reasonable to cater our mobile app towards a demographic that we already knew, so I moved forward with university students as our target audience.

Starting assumptions

From chats I had with sales associates, during their down times and in the hallway, I gathered enough information to produce a few proto-personas. They were designed based on what I knew about students from when I was a student myself, combined with new information obtained from our sales/marketing team.

Fiona, one of the proto-personas I created, describing an aspiring food blogger.

One proto-persona I designed was that of an aspiring food-blogger named Fiona who is currently studying Communication. I thought this was a believable persona because someone who writes for blogs would share some similarities with a Communications student, such as eloquent writing skills.

Other proto-personas I explored were "Studious Steve", a hard-working student with a reduced social life, and "Healthy Henry" who was into healthy eating, and staying fit.

User interviews and guerilla testing

Working with our sales/marketing team, we invited individuals who matched our proto-personas to our office to conduct user interviews. I prepared questions that would help me gain a deeper insight on their behaviours, needs and goals such as. Some example questions we asked were:

Aside from these sessions, I also gained a lot of insight from just casually chatting with friends and acquaintances outside of work. I found that in a social setting, people tend to be more honest about their opinions and experiences on mobile apps in general.

From this exercise, we found that university students who use mobile apps to order food tend to be active on social media networks such as Instagram, Facebook. They prefer apps that do one thing really well, rather than apps that have many unrelated features.

Users in this group tend to judge the quality of a mobile app by its appearance at first, but in most cases will consider its usefulness if they are motivated to keep using it.

Previously, features had been added in without much planning, and our product usability suffered—workarounds due to legacy code led to lengthy user experience pathways, UX issues that had obvious solutions.

University students tend to judge the quality of a mobile app by its appearance at first, but in most cases will consider its usefulness if they are motivated to keep using it. So it was clear that bringing important useful features to the surface and re-aligning our user interface with these features were our crucial next steps.

Persona design and journey mapping

After aquiring more data, I returned to my proto-personas to update, modify, and combine them so that we can identify our target audience. The new versions of the personas (formerly proto-personas) were more fleshed out to incorporate real data, and more-specific descriptions under each category.

The new and improved Fiona 2.0, with more informed data.

To put ourselves in the shoes of someone using our app to order food, I facilitated an exercise with my teammates where we would imagine the various steps of the process, and think about what is going on in the mind of the individual. Breaking down each phase into specific actions (like thinking about where to eat, lining up to pay, etc.), we identified areas where a mobile app could help aleviate some of the pain points.

The typical journey of a university student having lunch on campus. This journey map is geared more towards the social-media savvy type.

Cutting back on features

Having re-examined our target users and identifying what they look for in a mobile food ordering app, I drafted a shortlist of our existing features.

Feature Phase
Mobile ordering Discovery
Mobile payments Ordering food
Food delivery in development Ordering food
Searching for restaurants Discovery
Restaurant hours and information Discovery
Reading/writing menu item reviews Eating
Order history Ordering food
Re-order a previous order New Ordering food
Setting the time to pick-up an order New Ordering food
Notify staff you have checked-in to a sit-down restaurant Dine-in experience
Grocery delivery Miscellaneous
Request table service Dine-in experience
Table reservation Dine-in experience
In-app special currency Ordering food

User interface improvements

In my new design, I focused on and making it easy to find restaurants, browse menus, and choose items to order. Our existing app already had this three-tiered structure in place—restaurants, menus, orders—but the interface did not communicate this relationship very clearly, so users often got lost in the app, not sure where they are.


My approach to solve this issue was to introduce a main visual element to signify when the user was entering into a new tier—for example using photographic cards and full-width hero images, as well as less visual designs, like simple text-based navigation bars (iOS).

One element from the old UI that confused our test participants was a QR-code scanner icon that was displayed in the navigation bar (iOS). This was one of our legacy features that allowed customers to check into a table, to let the staff at a sit-down restaurant know they have arrived, and are ready to be served.

If a feature is no longer used or supported, keeping it in the product does it no good.

In my new design, I re-imagined the starting screen as a search mode, replacing the QR-code scanner affordance with a search filter affordance which would be more relevant to the current mode. If a feature is no longer used or supported, keeping it in the product does it no good. In fact, it harms the user experience. Thinking in the user’s shoes, if I was exploring an app, and found a prominent modal feature like a barcode scanner with lacking UI indications or supporting help text, I could potentially be discouraged to continue using the app.

Searching for restaurants was also the starting mode in the old design. In my new version, I provide a vividly visual way to recommend and suggest restaurants to the user, and provide other contextual listings, depending on the current mode.

By separating the restaurant profile into three discrete sections, we help the user focus on one task at a time and constantly keep the user well-oriented in the app. Much like a website having teaser content on its homepage, the first section of the restaurant profile also contains some useful information from the other two sections such as a rating summary, and a general location. It’s like giving our user a little “appetizer” and then allowing them to naturally explore further.

Each restaurant profile is divided into three sections, catering to different user needs: the “menu” for ordering food, “reviews” for research and user enagement, and “info” for planning.

In the ordering tier, I opted for a more functional design—an itemized listing, what you would expect to see if reading a receipt or a bill. Because this step involves payment, I wanted to make things as transparent as possible for the end user so that they feel confident in their actions and also in our product.

The ordering tier provides clear affordances to add items to the order, and a transparent summary of the payment.

One of the new features we added into the new design was a way for the customer indicate to the restaurant when he or she was planning to arrive to pick up the order. This was increasingly popular in similar mobile-ordering apps geared towards university students, that brought value to their experience.

What I learned

The main challenge of this project was finding ways to perform UX research on a limited budget. Normally, testing participants would be recruited through a more controlled process with set criteria, either by the UX designer or through a recruiting agency. Because that wasn’t available, I knew I had to come up with creative ways to do my research by gathering data from internal and external sources in both formal and informal settings.

I felt using proto-personas in this situation was appropriate because it allowed me to draw from resources that were already available. Having this starting foundation helped us isolate a viable user group to cater towards, so that we could work towards a well-defined product for a specific audience.