You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Our goal is to improve the user experience when ordering food at a restaurant by creating a mobile application that displays the menu for several restaurants.  There are three main types of users: the customer, the waiter, and the manager.

The customer will use our app to explore the menu of a restaurant (while present or not present at the restaurant).  Some customers may be extremely hungry and will want an efficient application.  Another group of customers will be more interested in exploring the menu slowly.  This group would also be more likely to review their dishes after finishing their meals.

  • Any age or gender
  • Hungry
  • Can have dietary restrictions or other specific requests
  • May or may not speak English
  • May want to review food afterwards
  • Might or might not be tech-savvy

We interviewed several people ages 20-45 about their frustrations with ordering via paper menu, and what they would look for in a mobile menu.

One interviewee said he is often frustrated when he doesn’t understand the terms on the menu.  He also dislikes not having control over when the waiter comes over to take his order.  He complained about the lack of an ingredients list.  He wanted to know what the food looks like ahead of time and what other users rated the food.  He would also like to be able to filter for gluten free items on the menu.

Another interviewee was less concerned with how the food looks and more focused on the user reviews.  He wanted to know what are the most popular dishes and what dishes go well with each other.  He said he would write a review after he ordered his food.

A third interviewee mentioned that she has a problem with her accent when ordering food at restaurants (she said the maitré d can be condescending towards her).  She gets frustrated when her food is slow, and she would prefer to know exactly what the vegetarian fare is at a particular restaurant.  She said pictures would be very helpful, especially at an expensive restaurant where she wants to be sure she’s spending her money wisely.  Even though this interviewee acknowledged that she is 45, she said she would feel comfortable using a mobile application (she considers herself tech savvy).

The waiter will submit the user’s order to the chef (not via the app).  He or she will help the user with ordering when needed (perhaps via the app).

  • Any age or gender
  • Speaks English, may speak other languages
  • Familiar with the interface, uses it every day

We interviewed a former waiter at a bar and grill.  He said his biggest problem with taking orders was that the customer wouldn’t be specific enough about their order, and then would be unhappy with their food when it came.  He also said that orders take much longer than expected when the restaurant was busy, which made customers unhappy.  He said his menu was specific and described all of the ingredients and food preparation, but that that’s not typical for most restaurants.

The manager will use our app to upload the menu and pictures of dishes.

  • Can be any age or gender
  • Speaks English, may speak other languages
  • May not be tech savvy
  • Needs to upload the menu and pictures

We interviewed one former manager of a cafe.  He listed a couple of problems he faced with customer ordering: for example, customers not understanding the details of a menu and being out of something the customer wants.  He said the main problem was communication back and forth (maybe he misunderstood what they wanted or they misunderstood him).  He said most of his customers understood the menu but got confused about certain ambiguities (for example, default bread) and about things that changed every day (soup/bread/dessert of the day).

Our website is meant to be accessed in two different settings. On one hand, the Manager needs to update his/her restaurant’s menu information from a web interface, where he/she can easily update the restaurant’s profile. From a different side, users will interact with the mobile-optimized site from their phones and mobile devices.

Why is the task being done?
The site needs to be updated with menu information about the restaurant, so that content can be displayed to users.

What does the user need to know or have before doing the task?
The manager must have information about what items the restaurant will be serving, and knowledge about how he/she wants this information to be displayed. He/she must also have pictures of the food items to display on the menu.

Where is the task being performed?
The task is performed on a desktop or laptop computer, either in the restaurant or at home.

How often is the task performed?
The task only needs to be performed as many times as the menu information changes or whenever there are new pictures to be uploaded.

What are its time or resource constraints?
There are no time or resource constraints on the user here, especially if he/she is working from home. However, we hope that the user will be able to quickly upload a picture of an item on a menu, and the description of its ingredients quickly.

How is the task learned?
The task will be structured like a basic webform, which is quite learnable if the user is used to working with websites, but will also be made obvious by the nature of the form.

What can go wrong? (Exceptions, errors, emergencies)
- The user can insert improper and/or incorrect information.
- The information entered can be confusing.

Who else is involved in the task?
No one else needs to be involved in the task, but the manager may ask a chef or photographer to help update the restaurant profile.

What are the subtasks?
- Adding the restaurant description
- Creating individual menu items
- Uploading pictures of individual menu items
- Adding details to individual menu items
- Saving the description

Why is the task being done?
The client may want to search for a particular restaurant to see its menu, or to find restaurants in the area.

