Usability Testing

To measure the usability of our application we tested 6 users on completing a set of tasks that we prepared based on the goals to be accomplished. For each user observations were made on completion of tasks. Also to test the functionality of all the areas of our application we created the two scenarios mentioned above to record more observations. At the end of the test the users were given a short questionnaire to fill in for additional information about their experience having the test. The observations were analyzed and the conclusions were made as follows.

Questionnaire results
1. All users agreed that they could complete all the tasks given.
2. 3 out of 6 users had problems reaching their goals mainly due to the fact that that it was unclear if they had actually selected an item from the menu.
3. All users agreed that they would use the application again whenever they have the need for ordering.
4. Generally almost of the users found out application very simple to use with the exception of 2 users who found it moderately difficult because of the problem identified in result (2).

Success Rate: We had an overall success rate of 100% of user being able to complete task and a 50% failure rate if users not being able to reach their goals.

User behavior: The users understood the task and were comfortable and relaxed during the test. They recognized the different components of the user interface and could use them based on working knowledge

Speed: users were able to finish the test on an average of fewer than 3 mins

Conclusion
We believe that our usability test was successful and we captured the most important areas of our application that work well and the parts that still need to be improved.  In addition we tested for failure, user behavior and speed.

Usability Test 1

Usability Test 2

Usability Test 3

video 3

Usability Test 4

video 4

Usability Test 5

video 5

Usability Test 6

video 6

Screens of the Application

Welcome Screen

Menu Food

Menu Drinks

Menu Specials

My Order

Final Screen

UI Design

Last week we did the sketch and story board for our application. This week we finally started to design it, using a tool called Indigo Design, where we added pictures, colours and some functionality so the user can visualize how the application will look like when its ready.
You can check it out the result on the link: Easy order App

Sketching & Prototyping : Design Part 1

Designing the structure

Now that we have a good hierarchial information archtecture and most of our navigation is organized we will be adding more structure through designing the UI using activity flow diagrams , sketches and storyboarding . Also paper prototyping guerilla tests were performed with our users which helped to refine misunderstood or uncertain areas of our design.

Flow Diagrams

To understand the logical sequence of activities in the easy order application we choose 2 main activities that define the application

1. Placing an Order
2. Checking out "MyOrder"

Navigation Structure
The navigation structure is a combination of the two previously mentioned flow charts above. This will help us understand how the two activities come together to help the user accomplish their task / goals.

Sketches 

The sketches are visual representations of the UI that will be used to test the users in the guerilla test. The reason for the paper based sketches are primarily because they are easy to change and update after user reviews.

Gestalt

We use the laws of gestalt to add more clarity to out application user interface. For the menus "proximity" was user to space icons and "grouping" in rows and columns.

Affordances

This can also be found in our design where we have indicated in the side menus active & inactive menus that are "depressed" when active and "raised" when inactive also color shading.

 

Storyboard

-       Storyboard is a sequence of drawings, typically with some directions and dialogues, representing the actions need to be taken in order to reach the goal.

-       In our storyboard we have given a very summarized information, the reason is that user performs the same activity in all three sub menus.

Final flow diagrams & storyboard

The flow diagrams where not changed as they defined the activities efficiently and accurately.These are our final sketches of the storyboard after considering the problems from users after the guerrilla test.

Hierarchal Information Architecture

The architecture will be comprised of a sequence of logical steps/activities that will lead to a desired user goal. The purpose of the structure is to organize information in a way that is useful to the end user.

To achieve this we have looked at the application activates and categorized into the following

- Menu Items
- User Actions

Technique used to design the application information architecture

Card sorting was the primary technique used to collect information about how our target group perceived the application architecture and giving use valuable data for improving it further.

This exercise was conducted for determining the finalized the architecture of the application that was initially designed. The results of this exercise served as input for rethinking the proposed hierarchical information architecture and make changes where necessary after discussion. 

Before Card Sorting

After Card Sorting

0. The final information architecture we have decided after taking consideration from the users card sorting exercise are 2 major changes
   
