GR6 User Testing

Design & Implementation

Screenshot	Design Description	Implementation
	Instead of having a lengthy tutorial or video explaining exactly what our application did, we decided to put a short blurb on app startup The rest of the directions on how to use the application would be conveniently placed throughout the app in the form of helpful toast reminders that were static or pop-ups. We decided to use this method because most users we talked to did not want to bother with a lengthy tutorial video explaninig function/usability.	Static page with an image for the description and a single button to continue for simplicity
	Our home page consisted of a list of old trips that the user created, and a small input segment for new trips to be added. We decided to keep our home interface clean and simple because we realized this made the app more organized and easily accessible by our users. The top menu bar easily allows the user to navigate to each of the 4 different pages in our app, the home page, packing tips page, packing page, and settings page. We resized our icons to be larger after initial user testing showed us that users were having difficulty pressing the buttons if they had smaller than average smartphones.	A SQLite database was used for the backend, storing each trip along with the trip information the user inputs in it All data is stored internally on the phone The list of past trips, when selected, will lead to the packing page for that specific trip A single text field allows users to enter new trips Pressing the continue button will lead to the trip information page, where users can enter trip data, but does not save the trip in the database just yet We decided to delay saving the trip into the database until after the user had entered their trip details for safety reasons, since users could decide not to add the trip and back out of the page, leading to extraneous data entries in the database To eliminate the need for a context menu and save space for the application, an action bar at the top with buttons to navigate between the main pages of the app was implemented
	Our trip settings page was created with efficiency in mind. Pictures are much more expressive than drop down word menus would be, so for each setting we used a big icon to represent that particular setting To keep the app less cluttered, we used simple colors (white and grey) with torquoise to make certain images (aka, the highlighted/pressed buttons) stand out. These color decisions were made after users explained that selecting some buttons seemed to have no feedback.	We used Android's SharedPreferences feature to keep track of the current trip name the user is accessing on the phone SharedPreferences were also used to keep track of the choices the users made in selecting/entering trip information Once all trip information is entered, and the user hits continue, the information is added into the database and a list of items is generated The trips are canned - 2 trips were programmed into the app, and one trip is randomly chosen as the user's trip The quantity of items are determined by the duration of the trip and the item itself (e.g. for a 7 day trip, the app suggests bringing 7 shirts but only 1 toothbrush) Error checking is apparent when the user tries to continue without filling in all the information - the page will not advance, and a toast will appear prompting the user to fill out all information Information is not saved when the user decides to go back, since we decided not to distinguish between users accidentally hitting go back and users intentionally going back for sake of time in developing the app.
	In our packing section, our final design included two major components, a shelf and a backpack. Things on the shelf represented items that needed to be packed and things in the backpack represented things that you already packed. To show which items belonged to which object, we had a bubble in the middle of the screen that either pointed to the backpack or the shelf, depending on which object you were currently looking at. The bubble concept was added after intial tests revealed that users were confused as to which view they were currently looking at, the shelf or the backpack.	To represent the different categories of items, a tab layout was implemented The shelf view with the items to be pack displays items in the category of the selected tab, which is tap-able and draggable as well Tapping items to add to the bubble underneath will log that many copies of the item as packed in the database Tapping items in the bubble will do the opposite The backpack is also a listener for drag events, allowing users to pack items in bulk Each item is given an automatic weight of 1 lb, and the scale to the right of the backpack displays the weight of the items in the bag
	Items from the shelf could be tapped or dragged into the backpack. These items would then appear in the bubble above the backpack, indicating that these were the items that were already packed. Beside the backpack is a weight that tells you how heavy your current items are. The backpack will change into different forms of transportation depending on how heavy your total items are. For example, if you are carrying 50lbs worth of material, the image of the backpack would change to a luggage case. Once again, these decisions were made because an image is more expressive than numbers or words, so this visual representation of weight helps the user's efficiency.	The application keeps track of the weight of the items in the bag, changing the image based on weight
	The edit mode of our application is the mode in which you "edit" the shelf. The user would do this in two conditions: 1) he doesn't want to bring a particular item that the app auto generated for him to bring, or 2) he wants to add an item that the app did not generate for him. When entering edit mode, a trashcan will appear in the bottom left corner to indicate that dragging objects into the trashcan will delete them. Additionally, + marks appear at the bottom of each item, which signifies that you can add additional items. If the items you want do not appear, there is also a small input that appears right below the shelf which says "add new item."	The edit button switches the application into 'edit mode', changing the bubble to contain items that, when tapped, will be added to the unpacked list in the database. The list of items contain all the items viewable from each category tab The trashcan is also a listener for drag events, allowing users to discard items they do not want to pack from their shelf Editable text fields allow the user to add items not visible in the current list to the shelf
	The packing tips, weather, and helpful destination-based information are located in the help menu. This page was designed as a simple 3-tab, easily navigatable help menu for users to check when they wanted trip-specific information. During heuristic evaluations, users complained that the original black background of the packing tips did not fit the overall color scheme of the app, so the background was instead changed to white and the highlights were kept blue. The tab was also changed white to match the background of the tab that was currently in view	Viewing trip information, such as packing tips and weather information is visible via the question mark button in the action bar Tabs reveal static pages displaying information based on the trip chosen

Evaluation

Testing Procedures

Three users were selected for testing. All three users have been on a trip that requires planning of what to pack - and have different problems with packing that could potentially be solved by this application. Two of the users explains that they go on a similar vacation every year. Two of the users describes that they are often unsure of what to bring when they go to somewhere they have never been to before. One user describes having forgotten to bring enough socks once.

