1. Final Design

Menu Screen

   

Feature

Description

Reasoning

Tab System for Types of Foods

Users can click on a tab such as "Appetizers" or "Drinks" to look at products that fall under those categories

Through user testing, we have found that the tab system was the easiest and fastest method for users to browse for products.

Search Features

By clicking on the red "Search" tab, the user will be able to search for products from all categories using keywords/descriptions.

We initially wanted the user to be able to search for products they want to order based on multiple criteria such as type of food (seafood, steak, etc.), price, and more. However, we found that it was too hard to implement a filtering system and it was hard to learn how to use a filtering system, so we simplified the process to a search feature.

More Information in the Sidebar

When a user clicks on a product, a sidebar will be displayed on the right hand side of the menu. It will display more information about the product such as nutrition facts and anything else the restaurant would like to tell the user about the product.

One of our initial goals of this product was for the user to know more about what they are ordering than a regular user can find out using a regular menu. With this addition, we are able to keep the brief details of the products on the menu more concise while giving the user the ability to learn more about their products.

Pop-up Notifications

When a user adds a product to their order or adds a product to the compare list, a large black pop-up is displayed in the middle of the screen to notify the user that the action has been taken.

When we were testing our computer prototypes, we received input that the user was not receiving enough feedback when performing an action of products on the menu page.

Games Screen

Feature

Description

Reasoning

Ability to Play Multiple Games

Once the user navigates to the Game screen, they have a variety of games to choose from and clicking on the buttons will bring them to a game.

While waiting for food, users are often bored with nothing to do so added games to help pass the tiem. We also made the games multiplayer so that if the user was with friends, they could play the game together as a social event instead of everyone being focused on their own tablet.

Removal of Web Browser

We removed the web browser feature.

While talking to our TA, he pointed out that eating out was usually a social thing, so adding the web browser would keep everyone from interacting with each other. In addition, we realized the majority of people had a smartphone and could access the internet anyways.

Help Screen

Feature

Description

Reasoning

Help Screen

Clicking on the Help screen will alert the restaurant that the user needs help and will call over a waiter to come assist the user.

We found that users often found it frustrating trying to get a waiter's attention when they needed help, so this feature will allow them to directly signal the waiter. In addition, waiters found it difficult to keep track of who needed help and who they needed to check up on so this will signal them when a user needs help.

Compare Screen

  

Feature

Description

Reasoning

Image and Descriptions of Each Product

Each product on the Compare page has a picture, name, price, description, and nutrition facts for the user to compare side-by-side

We found that users often have trouble deciding between items so the easiest way to solve that problem is to compare the products side-by-side in all possible categories to decide which item they want.

Horizontal Scrolling

The items on the Compare list are put side-by-side so if the items overflows, there is a horizontal scroll bar.

We found that it was easier to compare items side-by-side instead of stacking the items vertically, which called for horizontal scrolling.

Add to Order Button

By clicking on the "Add to Order" button, the user can add the item directly to the order from the Compare page.

We found that it was a hassle for the user to close the Compare page, remember which item they had chosen and find the item again on the menu.

View Order Screen

Feature

Description

Reasoning

Viewing All of Your Products

The user can review all their products that they have added to their order so far and the comments they added before sending the order to make sure the restaurant receives the correct order.

Oftentimes, it's hard to keep track of what items the user has ordered or wants to order, so this feature will allow users to keep track of what they have or haven't ordered. In addition, this allows users to make sure that they are sending the correct order to the restaurant.

Ability to Remove Products

If the user realizes they added the wrong item or changes their mind, they have the ability to remove the item from the View Order page by clicking the "Remove Item" text.

This was for safety in case the user accidentally clicked on "Add to Order" on the wrong item or they changed their mind.

View of Your Subtotal

The user can view how much money they have on their bill with all their orders to make sure they aren't spending too much or just to see how much they have spent.

