Phone Design

Usability Test Results & Revised Design For Paper Prototype of a mobile phone address book

Team Wei-Cheng Wu (David) Chung-Shun Feng (Fong) Michael Matunry Rutu Upadhyaya

— 02623500 — 02462644 — 02069839 — 02491105

Usability Test Results Report David – Feng – Michael ‐ Rutu

Introduction Our team of four – David, Feng, Michael and Rutu; conducted a usability test for the paper prototype of an address book for an old design mobile phone. The usability test was carried out as a paper-and-pen format with 4 different users. From our team one person acted as a facilitator, one as the phone processor and two team members observed and recorded testing procedures. Each user was given instructions explaining the testing process and then provided with four scenarios where the user would have to use our address book design. This document explains the testing process, information about the subjects, findings and recommendations for further revisions.

Users who tested our design User 1

Gender Occupation Age group Duration

Female Student at Academy of Art university 20 – 25 9 minutes

User 2

Gender Occupation Age group Duration

Female Student at Academy of Art university 20 – 25 8 minutes

User 3

Gender Occupation Age group Duration

Male Student at Academy of Art university 20 – 25 9 minutes

User 4

Gender Occupation Age group Duration

Female Faculty (Academy of Art University) and User Experience Specialist 10 minutes

1

Usability Test Results Report David – Feng – Michael ‐ Rutu

User testing process The user testing process was broken up into 4 main processes 1. Facilitator’s instructions, 2. User tasks, 3. Processing user actions and 4. Recording observations

Facilitator’s Instructions A facilitator’s job in the user testing process is to introduce the project, explain the purpose of testing and how the test shall be carried out. Here is the script we prepared for our facilitator to read out to the user – Thank you for helping us test our address book design of a mobile phone. The purpose of this usability test is to identify problems and improve our design. We want you to know that we are in no way trying to test or analyze you. We are only testing our design.

(Name of team member acting as Processor) here will act as the mobile phone processor. As and when you press a particular button, (Name of team member acting as Processor) will change the phone screen for you. I will be the facilitator and I shall walk you through the testing process and will answer any questions that you may have. We also have two of our team members (Names of team members) who will be the observers and they will record their observations based on the way you use our design.

Testing process Since this is a paper prototype test, we will not be using a real mobile phone, but instead we will be using this paper and it will act as the actual phone.

We would like you to think aloud every action that you are carrying out, for instance if you are going to press the menu button, then say “I will press the menu button”. This is only so that we can see and understand your thinking process while you use our design.

While operating this paper phone - the text that you see on the lowest part of the screen paper is corresponding to the buttons below. E.g. text in between would correspond to the middle button.

It will take about 20 minutes to do the entire test. If you need to take a break in between or have any questions please let us know.

Once again we would like to state that we are not testing you in any way, we are only here to test our design.

Do you feel that the instructions were clear?

Thank you, we can now begin our actual testing process.

2

Usability Test Results Report David – Feng – Michael ‐ Rutu

User Tasks We wanted to test four parts of our design – adding, calling, editing and deleting a contact. To personalize the user experience, we created a story with the user wherein he/she has to use all four said aspects of our design. We simplified this process by breaking the story and the tasks into four smaller groups. Here are the scenarios created for the user Scenario 1 – Your design has been chosen to be displayed in the spring show. At the spring show someone from Pixar approaches you and praises your design style. He introduces himself to you as Ben. Ben has unfortunately run out of his business cards and asks you to write down his office number so that you can call up and set up an appointment with him. Since you only have your cell phone in hand you attempt to store the number into the phone.

Scenario 2 – So the next day you call up the office and set up an appointment.

Scenario 3 – When you reach the office on the scheduled day, you find that Ben had to attend to some urgent work, so he leaves a message for you at the reception desk asking you to meet another colleague and show him your portfolio. He also asks you to call him on his mobile phone, so when the receptionist gives you the number you edit his stored information and add Ben’s mobile number to it.

Scenario 4 – On your way out you bump into an old friend of yours, and realize she also works at Pixar.

