ease-mail interactiveprototype feedback

8/12/2019 Ease-Mail InteractivePrototype Feedback

1/25


2/25

User 1 is a male Boeing engineer who worked with early computers to assess lighting

conditions in planned spaces. He currently uses a desktop computer almost entirely to write

letters in MS Word and use email. He has difficulty seeing, hearing and remaining focused when

presented with distractions. He seemed overconfident in his abilities, and didnt want to admit

when he was lost, and in need of help.

User 2 is a female kindergarten teacher with a love of lifelong learning and communication. An

iPad is her primary device and she uses it mainly for email and games. She had no obvious

physical impairments, and showed strong problem solving skills, and confidence when faced

with unfamiliar situations. She asked for help easily, and even showed us a comic strip making

fun out of stereotypes regarding the elderly, and technology.

User 3 isa male materials engineer who has not used computers until recently. He currently

uses a laptop to check email, write letters in MS Word, and access the internet. He had no vision

in one eye, difficulty hearing, and difficulty with fine motor movements. He readily recognizedwhen he was lost and was willing to ask for help.

Contextual Inquiry Results

High level tasks and common themes

While performing the contextual inquiry themes that users shared included: that they found the

default font size was too small to read, elders who communicated on a computer appeared to

use email, external hardware was to hard to access/use, a mouse was more easier to use then

an trackpad, and typing was a difficult task.

Individually User 1 had trouble with the Windows 8 interface. Although the user liked instantaccess to an application due to his poor eyesight he had trouble distinguishing icons from one

another, and thus would end up clicking almost everything until he obtained his objective. Another

problem was with the users poor memory, he would ask for help performing a task. We would

demonstrate it only to have him forget how the task was performed. User 2 on the other hand

was the most experienced out of the three in using technology, as she was able to navigate

through her iPad, and was able to recognize how to operate an pc. In one case, we were able to

give her a email address, and she was able to send an simple message. She talked about how

her grandchildren taught her how to navigate through different programs, and apps. Despite

experience, when arriving at Facebook, an application she hadnt used before, she refused to try

it, as no one had taught her how it works, and was uncomfortable learning it without a guide.User 3 was able to navigate through a computer, and an iPad although he needed some help

figuring out each step, due to his poor eyesight. In one case he had trouble composing an email,

as he couldnt tell the subject box from the address box. Also, when operating an web browser, it

was shown that user 3 had trouble recognizing an input box while accessing google, and typing

in an url from an keyboard.


3/25

Table 1: Design Implications based on Participants

Problem Observation Implication

Eyesight Most users had impaired eyesight

and took time to scan the screen

Fonts should be large and the

interface should be graphically simple

Unsteady Hands Some users had shaky hands

which made cursor movement

inaccurate

Actionable items should have large

click targets to reduce the required

accuracy

Difficulty Hearing Most users had trouble hearing The solution should not rely on sound

for core functionality

Distractibility Elders tended to get distracted by

various options

Only display content that matters to

the user

Lacking Support Elders tended to get input boxes,and buttons mixed up, and

confused

Hints at the bottom of the screen,help display what the user has done,

and what they can do next

Design Choice

We decided to merge some of our designs in order to get the best of both worlds. Our modified

design was chosen, due to the way it keeps only a few important items on screen allowing an

elder not to be distracted by several choices which User 1, and 3 demonstrated during the

contextual inquiry. Another reason was due to our users poor eyesight, by having only a select

number of items we can make text fonts/icons larger for readability. Also, we feel that comparedto the previous designs our new version is more minimalistic, and easier to traverse with the

arrow buttons.


4/25

Existing and New TasksThese are the tasks we decided to focus on based on our contextual inquiry for general

technology.

Easy Task - Opening a New MessageAlice, and Bob were having a conversation about how the Seahawks won the Superbowl. Bob

mentions that he found an interesting article on the how the Seahawks won the game, and

decides to send it to Alice over email. Alice goes to Ease-Mailon her computer to find, and

access the message sent from Bob. Ease-Mailshould allow Alice to find Bobs new message

without having to search cluelessly, for the emails location in her inbox.

Moderate Task - Sending an Group Email

Alice is an elder who wants to plan Bob her grandsons birthday however, she needs to know

when the rest of her family is available to celebrate. Instead of calling each one independently,

she wants to notify the entire family at once. Using Ease-Mail shes planning to email everyonedespite being inexperienced using email. Ease-Mail should allow Alice to clearly understand what