We found that users liked knowing how much the bill would add up to before they send in their order to make sure they aren't going over budget.

Pay Screen

   

Feature

Description

Reasoning

Viewing Your Order

The user can view what items they ordered and how much each item was. It also allows the user to potentially split the bill by figuring out how much each item was worth.

Users like to know how much each item cost and what each item was when they receive their bill. In addition, it's standard on receipts to show a list of ordered items.

Tip Calculator

On the right side of these screen is a tip calculator. The user can either choose from a pre-set tip amount (15%, 18%, 20%), enter their own percentage, or enter a fixed amount to automatically add their tip to a bill.

Users told us it's often a hassle to figure out how much tip to add and waste time trying to calculate how much 15% is. This will allow users to not only easily figure out how much tip is appropriate but to also add it directly to the bill

Two Ways to Pay

The user can either click on "Pay with Credit" or "Pay with Cash" which will bring to different pages. "Pay with Credit" will prompt them to slide their credit card in a slot on the right while "Pay with Cash" will alert the waiter who will come over and collect the payment.

Users often found it frustrating to wait for the waiter to come over to either collect their cash or card to pay. This allows users to pay easily at the table without having to wait for the waiter to come over.

2. Implementation

Our Implementation

We implemented OpenMenu as a web application using:

  1. Javascript & Jquery Framework: Scripting the application together and creating our functions
  2. HTML5: Structuring the skeleton of our web application
  3. CSS3: Styling the looks and aesthetics of OpenMenu.

Why We Choose to Use the Web

We decided to implement OpenMenu as a web application for multiple reasons:

  1. All of our project members were familiar with web development, so we didn't need to learn any new languages.
  2. It can be deployed and tested on multiple types of tablet systems such as tablet PCs, Android Tablets, and iPads.
  3. The current web technologies provided all the tools we needed to implement OpenMenu.

Changes We Made

  1. Removal of Hoverable States: During our heuristic evaluations, we included hoverable states but we quickly realized that it was impossible to get into this state using a tablet system.
  2. Larger Buttons: We also had to make our buttons larger because testers noted that these buttons might be difficult to press using fingers.
  3. Removal of Filtering System: We found that the filtering system was extremely difficult to implement in the time we had. We moved on to survey a large group of prospective users to see if a filtering system was crucially necessary. Users noted that a filtering system might decrease learnability. We found that by further improving on the search feature of OpenMenu, we could avoid implementing the filtering system.
  4. Lack of Implementation for Waiter/Waitress Side: It was simply too daunting for us to implement both the customer AND the waiter/waitress side, so we focused our project to only implement the customer side. If we had more time, we would have included the waiter/waitress side in our application.
  5. Lack of Working Games: If this was a real project, we would have used an outside source and their APIs to include their games into our application. Because it would been extremely difficult to produce our own games into OpenMenu, we omitting including actual working games. 

3. Evaluation

Users

We initially specified three user groups for OpenMenu and we still wanted to test those user groups in our final round of user testing for 6.813. With this in mind we tested OpenMenu on:

  1. User 1 - Parent: We tested the application on one of our parents who spoke English because isn't super tech-savvy.
  2. User 2 - College Student: For this, we tested it on a friend of ours who wasn't course 6 and wasn't taking 6.813. We noted that she something similar to this before at a restaurant.
  3. User 3 - Waiter/Waitress: We tested OpenMenu on a friend of ours who had been a waitress in the past at a chain restaurant.

Description of User Testing Procedure

For each user, we first read a briefing to set up the situation in their minds. Next, we asked the user to complete all the scenario tasks one at a time. Two of us took notes to record what the user said and did.

Briefing

Hello and thank you for help us with our project, OpenMenu! This is ______, ______, and _____.

    Picture this: 

    You are going out to a restaurant on a Friday night with a couple friends. When you are seated, you notice that instead of menus, your waiter has grabbed tablets instead. Your waiter informs you that the restaurant is trying out a new electronic ordering system. The purpose of this new ordering system is to make ordering and waiting at restaurants faster and more efficient and to entertain customers while waiting for their orders to arrive.

    To help us test the system, we're going to ask you to do some scenario tasks.

