...
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 |
...
Reflection
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 be
easier 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.
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.