steps she needs to take in order to send an email out to her whole family regarding Bobs

birthday.

Hard Task - Adding New Contact from Email

Bob met Charlie in a cafe while going out for lunch. The two hit it off, and decided to become

friends. Charlie asked Bob for his email address, so they could communicate with each other.

Bob gave Charlie his address Charlie then proceeded to send Bob an email. From the message

Bob got Charlie address, so she could add him as an contact. Ease-Mail should allow Bob to

add Charlie as a contact from inside the message in a simplified instructed way, that allows Bob

to know what hes doing, without being over cumbersome.


5/25

StoryboardsBelow are the storyboards each storyboard is designed off one of the original sketches following

one of our tasks.

Storyboard for Concept 1(Hard Task - Adding New Contact from Email):


6/25

Storyboard for Concept 2(Moderate Task - Sending an Group Email):


7/25

Storyboard for Concept 3 (Hard Task - Send Email to a new contact):


8/25


9/25

Low Fidelity Prototype

Menu Page

We created our paper prototype using the

vector graphic drawing software in Googledrive. We then printed out each screen on

separate piece of paper. On the side, we had a

memo sticker with the description of the task.

Interactive Content

Info bars located at the bottom of all the screens showed the description of different buttons in

the interface when users hover over them. It also shows the confirmation messages and status

of the interface. We used memo paper, and paper pieces to display contents that are responsiveto user interaction.

Menu Navigation

We numbered all the pages, and marked each button with the page number it points to, so we

can keep track of the pages more easily.


10/25

Evaluation method

Tasks

For our user tests, we gave the participants 3 tasks relevant to the goals of the EaseMail

application. They were variants on the basic tasks we discovered were desired through ourcontextual inquiry, but with extra requirements to test some advanced functionality and its

discoverability. The first task was to send an email to 2 predetermined recipients. Our second

task was more complicated and involved basic inbox management. The user was asked to

check two incoming messages, reply to one of them and delete the other. Finally, the third task

involved basic contact management. The user was asked to remove a predetermined person

from their contacts. This task started wherever the last task left of usually on the inbox screen.

Environment

Due to the nature of our two participant groups, the evaluation was carried out in 2 locations. The

first was the CSE atrium. This location was empty and quiet at the time of the testing. We

gathered tables together to provide staging area for the computer and his paper UI. The secondlocation was the Odegaard Library which was also a quiet, low-distraction environment. We

used one large table to provide the same amenities as before in as similar an arrangement as

possible. In both cases we gave the participant a pen to use as a stylus on the prototype.

Participants

Our participants came from two demographic groups: 2 were peer students at the University of

Washington and the other was a staffer at the Odegaard Library. The peers were friends of a

group member but had not heard anything about this project previously. The odegaard staffer

was approached to volunteer in our study on the day of the evaluation due to difficulty arranging a

meeting at any of the nearby Retirement Homes with a true member of our elderly user group.

Like with the peers, the staffer had no former knowledge of our project.

Procedure

For each evaluation the team set up 3 stacks of paper prototype components, one related to

each of the 3 main tasks as well as an extra stack of misc UI components in case the user

explored any other parts of the UI. The users table was cleared except for the initial UI screen, a

stylus and a sticky note with the first task written down. We brought the user over, reconfirmed

the basics of the consent form they signed earlier (their ability to leave at will, and the fact we

were testing the UI not them, etc). For each task, Nick verbally told them the goal as well as

provided it in writing on a sticky note. Only the goal was given, not any steps to achieve it. Matt

took notes throughout the test while Ben was the computer and provided the UI transitions inresponse to user input.

Measures

During the test, we paid attention to a number of measures, mostly qualitative. The most

important measure we investigated were any signs of frustration or confusion from the user.

This showed itself in the forms of hesitancy picking a UI option or verbal expressions of

confusion. The second most important measure was whether the user was satisfied that each


11/25

task was completed successfully. Satisfaction was apparent if the user knew that they were

done with a task rather than continuing to try accomplishing it. This allowed us to evaluate our

feedback mechanisms. Lastly, we observed the time it took to complete each task. This was

influenced a bit by difficulties with the paper prototype technique (especially with the first subject)

but gave some quantitative indication of the time required to learn and accomplish each task.

Given the repetitive nature of managing email, too much time required for any one task couldmake our UI unfriendly to use.

Evaluation Results

From our defined measures, and observations we were able to obtain qualitative results that

showed weaknesses in our design which upon reflecting allowed us to devise new solutions.