Scenario Tasks

#

Title of the Task and Statement to User

Steps of the Task (For our personal use)

1

Viewing and Ordering Foods

You and your friends were just seated by a lovely waitress at Mama Mia's.
You are extremely hungry and want to look through choices to order something as
soon as possible. So:
- You go through the menu to order some food
- You proceed to send in your order

1. Scroll through the menu
2. Move between tabs
     -Drinks
     -Appetizers
     -Entrees
     -Deserts
2. Click on each item for more information
3. Add and remove items from their order
4. View your order
5. Send in their order

2

Play Some Games 

You and your friends just ordered some delicious food from Mama Mia's. In the mean
time, you and your friends notice that there are games offered on the device. So:
- You go and browse through the games
- You choose to play Scrabble with your friends

1. Navigate the game screen
2. Click on a game
3. Play a game
4. Go back to the main game screen

3

Pay the Bill

You and your friend just finished your delicious meals and everything was wonderful.
The only thing left to do is pay the bill. So:
- You pay the bill

1. View the bill 
2. Add tip 
3. Choose to pay with cash or card 
4. Pay the bill

4

Search and Comparing Foods

You and your friends are very impressed by the number of items on the menu, but some
want beef while others want seafood. So:
- You search for different items and compare them side by side

1. Search for items 
2. Compare items side-by-side 

5

Ask for Help


You and your friends have just spilled a drink accidentally and really need help from the
waiter/waitress. So:
- You get help from the waiter/waitress using the system

1. Click on the help button 
2. Search through the help on the device 
3. Call your waiter over for help 

Usability Problems

Description of Problem

Type of Usability Issue

Possible Solution

User did not understand what "Compare List" button did (older parent)

Affordance

Change wording

User did not know how to remove an item from their order (older parent)

Learnability

Adding more information of their order in the actual menu (Better Affordance).

User assumed that they can sort the "Compare List" by clicking on the label (such as "Price") (college student)

Efficiency/Affordance

Implement sorting in "Compare List"

User did not know how many of an item they had already ordered (waitress)

Affordance

Display the number of times an item has been ordered on the "Add to Order" button

User thought help button was for device/interface help (older parent)

Affordance/Learnability

Change wording to be more specific to waiter/waitress help

User didn't know you could click on an item to view more information on the product (older parent)

Learnability/Affordance

Make the picture/description of the product look more clickable, like a button

User wasn't sure if "Add to Order" sent in their order or if they had to send in their order separately (older parent)

Learnability/Affordance

Change "View Order" to "View and Send Order"

User removed items by accident on the Order Screen (older parent)

Efficiency/Safety

Add a confirmation prompt before removing the item to make sure the user didn't click it by accident.

User found the radio buttons hard to click for the tip calculator (college student)

Efficiency

Instead of three radio buttons, make it three regular buttons that instantly change the tip once clicked on the percentage.

4. Reflection

User and Task Analysis

What We Learned

When we thought about what we wanted to get out of 6.813, we wanted to learn more about making technologies easier to use for populations that normally don't interact with technology. With this in mind, we decided to make a menu system because menus are used by both technologically advanced users and users who don't even own a computer. This was highly risky but we believed that it would be a great learning experience so we carried on. We learned that interviewing people who would be typical users of our product are extremely beneficial in learning about that the user, the user's technical abilities, and the user's desires in our product. Performing our task analysis was useful throughout the production of OpenMenu because it gave us goals we wanted to accomplish that we can always keep in mind.

What We Would Have Done Differently

We believe that this process went extremely well, and we wouldn't have changed much. We felt as through the user groups we chose were ideal for our product and the tasks we choose were valid for OpenMenu. 

