Challenge

The people I interviewed did not have always have a positive experience when ordering food online. Their two biggest complaints were:

1. Having too many choices to make and too many options to pick from, which can lead to excessive scrolling on phones.

2. Having to find and/or select the restaurant location they were going to order from.

I chose to apply my findings to a mobile app for ordering pizza because my users had directed several of their complaints to that experience, and I wanted to revise that experience into one that would make them feel like it was easy to order a pizza.

Approach

I set a few design goals for myself based on my synthesized findings from directed storytelling and affinity diagramming:

• Provide option for app to use device location and select the nearest restaurant location, giving users settings customized to that location. Let user change location if they don’t like the selected location. Make this information prominent by placing at the top of the screen.

• Provide pizza and location reviews since all my users said they look at Google reviews at some point when making food ordering decisions.

• Limit choices and options by: (1) limiting number of signature-type pizzas to pick from and (2) limiting ability to customize signature-type pizzas.

• Take users through building a pizza in a step-by-step process so they don’t have to figure out what to do next.

• Limit the amount of scrolling per screen.

I began first by creating a rough sketch of the site map and information architecture of the app before translating my diagram into a screen flow in Sketch with medium-fidelity wireframes, utilizing existing pizza apps as a source for common mobile UI design patterns and for making sure I was including the necessary steps and information to complete an order.

Tools & Methods

Directed storytelling
Affinity diagramming
Sketching
Site map
Information architecture
Screen flow
Wireframing
Interaction design
Prototyping
Usability testing
Visual design
Material Design
Sketch
Axure RP

Once the screen flow was fleshed out, I built an interactive prototype in Axure RP that focused on the flow a user would take to order a pizza. Thus, not all screens were created, namely the sign in/sign up process, reviews, or other menu pages that contained the additional features available to users.

Usability testing

Next, I conducted usability testing of the prototype on an actual phone with the three users I interviewed and an additional participant who also had previous experience ordering food on her phone. The test focused on the ease of use in placing an order for a pizza from the fictitious “Flame Pizzeria,” as well as on the user flow of the mobile interface during that process.

Scenarios/tasks:

1. Select a signature pizza and place an order for it

2. Build a pizza and place an order for it.

I recorded quantitative data for task completion rate, time on task, post-task rating, satisfaction rating, error frequency, and severity of errors, along with recording qualitative data.

Outcome

Users were generally able to complete the tasks on time, giving an average rating for their experience with each task as between easy and very easy. Overall, they were satisfied to very satisfied with the app (as a prototype).

Descriptive words/phrases

“Simple.” “Straightforward.” “Easy to navigate.” “I’d use it.” “It’s a good app.” “It’s easy.”

The tasks were not without usability problems though. The tasks pinpointed one screen in particular that caused several problems: the order details screen. This screen had two steps which asked the user to select between “carryout” and “delivery” AND between “order now” and “order later.” Some users would only make a selection for one of the steps and skip over the other step. This was either because they didn’t notice there were two steps to complete on the screen or, in the case of one user, ordering now or later meant something else.

This common usability problem suggested that these screens needed to be revised so that there was only ONE step to complete per screen, much like the step-by-step process for building a pizza.

As one user put it:

“When you’re going fast, you shouldn’t have two options (choices) on the same screen...go to the next thing otherwise you’ll skip something.” 

Other usability problems

• Not noticing the build your own pizza option on the pizza menu screen

• Thinking the "no thanks" button in regards to using device location meant exiting the app

• Not knowing how big the pizzas are

• Finding the radio buttons hard to push

I then revised the screen flow to address the usability problems discovered from the tests and edited the screen flow and prototype to include most of the screen revisions.

NOTE: The revised prototype includes most of the screen revisions; I did not include a summary screen of the entire order though.

User interface

With this research in hand, I then began creating high fidelity visual designs for Android utilizing Material Design guidelines. I found a free stock photo of a pizza in a wood-burning oven and used this as inspiration for my color palette.

Reflection

This project allowed me to utilize tools and methods across the entire UX design process, from scoping and research to wireframing and prototyping to usability testing to visual design, and it demonstrates how I was able to start from a simple question and end up with a tangible product.

This project was also my first time using Axure RP, and I’m proud of what I accomplished with it, especially having a limited amount of time to build something before testing it. I learned about the program and built the prototype over the course of just five to six days. I was determined to make it as realistic as I could, so there were chunks of time devoted to figuring out how to make features work, exploring tutorials, Axure training and reference guides, and the Axure forum. It was exhausting, but immensely satisfying when things worked correctly.