What does the user need to know or have before doing the task?
The user can either search by name, in which case he/she should have the name of the restaurant. Otherwise, the mobile app will use location to search for restaurants.

Where is the task being performed?
The task can be performed anywhere, although it has special behavior if performed at the same location as the restaurant.

How often is the task performed?
This task is performed whenever the user wants to eat or search a menu.

What are its time or resource constraints?
There are no resource constraints but time might be constrained by the client’s hunger or desire to order food. Furthermore, a search is especially tilted in the favor of efficiency.

How is the task learned?
The task is meant to be intuitive and learnable, mirroring other interfaces that users will have seen if they are already mobile phone users.

What can go wrong? (Exceptions, errors, emergencies)
The task is meant to inform clients of the restaurants available to them in an innovative way, and the client will not be able to provide any feedback through the site.

Who else is involved in the task?
No one.

What are the subtasks?

Path 1:

- Check in via-location
- Presented a list of restaurants to choose from
- Select the restaurant

Path 2:

- Enter query into a search bar
- Choose the relevant text-matched name for the restaurant

Why is the task being done?
The task is being done to see what items are offered at the restaurant that the client is currently eating at or interested in, and to see pictures of said items.

What does the user need to know or have before doing the task?
The user needs to know the restaurant's menu he/she wants to view, and his/her experience might be shaped by a desire to filter the menu by criteria such as dietary constraints or food cravings.

Where is the task being performed?
The task can be performed inside of the restaurant before the client orders or while on the go as a precursor to deciding to visit the restaurant. Anywhere the user can access the internet from his/her mobile phone is a valid location for the task.

How often is the task performed?
This task is performed whenever the user wants to eat or search a menu.

What are its time or resource constraints?
There are resource constraints for data downloading/uploading and time might be constrained by the client’s hunger or desire to order food. Quick feedback to the user is essential in this case.

How is the task learned?
The task is meant to be intuitive and easily learnable. On occasion, waiters might be trained in this task in order to help the client learn the task or search the menu themselves.

What can go wrong? (Exceptions, errors, emergencies)
- The client can select the wrong restaurant.
- The client cannot browse the menu efficiently enough.

Who else is involved in the task?
A waiter can potentially aide the client in using the app, but it should mainly be used by the client.

What are the subtasks?
- Click on the relevant menu subitems
- Scroll through the relevant food items
- Click on food items for more specific information

Why is the task being done?
The user wants to see or show a more specific list of the items presented on a particular restaurant menu.

What does the user need to know or have before doing the task?
The type of filter that needs to be applied i.e. vegetarian, gluten-free, meat-only, etc.

Where is the task being performed?
The task can be performed inside of the restaurant before the client orders or while on the go as a precursor to deciding to visit the restaurant. Anywhere the user can access the internet from his/her mobile phone is a valid location for the task.

How often is the task performed?
This task is performed whenever the user wants to get a more specific idea of the menu.

What are its time or resource constraints?
There are resource constraints for data processing and time might be constrained by the client’s hunger or desire to order food and quick feedback.

How is the task learned?
The task is meant to be intuitive and easily learnable. On occasion, waiters might be trained in this task in order to help the client learn the task or search the menu themselves.

What can go wrong? (Exceptions, errors, emergencies)
- The client can select the wrong restaurant.
- The client can select the incorrect filter, and the incorrect specifications to apply it to.

Who else is involved in the task?
A waiter can potentially aide the client in using the app, but it should mainly be used by the client.

What are the subtasks?
- Selecting the relevant filter
- Applying the filter to the relevant list of menu items

Why is the task being done?
To provide feedback to other customers

What does the user need to know or have before doing the task?
What food they have just eaten and the restaurant they have just eaten it at

Where is the task being performed?
The task is performed at the restaurant after the food is eaten, or at any other location that the user prefers

How often is the task performed?
Every time a user eats an item, and wants to provide feedback

What are its time or resource constraints?
There are resource constraints for data processing and time might be constrained by the client’s willingness to rate a menu and the efficiency with which a submission can be made.

How is the task learned?
The task is meant to be similar to reviews on Amazon or Yelp, demonstrating consistency

What can go wrong? (Exceptions, errors, emergencies)
- The client can select the wrong menu item
- Malicious users can submit incorrect or unnecessary reviews
- The reviewer can enter incorrect information

Who else is involved in the task?
The waiter and manager can view the reviews as feedback.

What are the subtasks?
- Select the appropriate restaurant
- Select the correct food item
- Write a review
- Submit a review

  • No labels