Frustrations/Confusion

Our first observation, was observed during the composition of an message, while watching for

frustration, and confusion. Users tended to be confused about adding, and removing contacts

after having gone from selecting contacts to the main body of the message. To solve the

confusion, we decided to add a delete button shown as an a X next to each contact in order to

allow an user to easily remove an contact upon deciding they no longer wish to message them.

Also, to allow users to easily add contacts after going to the messages body, we added an add

recipient button. The button is located below all contacts with an default profile picture, and the

addition symbol on top to symbolize the functionality of adding.

Satisfaction

The second observation, came after the completion of an task during which the users tended to

be confused whether they had actually finished the task, and achieved their expected results.

Surprised that our users lacked the feeling of satisfaction, and due to the fact that we were

measuring for it we know we had to give them some kind of confirmation that they completedtheir desired task. In order to give users satisfaction, we decided to add an confirmation screen

for every piece of data created, or edited. The confirmation screen is shown at the bottom of the

screen, as an line of text, where help is given to state the changes made.

The final observation, came when an users wished to take back an action, after going past a

point of no return such as sending, or deleting a message. We decided to add a modal popup

that confirms the user wishes to make the action before its performed. The pop up is shown at

the center of the screen, with an confirmation message to the action being performed, and two

buttons one to perform the action, and one to cancel it.

Time

It should be noted, that all though we observed the time it took to complete said tasks. Our

participants moved at a brisk pace which showed that the time it was taking them to complete

tasks wasnt so much of an concern. That being said, since we didnt really get to run our low

fidelity paper prototype by an elderly, the design could still be changed to match their needs

based on latter tests.


12/25

Interface Revision

Here are the changes we mentioned in the above section. These changes are focused on

adding feedback to the users actions.

Remove and add recipient buttons on the Compose Mail Screen

Confirm message & Task Completion Message

Confirm screen at the bottom of the page that states the changes made in the previous screen.


13/25

Interactive Prototype

Overview

Link to our interactive prototype: http://easemail.daemonfstudios.com/

The interactive prototype was implemented in a website using php to show the dynamic contentand css to define the style of the layout. The overall design is almost identical to the low fidelity

prototype. All the screens in the paper prototype were converted to webpages which are linked

with hyperlinks.

Key elements of the implementation

Back buttons and home buttons have a consistent location on every screen

The back buttons on every page functions as the back button on browser.

Buttons representing contacts are always in circular shape while other functional buttons

are in square to make sure they look distinct

Interactive info bar at the bottom shows the system status and guide the user to do

specific tasks
http://www.google.com/url?q=http%3A%2F%2Feasemail.daemonfstudios.com%2F&sa=D&sntz=1&usg=AFQjCNFbuYsVS79RVfHLs4Rxp9vnxmvo5w


14/25

Transition from low fidelity prototype to the interactive prototype

The transition from low fidelity prototype to the interactive prototype is pretty smooth because of

the simplicity of our design. The most distinct feature in the interactive prototype is the feedback

from system to the user. We used color, for the info bar, and message boxes to achieve this.

1. Added the color blue on selected elements to make make some of the buttons more

distinct from others

2. The interactive prototype shows more info on the info bar than the paper prototype, which

was impossible to be shown

3. A pop up error message is shown if user tries to leave the email their editing


15/25

Platform specific constraints

The main constraint of this system is the web based platform. It is harder to control the size of

the interface on a website than a application since different browsers have a different

interpretation to a graphic. Also, it takes time to implement a system to show info about all the

elements in the interface. So the info bar in this interactive prototype only shows the descriptionof some important features.

1. Website layout are shown differently on different web browsers and computers

a. layout changes on larger screen

b. The look and feel of pop up message box is not consistent with the rest of the

design.

2. Details such as error prevention was not added for simplicity

a. Users can send empty messages

b. The status of the application can not be saved. Edited messages are not saved, if

you click the back button in the mail composition page


16/25

Storyboards for Tasks

Task 1 - Open an New Message:

Task 2 - Send an Group Email:


17/25

Task 3 - Add New Contact from Message:


18/25

Feedback

When it came time to gather feedback on our interactive prototype, we decided to have our

stakeholders perform a walkthrough. During which we used three different research instruments

in order to gather critical feedback on what our users thought, and how they interacted with our

prototype. The first was observing for bottom line numeric data such as the number of timesusers showed confusion, or the number of unnecessary button clicks. At the same time we also