Because this app is highly focused on efficiency (being able to quickly move and checkoff items), there are shortcuts that can be better understood by learning from other sources (eg: other people, or a short introduction video). In this case, learnability was sacrificed in this area in order to simplify the application, and to conserve the limited mobile screen space. The testing procedures were as follow:

A briefing video was shown to the user that summarized the purpose of the application, and gave a few pointers to using the application. The video can be found here.
Users started the application, and were given enough time to read the introduction.
Users were given a series of index cards that contained a task (shown below), and were told to complete each one as specified. There were 11 tasks in total, each task targeting a different functionality of the application.
Users received Skittles candy as compensation for taking time out of their busy schedules to test our application.

Raw Observations

These are observations that were recorded during the testing procedures. The document can be found here(opens a google document).

Summarized Observations

These are summaries of what was observed throughout the three users that tested PackIt.

No.	User Task	Summarized Observations	Plans for Improvement
1	Create a new trip called "Alaska Vacation", by plane from June 1st - June 8th	Users generally had no problem completing this task. The particular android phone we were using did not have a clear ENTER / DONE button on the built in keyboard, and one user was unsure of how to finish typing and close the window.	None
2	Pack 2 shirts into your backpack	Two of the users intuitively dragged the items into the backpack, then realized it dragged all the shirts as opposed to just 2. One of the users attempted to drag all the items back, but was unable to do so as this function does not exist. Users that made the mistake were able to move the items back on the shelf after they had understood the difference between dragging and clicking, and easily corrected their errors	Implement ability to DRAG items to different parts of the application, and not just to the backpack (eg, to the shelf, to the bubble that described what was in the backpack). Make the distinction more clear at the beginning - perhaps some popup TIP dialog.
3	Pack all the socks	One user tapped once, then realized it was possible to drag everything at once, and so did so appropriately. One user tapped multiple times in order to get all the socks into the backpack. One user dragged (most efficient method)	Emphasize distinction between dragging and clicking (as mentioned above
4	Unpack 1 shirt	Users had no difficulty performing this task	None
5	Add 1 shirt to the shelf of things 'to pack'	Users had no difficulty performing this task	None
6	Edit the shelf so that you won't be bringing any pants	Users had no difficulty performing this task. One user attempted to click instead of dragging items to the trash can, causing a minor bug to happen	Correct the bug that packs your item when you are in the 'shelf editing mode'
7	Add 4 pairs of sunglasses to the list of things to pack	One user was confused because the shelf did not change to the category when socks were being added, and so was unsure of whether or not socks were actually being added	Modify program such that when anything is being added to the shelf, the shelf changes to the category of the item being added
8	Add 1 fishing rod to the shelf of things 'to pack'	Users had no difficulty performing this task, although when one user forgot to input the number, the original item that had been typed in disappeared. In addition, the screen becomes extremely cluttered when the keyboard appears	Change the look of the screen when the keyboard appears, and make it so that what was typed does not get removed even if the entry is invalid
9	Pack the fishing rod	Users had no difficulty performing this task	None
10	Change your settings so you are now driving to Alaska	Users had no difficulty performing this task	None
11	View the weather information for your trip	Users had no difficulty performing this task	None

General Summary

It is clear that the distinction between drag and click is not clear (for moving items into the bag/out of the bag/onto the shelf). This can be corrected with several methods - having a tips page at the beginning that is shown to the user or showing a user a tooltip if they are detected to be clicking multiple times in order to move everything into the backpack. In addition, because of time constraints, the dragging model was not implemented the other way around (so moving items in the backpack back up to the shelf). This should be implemented as it would greatly help the consistency of this feature. As well, a minor issue arose when the keyboard appeared during the 'add non-existing item' feature. The screen became cramped as elements were overlapping, and an easy fix to this problem is to make the screen scrollable such that during this action the entire screen scrolls up to make room for the keyboard.

Reflections

What we learned

Over the course of the iterative design process, our team learned a great deal. The most important thing we learned was something very fundamental to UI, we were reinforced by the fact that the designer thinks very differently from the user. What seems so clear to the designer may be completely confusing the user. Because of this we had to try to think from the users standpoint, and make every aspect of our app as simple and clear as it could possibly be. Another thing we learned was the sometimes sacrifices need to be made for the overall goal of usability. In some parts of our app we needed to sacrifice learnability for efficiency. For example, one of our very first drafts of the app included three seperate tabs, one with a visual representation of the list of items to pack (aka backpack/shelf, ect) and one with a text representation of the list, which could be edited to add new items, ect. However, we realized that this would require the user to go back and forth between two modes many different times, which would be very slow and annoying. Although it would beeasier to see list of items to pack in two forms, it was a much better idea to keep it simple and efficient and only showcase one mode.

What we would change

If we were to do this project over again, we would do several things differently. We would prototype the main feature of the app more thoroughly. When changes needed to be made to the app after user testing, we would make sure to create/sketch a completely new draft that included these improvements, instead of just editing it a little at a time based on each new comment, as that allows for some sloppy errors in the long term. (For example, you change one thing but have to change it back based on other users opinions.) Anther thing we would change is to prototype a more realistic looking version of our application. The paper prototypes were much bigger than the screen size of any of our phones, and we felt that this allowed certain objects to look better on paper than they actually turned out to be on the phone. The final and most important thing we would do differently is to really listen to every comment a user makes. Sometimes it is easy to think that the designer is correct, or that the designer's implementation is good enough and that the user will "get it", but in the end the user is always correct. Some details the users mentioned were confusing ended up being a big problem when we finally created a working version of our application. More focus on these details during the testing phase would've helped us a lot for our final app.

Child pages

GR6 - PackIt User Testing