You want store her number in your phone, but your phone book has no more space in its memory, so you want to delete a number. You realize that from your list of contacts – Chris is someone you had met ages back and have never called him and probably never will, so you delete his number.

The tasks were made easier by keeping a piece of paper in front of the user with just add, call, edit or delete instruction and the name and number of the corresponding person as shown below -

Add New Contact Ben (Office number) 415‐123‐7862

3

Usability Test Results Report David – Feng – Michael ‐ Rutu

Flow chart of screen layouts (Original Design)

4

Usability Test Results Report David – Feng – Michael ‐ Rutu

5

Usability Test Results Report David – Feng – Michael ‐ Rutu

6

Usability Test Results Report David – Feng – Michael ‐ Rutu

7

Usability Test Results Report David – Feng – Michael ‐ Rutu

8

Usability Test Results Report David – Feng – Michael ‐ Rutu

9

Usability Test Results Report David – Feng – Michael ‐ Rutu

Observations Two members from our team observed user actions and recorded the problems found in the design as per the tasks given to user.

Activity / User Task

Add new contact Ben’s Office number

Call contact Ben

Observations User 2 had a little confusion between “contacts” and “calls”

Problem with Design While most phones do have just “calls” written, we thought maybe it is confusing

Fixing the design We changed the “Calls” menu to “Call log”

User 4 expected the name, phone numbers and address to be on the same page. The “next” to go from one field to another was confusing.

“next” had to be pressed at least 3 times before you could save a contact.

We decided to put all the contact fields into one screen which can be accessed by scrolling up or down and directly saving after the user has finished entering the details he/she wants.

User 1 went into Menu> Calls by mistake and then wanted to go back and the C button had no indication that it would take her back to the previous screen.

We need to indicate what the C button refers to in most screens.

We improved the design by adding “back” corresponding to the C button.

User 3 entered the number into the main screen and then hit save and expected it to allow user to add it to an existing contact.

We did not have an option to add an entered number to an existing contact.

We did not have any indication as to which contact the options list corresponded to.

We designed the interface such that you can save the number entered into the main screen as a new contact or into an existing contact.

User 4 went into Menu>call log > select contact > options – Then the user expected to see the contact’s name above the options list to know which contact is being edited.

In the options screen it showed no indication of which contact the options list corresponded to.

We added the contact name as a title on the options list screen.

User 4 found the confirmation screen “yes” or “no” as inappropriate questions.

“yes” and “no” questions can confuse users.

An improvement would be to write “cancel” and “confirm” delete.

Edit Ben’s number and add a mobile phone number to the existing contact

Delete the existing contact Chris

10

Usability Test Results Report David – Feng – Michael ‐ Rutu

Flow chart of screen layouts (Revised Design)

11

Usability Test Results Report David – Feng – Michael ‐ Rutu

12

Usability Test Results Report David – Feng – Michael ‐ Rutu

13

Usability Test Results Report David – Feng – Michael ‐ Rutu

14

Usability Test Results Report David – Feng – Michael ‐ Rutu

15

Usability Test Results Report David – Feng – Michael ‐ Rutu

16

Usability Test Results Report David – Feng – Michael ‐ Rutu

Conclusion The results of the usability test showed both effectiveness of our design and also a few problems which were easy to fix. Based on the results of our observers, overall satisfaction of the design was relatively high.

However the few problems that we did find needed to be fixed as a part of improving our design. Hence our revised design is an improved version of the paper prototype with which we had started before the user testing.

Experience When we designed this paper prototype, we tried very hard to think of every aspect that a user could possibly want to use the design in. We came up with at least two possibilities for just adding a new contact and were happy that our design was “complete”. The user testing definitely gave us more insight into our design by showing us even more ways that a user would use our design in.

The most convenient part about using the paper prototype was that we were able to change our design after every user’s comments. So if the user 1 faced a problem with something, we immediately corrected it so that the next user does not have to point out the same design error.

Our biggest learning experience was that no matter how many design possibilities we came up with and how "perfect" we thought our design was, a user will always change if not all at least a part of that perspective.

17