gathered process data in regards to data/observations that stuck out to us in the walkthrough as

being odd, or significant. After the walkthrough, we finished by giving an questionnaire where we

gathered subjective feedback in regards to what the user thought of the prototype, and what

changes they felt were needed. Please scroll to the appendix for more information on the script

used for the walkthrough, or the evaluation process.

Evaluator 1 is an older gentleman around the age of forty-two who fit into being a end user, as

he has trouble working with computers despite using one for work. Through the walkthrough

evaluator 1 was able to guide himself through the prototype thanks to the script making goodtime despite showing a couple signs of confusion, and getting lost a few times which seemed

normal for an first time use. Notable feedback gathered came as process data such as not

knowing whither the email had been sent the first time due to the fact that the confirmation

message seemed hidden at the bottom of the screen. The second piece came when the

evaluator read the task to add a contact from an message without reading the instructions he

proceeded to manage contacts only to realize he couldnt add a contact from the menu, thus

leading him to request the functionality to add a contact without receiving an message first.

When asked what he liked, he stated the design was simplistic, and easy to use. When asked

what he didnt like, he stated that he wished the send button was more intuitive to an actual send

button.

Evaluator 2 is an younger man who fit into the category of being an UI expert due to his

technical background. He was able to navigate through the prototype with ease, and was much

faster than evaluator 1, showing little confusion. He only got lost once like evaluator 1 in

mistaking the contacts button for adding an contact. Otherwise, most of the noteworthy feedback

came during the questionnaire. When asked what he liked, evaluator 1 stated that he thought the

prototype followed an minimalist design. When asked what he didnt like, he replied that reading

from left to right with messages was an pain, and that the text was too small in an message box

if it didnt have an picture of the contact in it, as it required focusing in on the small text. Despite

the criticism when asked who he thought would use this kind of email, he admitted that it

seemed like something for elderly, and could look past reading from left to right for them.

From evaluators 1 and 2 feedback, we believe that its important for us to make the text larger

for each email in the inbox that lacks the contacts picture, and to add the functionality for adding

contacts in the manage contacts page which wasnt added prior to now due to time constraints.


19/25

Appendix

Consent Form 1


20/25

Consent Form 2


21/25

Consent Form 3


22/25

Raw Data

User1

Compose Message (completed): Navigated with ease & precision

Check Mail (completed):

Easily Navigated to Inbox

Mistook some text for an button

Delete Contact (competed):

No trouble in fulfilling task

Wasnt sure if contact was deleted after being sent back home

User2

Compose Message (completed):

Understood UI actions, and task for navigating to compose message

Took a bit to realize how to add multiple contacts, and manage them

Wasnt sure if message was actually sent at first


Navigated Inbox with ease

Was confused about the contacts attached to the message

Delete Contact (completed):

Deleted contact without trouble

User3

Compose Message (completed):

Navigated UI at brisk pace, adding contacts easily

Assumed input boxes were clickable


Upon navigating to inbox, had to think about messages for a bit

Also, had to think about the details button for an message, and what it does

Upon being taken back to inbox after deleting message, user wasnt sure if task

was completed

Delete Contact (completed):

Realized how to manage contacts without trouble, shown by pace

Accidently deleted contact, and wished to take it back


23/25

All the elements of the paper prototype

Menu

Compose New Message, Manage Contact and Check Inbox


24/25

Script:

Task 1: Open an New Message from Wanda Fuqua1. Click on Inbox

2. Click on Questions on HW from Wanda Fuqua

Task 2: Send an Group Email to: Jonny, Liz, and Draco1. Click on Send an Message

2. Click on Jonny, Liz, and Draco

3. Click on next button

4. Type in text for Subject

5. Type in text for Body

6. Click Send

Task 3: Add new contact as Bob from [email protected]. Click on the inbox

2. Click on message titled Nice Meeting You from [email protected]

3. Click on add to contacts

4. Enter in Bob under First Name

5. Click Save


25/25

Evaluation Technique:

Bottom Line Data: Number of times user makes a gesture, or comment to show confusion

Number of times user clicks buttons out of proceeding order

User realizes home button takes user back to Main Menu

How long did it take for the first, second, and third task

Questionnaire:1. What did you like about it?

2. What didnt you like about it?

3. What did you think of the box buttons?

4. Would you use it again?

UI Expert1. Who do imagine would use this kind of email?

Process Data (Interesting Data Gathered on Sight):

ease-mail interactiveprototype feedback

Documents