Designs

What We Learned

One of the first things we had to do was write an example scenario which helped us conceptualize how our product would be used in a hypothetical situation. We incorporated all of the tasks that we created during our Task Analysis to confirm that our tasks were still valid. After creating our scenario, each member separately came up with their own design which resulted in three completely different designs for OpenMenu. We choose to do so separately because we didn't want own ideas to conflict with each other before we got all of our ideas on paper. From these three designs, we choose what seemed like good ideas to test for paper prototyping and which ones we wanted to scrap off the board (to save time in implementation and testing). 

What We Would Have Done Differently

All of us focused too much of our time on the "menu" part of the application and we didn't focus enough on the "compare" features, and viewing/paying the bills section of the application. Because of this, our implementation of these features were not as in-depth or creative as we wanted it to be. We should have spent more time designing the rest of the application.

Paper & Computer Prototyping

What We Learned

When we first heard about paper prototyping, we thought it was a dumb idea because it isn't the "real thing." However after actually using paper prototypes, we realized that paper prototyping is a cheap way to get very useful data and feedback from potential users. Even though we had three designs, we still had to choose only one design to paper prototype due to lack of time. Therefore, we choose the best ideas from all three designs to make a single design as a group. One of the things we had to give up testing was the meny system that was using the paper metaphor where users can swipe to flip the menu like a book. We believed that the system was not efficient enough and the risk of taking extra time to test it was not worth it. After both iterations of paper prototyping, we received awesome feedback to change OpenMenu (for the better) and prepare itself for computer prototyping.

As programmers, we found it hard to create a computer prototype without implementing some of the features of the application. We found that we had to realize that we should get the full range of features of the application but not implement the back-end of it.

What We Would Have Done Differently

We found have changed how we tackled the computer prototyping process by putting more emphasis on the "look and feel" of the application and not wasting so much time implementing some of the features. However, we are still proud of the look and feel of OpenMenu but there could have been room for improvement.

Heuristic Evaluations

What We Learned

Throughout the course, we placed great emphasize on the phrase "you are not the user." Though this concept is very important in the design and implementation of an user interface, technical analysis and feedback is also important in the creation of an intuitive, easy-to-use interface. We were able to use what we had learned in the course to offer suggestions and better other groups' interfaces while the act was reciprocated for our interface as well.

What We Would Have Done Differently

Because of the importance of heuristic evaluation, we would run more rounds of heuristic evaluations after each design/implementation of our interface.

User Testing

What We Learned

Something that surprised us when we were doing user testing is how some things that seemed obvious to us were confusing the users. One example was how users weren't sure what the "Compare List" button did, whereas it seemed obvious to us when we were designing and implementing. We tried to take all the feedback from the users and incorporate it into our next iteration of our product. For example, we added more feedback when the user added to order or to the compare list by updating the number of items currently on the order or compare list. Another thing we really learned from user testing was to make everything as simple as possible since a lot of things appear obvious to us since we were the one that designed and implemented it, but appear completely different to the average user.

What We Would Have Done Differently

The User testing went really well and we learned a lot from it. The feedback we got was really useful in improving our product. We don't think we would've changed much from this process.

  • No labels

1 Comment

  1. on GR5:

    Presentation: Good briefing.
    Usability: Evidence that you learned from paper prototype testing and heuristic evaluations.
    Completeness: Good: UI seems complete enough for user testing of the scenarios
    Answers to our questions: It's clear that you've put quite some some thinking on the layout and how to reduce clutter. Congratulations

    on GR6:

    Overall Wiki presentation: clearly structured, and up to date but a few sentences are incomplete:
    '...our parents who spoke English because isn't super tech-savvy.'
    ' We noted that she something similar to this before'
    Design description: clear presentation, screenshots, and mentions of how design evaluations were motivated by evaluation
    Evaluation: very good
    Reflection: Great that you exposed  ""lessons learned"" from each of the design phases.