...
It’s important his mischievous friends don’t see his password while logging in. Additionally, this agreeable group of friends will likely search for several different movie titles, before agreeing on one they’d like to watch.”
Scenario Tasks
Task 1:
Task 2:
Task 3: This is a picture of task 3 from our second iteration. On our first iteration, the task told users to incorrectly type a letter to simulate making a mistake. For our second iteration, the task did not tell users to mistake, rather during testing, when users were halfway complete with task 3, we told them to “change a letter”. We found users in our first iteration became preoccupied with making a mistake, and our prompting would more closely match an actual error.
Observations/Photos
User testing pointed out two types of flaws in our design
1) Actions which we thought were intuitive
2) Actions we hadn’t considered
We successfully conceived and covered all the cases that our users attempted, but our users pointed out very basic actions, which we designed, that they found counter intuitive.
Below are pictures of our first paper prototype with a brief explanation of how we ran it.
Users were given these controls to manipulate.
An important feature of our prototype was indicating focus. In our paper prototype we indicated focus by pointing a big yellow arrow at the focused object. Users were told that in an actual design, this would likely correlate to a highlighted background.
There were a set of onscreen directions that changed depending on “focus”. In our second prototype, we were able to remove some of these instructions and put them directly on our interface.
Keyboard_pp_lower
Keyboard_pp_upper
Keyboard_pp_number
Users iterated through different character sets (uppercase, lowercase, numbers/punctuation). This is clearly a necessary function, but user testing showed our implementation (hitting “down” from the root node) led to breaking to some internal inconsistencies. After hitting down and cycling through the character sets, users expected to be able to hit the “up” arrow to cycle upwards through the character sets, but this brought them into the box containing previously typed letters. This was something we changed in our second prototype. In our second prototype, hitting down, brought the user into a selection mode, where up or down cycled respectively through the character sets, and a set was only chosen when the user hit “select”. This proved better, but we had to indicate to the user “hit select to choose a character set”. This prevented the accident “up” error, but users found it cumbersome, and one user hadn’t realized they changed modes. This is something we still need to iterate on.
Keyboard_pp_2
As the user made selections, we added or removed nodes from the tree, and changed focus.
Keyboard_pp_3
For selecting letters, we tried to implement a paper “focus” using a paper frame around the focused letter.
Keyboard_pp_autocomplete
We designed a modified “autocomplete”, which based on previously typed characters suggested likely values. This could be very helpful, but only if it required few key presses to select. Moreover, it did not fit well with our metaphor of traversing the tree. (See the bottom of GR2, design 2 for a failed attempt!). Users were told to hold “select” to jump to the autocomplete, which worked well; however, returning to the tree was counter intuitive. Users were told to hold “select” to enter and leave the autocomplete, but once in the autocomplete, which was right of the tree, users wanted to hit “left” arrow to return to the tree. We changed this in our second prototype, which worked considerably better.
...