1. 
   
 Alcohol submenu
- This sub menu will be better for our users to select from a number of
different types of alcoholic beverages 

 Add/edit menu

- We have decided to rename this menu to checkout mainly because of the miss understanding of the purpose of the menu. Renaming it to “Checkout” will be clearer to our user and add/edit will be an action that can be performed.

Guerilla Understandability Testing

What we did ?

After we developed the sequential flow of activities within the application through well-defined flow charts and sketching storyboards we carried out a guerilla test to determine the user ability of our application, based on their ability to navigate through the application and accomplish user goals.

The Guerilla Test Setup

The test was executed with a designer present taking important notes from the user while administering the test. The designer asked specific questions and received good feedback and also additional explanation where needed. Most importantly the users were allowed to “think out loud” to process the sketches and give logical reasoning for making choices or decisions to accomplish goals. The test was recorded and the team analyzed results.

Guerilla Test#1
https://drive.google.com/file/d/0B8nDbyWKpofid0NacTlZVFhYQmM/view?usp=sharing

Guerilla Test #2
https://drive.google.com/file/d/0B8nDbyWKpofiYVIyUnlaVUw1dUU/view?usp=sharing

Guerilla Test Findings
Generally the application paper prototypes were well understood by our users during the test. They were able to move from one user interface screen to another and perform actions with good reasoning and judgment. Most of the users were able to go through the application from start to finish with just a few exceptions
Observations

Problems found

1. Some users used the “done” button for the wrong function. They pressed the button
   before they wanted to switch to another menu (e.g. food, drink).
   
2. The users recognized that the edit button at the button of the home screen
   performed the same function as done because they both lead to the “MyOrder”
   screen where items could be also edited.
   
3. So of the users missed the specials menu and only went to food and drinks and
   proceeded to checkout.
   

Solutions /Changes
The team has decided that making the “done “button inactive before and order is placed and inactive if the ordered items are empty. Also the “done” button will show a popup message informing the user if he/she wants to proceed to checkout and only redirect to the “MyOrder” page.

1. The “edit” button will be removed from the home screen so that the users are not confused but the “edit” button in the “MyOrder” page will remain to help user remove items from their order.
   
2. We think that relocating the specials menu in a more significant location on the screen might increase the chances of selecting form the special deals apart from ordering only from food and drinks.
   

Card Sorting

Card sorting was the primary technique used to collect information about how our target group perceived the application architecture and giving use valuable data for improving it further.

This exercise was conducted for determining the finalized the architecture of the application that was initially designed. The results of this exercise served as input for rethinking the proposed hierarchical information architecture and make changes where necessary after discussion.

Card Sorting Test #1

Card Sorting Test #2

Final Ordered Cards

Card Sorting Results

In the card sorting we found out from users that one main menu wasn't clear as it barley represented the sub menu. So we decided to make that main menu to be sub menu and replaced it with a main menu that can represent all the sub menus. That is the only change we came to because users have easily sorted the cards.

	Group One	Group two	Group three	Group four	Group  five
Card 1: Alcohol	1	0	0	0	1
Card 2: Soft drink	2	0	0	0	0
Card 3: Juice	2	0	0	0	0
Card 4: Warm Drink	2	0	0	0	0
Card 5: Chicken	0	2	0	0	0
Card 6: Sandwich	0	2	0	0	0
Card 7: Burger	0	2	0	0	0
Card 8: Specials	0	2	0	0	0
Card 9: 5 beer 4euros	0	0	2	0	0
Card 10: 2 burgers + drink	0	0	2	0	0
Card 11:  Pay	0	0	0	2	0
Card 8: Cancel	0	0	0	2	0

Groups names: Drinks, Food, Specials, Add /Edit and an extra group created by the users Alcohol

To the highest extent the potential users arranged the information architecture as we designed. There was a slight difference. For example one users selected alcohol as a different rather than a sub menu to drinks. Another user have a bit difference in the add menu buying choosing pay as the main menu rather than a sub menu to the Add/Edit menu.