...
| Panel |
|---|
We initially specified 3 three user groups that would use our interface: the older parent, the college student, and the waitress. For the older parent group, we asked one of our own parents, who isn't technology savvy and fits the group. For the college student, we asked one of our friends, perfectly fitting into this group. For the waitress group, we asked one of our friends that was a waitress, again an ideal representation of this group. |
Description of User Testing Procedure
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:
|
Description of User Testing Procedure
| Panel |
|---|
For each |
| Panel |
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. |
...
| Panel |
|---|
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. |
...
# | Title of the Task and Statement to User | Steps of the Task (For our personal use) | ||||
|---|---|---|---|---|---|---|
1 | Viewing and Ordering Foods
| 1. Scroll through the menu | ||||
2 | Play Some Games
| 1. Navigate the game screen | ||||
3 | Pay the Bill
| 1. View the bill | ||||
4 | Filtering Search and Comparing Foods
| 1. Search for items | ||||
5 | Ask for Help
| 1. Click on the help button |
...
Description of Problem | Type of Usability Issue | Possible Solution |
|---|---|---|
User did not understand what "Compare List" button did (older parent) | Affordance | Change Wording 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" |
4. Reflection
| Panel |
|---|
User and Task AnalysisComing Soon. |
| Panel |
|---|
DesignsComing Soon. |
| Panel |
|---|
Paper & Computer ProtypingComing Soon. |
| Panel |
|---|
Heuristic EvaluationsComing Soon. |
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
| Panel |
|---|
User and Task AnalysisWhat 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. |
| Panel |
|---|
DesignsWhat 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. |
| Panel |
|---|
Paper & Computer PrototypingWhat 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. |
| Panel |
|---|
Heuristic EvaluationsWhat 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. |
| Panel |
|---|
User TestingWhat 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 |
| Panel |
User TestingSomething 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. |