You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 34 Current »

Testing Information

Briefing

The briefing we presented to users consisted of a description of the problem our application is intended to solve, along with the characteristics of the users it is intended to be used by. Essentially, it was a brief description of the information determined in GR1, when we ourselves gathered information about the problem. In our briefing, we then attempted to emphasize the following points:

  1. The application is to be used to facilitate moving people in and out of dorms.
    1. People can either move in or out; both are done frequently.
    2. People move from and to a wide variety of places.
    3. Dorms typically have a set list of subtasks to be completed when a student is moving in or out.
    4. When moving, people have individual requirements which need to be taken care of.
  2. The application is to be used by dorm management staff.
    1. Dorm managers are very busy.
    2. Dorm managers are comfortable with the typical affordances of web interfaces and applications.
    3. Dorm managers like visual tools.
    4. Dorm managers are required to document move-ins and move-outs extensively
    5. Multiple people often simultaneously work together on moving students, dividing labor.

In essence, the spoken briefing we gave when having users test our prototype was then very similar to the following example:

"Our application, DormMate, is intended to facilitate the moving of people in and out of dorms and similar residential areas for students by the managing staff of these buildings. People move often, and to and from a large variety of places, making dorm management staff, who despite being very capable of using modern organizational tools, very busy, and giving them an enormous amount of information to keep track of. This information is difficult to manage since current tools are all text-based, and simultaneously needs to be reflected on separate paper forms when documented - it particularly affects communication between different staff members when dividing labor for moving students. The information is even more confounded because despite having protocols for moving students, students often have individual needs when moving which cannot be addressed by a rigid protocol." 

Scenario Tasks 

Based on the Task Analysis we did in GR1, we came up with four main tasks for potential users to accomplish during testing of our prototype. These four tasks were chosen since it was felt that they were representative of the tasks that management staff would need to accomplish, with other possible tasks only being minutely different, and following very similar steps to be accomplished. In addition, the four tasks had subtasks which covered many of the smaller tasks dorm management staff may need to accomplish in respect to the encompassing tasks of moving students in and out of a dorm. The tasks are as follows:

Task 1: Document and Indicate Subtask Completion 

  1. Background  : Jack Sparrow is in the process of moving out of the dorm; he has just returned his key.
  2. Task Detail : Mark that Jack Sparrow has returned his key in the system to document and inform other management staff.

Task 2: Determine Room Information

  1. Background : The house manager needs to know some statistics about the rooms on each floor for the incoming school year. They are currently using DormMate for their dorm.
  2. Task Detail : Determine the number of vacant rooms on the 2nd floor of the current dorm (tell the facilitator).

Task 3: Start Moving a Student In

  1. Background : John Hex has requested to move into Next House on March 30. He wants to live somewhere on the 2nd floor. He has no special move-in requirements.
  2. Task Detail : Begin the process for moving John into Next House using the application.

Task 4: Start a Room Swap

  1. Background : Lydia Slovaki wants to move into the same room that Ben Frog is moving out of. She would like to move on April 10th, and wants to be called when her move date is confirmed.
  2. Task Detail : Begin the process for moving Lydia in and Ben out in the system.  

Prototype Design & Analysis

Prototype 1

Prototype Photos

Prototype Image

Description



This is an image of our main page - after a standard login page, this 
is the page the user is directed to. The page is divided into two main areas,
the "News Feed" and the "Task Management" areas. In the news feed,
we have small strips (the width is visible in the picture) which display text    
regarding subtask updates (completed, marked incomplete, by whom).
These strips are thus tied to a particular task, and when clicked, scroll the
task management area content and simulate a selection of the referred to
task. In the prototype, this feature was simulated with different
subtask update strips and task strips being moved and rearranged
by the "computer" (you  can see strip examples on the right-hand midsection
of the image.

Buttons on the main page include the two large ones in the upper left corner -
those for returning to the main page ("Main Page") and for navigating to the
floor plan view ("Floor Plan"). There is also a search bar in the "Task Management"
area for looking up tasks specifically (current search parameter just name 
of relevant resident), and next to it, a button for "starting a new move task",
which takes the user to the form for starting the documentation for a new move.


This image is of our "Start Move Task" page, which is used for documenting a new
move in the system (and thus allowing the organizational utilities of the system to be
used). On the left is a form which has fixed information fields for moving to be filled in;
these fields change depending on which of the radio buttons: "Move In", "Move Out",
or "Room Swap" are selected - with the first two being self-explanatory, and the 
last radio button meant to be selected when one person wants to move into the same
room that another wishes to move out of. Fixed information fields include things like
"Name" , and "Move Date". At the bottom of the form is a section for adding subtasks,
by filling a new subtask in, and clicking the plus button to the left. 

On the right is a "Useful Information" section, which houses a tiered dropdown menu 
with three tiers - "floor plan", "my calendar", and "MIT Directory Search". When clicking
on one of these sections, the corresponding tool drops down; for floor plan, a scaled version
of the floor plan we have on our "Floor Plan" page; after clicking "My Calendar", a calendar
image color coded with move-in and move-out dates is dropped down, and after clicking
"MIT Directory Search", a people directory lookup, like that of MIT, drops out (same
functionality). These drop downs are mutually exclusive. When information is selected
or entered into these areas, they auto-fill the form on the left.

Filling in information in the form prototype was simulated by the user writing the information
in themselves, and clicking of any buttons was simulated with a finger press. To simulate
the drop down menu, we had a tri-fold with a different drop-down on each fold, and to simulate
autofilling of information, we just had the "computer" fill in information when it was selected
or entered in the "relevant information" section.
 


Here is another image of the new moving task form. The information is the same as
that of  the previous image, but this time, the "My Calendar" relevant info section is
dropped-down, rather than the people directory.


This is a picture of  the final page of our prototype - the floor plan. In the design, we
allow for functionality such as clicking on the color-coded rooms for detailed statistics,
and the option to start a move task with the information on the given room filled in. The "Stats"
button would pop up a set of statistics on the current floor (selected by clicking
the numbered tabs on the left), such as number of vacancies on the floor. The symbol next
to the stats button is static, and just indicates that the floor plan is pannable. We keep the
"Main Page" and "Floor Plan" buttons at the top, which have the same functionality described
previously.

In our prototype, we implemented the color-coding by markering in the rooms with colors; since
in our tasks these colors didn't change, we didn't have to handle the case of erasing marker
from our paper. To implement the effect of the stats button, we had a separate slip of paper 
with stats for floor 2 (which was the involved floor in all user tested tasks) which we
moved onto the paper, and the effect of clicking on a room was handled similarly. Lastly, we
implemented the functionality of the top mode-selection buttons by replacing the page -again.

Observations

During our prototype testing, we observed users in detail and found multiple instances where usability as reflected by the testing participant did not match expectations exactly; these observations were recorded as critical incidents, and used to determine required changes for the next iteration of our interface's design. The full list of observations is just below.

The observations are organized by user, then task.

 

User 1

Task 1

  1. Does not use News Feed to find task (does not seem to realize it is clickable); however, task is already on screen. 

Task 2

  1. Scans floor plan manually instead of noticing information box with desired information.  

Task 3

  1. Pauses for around 10s before realizing that return to main screen will allow initialization of a moving task.
  2. Spends 5 - 10s searching for "new move task" button.
  3. Used embedded floor plan to fill user information, rather than people directory as expected.   

Task 4

  1. Did not use room swap option; instead did separate move-in and move-out.
  2. Again, filled out information using the embedded floor plan instead of the people directory.  

User 2  

Task 1

  1. Does not use News Feed to find task (does not seem to realize it is clickable); however, task is already on screen.

Task 2

  1. Pauses for ten seconds before deciding to use floor plan.
  2. Sees summary statistics (as desired), but opts to verify by scanning the floor plan manually. 
  3. Doesn't realize floor plan is pannable. 

Task 3

  1. Took 5-10 seconds to decide to go back to main page to start move-in task.
  2. Uses floor plan to populate move information, rather than people look-up / calendar as expected.
  3. (Typo) Couldn't find "move-in date" because it was written as "move-out date".

Task 4 

  1. Stalls while trying to use embedded floor plan to fill out relevant move-in information.
  2. Gives up on using embedded floor plan and finds people directory for use.

 

User 3

Task 1

  1. Does not use News Feed to find task (does not seem to realize it is clickable); however, task is already on screen.
  2. Updates both desired information as well as extra information (incomplete subtask...).

Task 2

  1. Finds floor statistics and uses them. Does not use floor plan for verification at all.

Task 3

  1. Uses the calendar to help fill in date information. 
  2. Thinks a random box made by the layout is clickable when it isn't.
  3. Forgets to put name in once, and is then corrected.

Task 4 

  1. Doesn't use room swap option; instead opts to do separate move-in and move-out.
  2. Uses embedded floor plan to fill information instead of people directory.
  3. Doesn't fill out current residence of individual moving in (optional field) 

Prototype Iteration

In response to the usability issues we saw in the testing of the first iteration of our design, we made multiple changes to our prototype. These changes are detailed below. 

These changes are from the first iteration. The second iteration has not been revised yet.

 

Change 1

  1. Change : Much of the first prototype's text was written in cursive. This was all changed to print.
  2. Reason : Users are more familiar with print on computer screens. In the prototype testing, they often took a while to find buttons, we think possibly because their text was in cursive. 

Change 2

  1. Change : Added search bar in floor plan mode for quick navigation.
  2. Reason : Users had some difficulty with panning around large floor maps, and accessing tasks from there, as evidenced by the large time spent panning and delay in starting a new task from the floor plan.  

Change 3

  1. Change : Replaced the floor stats box with a dialog-spawning "Floor Stats" button, with large font.
  2. Reason : People did not seem to notice the floor stats box on the floor plan during testing, possibly because the text was small and they deemed it as containing minute details.

Change 4

  1. Change : Changed text of new move task button on home page from "Start New Move" to "Start New Task".
  2. Reason : People were a little confused as to whether "Start New Move" was the right button for all kinds of moves; many suggestions for the change.

Change 5

  1. Change : Relevant information drop downs are initially collapsed, rather than have the floor plan showing.
  2. Reason : Users did not notice the rest of the items in the menu such as the people lookup directory or the calendar, which should be more optimal for certain tasks.

Change 6

  1. Change : "Floor plan" drop down in relevant information part of form was replaced by a listing of vacant and occupied rooms.
  2. Reason : Floor plan drop down took users a while to pan around, while the information they were looking for was just occupancy of rooms.

Change 7

  1. Change : Removed "room swap" option. 
  2. Reason : Users cited this as a confusing point and typically used move-ins and move-outs together to produce the same functionality.

Change 8

  1. Change : Fixed the "move-out" typo on the move-in form.
  2. Reason : Obvious source of confusion. 

Prototype 2

Prototype Photos 

Prototype Image

Description

This is the picture of the main page from our second prototype. The page is nearly unchanged
from the first prototype - the only differences are that we changed all instances of cursive
to print (except for the large title), made the search bar more obvious by writing in lightly
"search".

This page too (the new move task form) is almost entirely unchanged; the difference
is that now, rather than having a floor plan popout in the "useful information" section,
there is a "show available rooms" dropdown since this seemed to be the only functionality
that the pop-out floor plan was being used for in the user tests; displaying the available
rooms as a list in this drop-down seemed to be more efficient and user friendly. 

We also decided to make sure that upon opening this page, none of the "useful information"
dropdowns was selected, since then people would see all of their options for using 
the "useful information" section. Lastly, we removed the "room swap" option since
the functionality was accounted for with both the "move in" and "move out" options,
and people naturally gravitated towards using both of those rather than the "room swap"
option.

Functionality was implemented in the prototype in the same ways that it was before, except
for the "show available rooms" dropdown which was displayed as a paper list.

This picture shows the "Show Available Rooms" dropdown enabled, with it looking and
functioning as described in the previous image's description.

This image shows the part of the paper prototype dedicated to our floor plan page, and
is extremely similar to what it was in the first prototype. The first major change here
is that all cursive is now in print, which we felt to be more user-friendly. Secondly,
we added a search bar for looking up tasks from this view as well, since this would 
reduce the amount of time needed for users to switch back to the main page and
start a new task or mark a task's subtasks (common functionality).

The functionality of the search bar was implemented in the prototype as it was in
the "Task Management" section of the main page, as described in that section. 

This shows the pop up resulting from clicking on the "Floor Stats" button; we embellished it
a bit more from the first prototype since people didn't seem to be taking it very seriously.
The pop up was implemented with just an extra slip of colored paper.

Observations 

Again, we observed users in detail and found multiple instances where usability as reflected by the testing participant did not match expectations exactly; these observations were recorded as critical incidents, and used to determine required changes for the next iteration of our interface's design. The full list of observations is just below.

The observations are organized by user, then task.

 

 User 1

Task 1

  1. Does not use News Feed to find task (does not seem to realize it is clickable); however, task is already on screen. 

Task 2

  1. Stalls for a few moments before noticing the floor stats button, but then uses it.
  2. Tries to check by scanning floor plan, but there is an inconsistency, and this confuses him.

Task 3

  1. Pauses for around 10s before realizing that return to main screen will allow initialization of a moving task. 
  2. Tries clicking pop-up calendar for auto-filling date (not "useful information calendar"), but it's just a reference tool, and is not clickable.  

Task 4

  1. The user has trouble and stalls before deciding to use the people directory for looking up the old address of the student moving in.


User 2 

Task 1

  1. The user is confused when he doesn't see the referred to task on screen (facilitators forgot to put it there...), but figures it out afterwards.  

Task 2

  1. The user does not notice the "Floor Stats" button, and instead tries counting vacant rooms by scanning the floor plan.

Task 3

  1. Immediately starts a new task using the floor plan, contrary to previous users.

Task 4 

  1. Could not find the "Start New Task" button on the main page.
  2. Confused by the "Start New Task" functionality on the floor plan; thinks that it will start both a "move in" and "move out" task.  

User 3

Task 1

  1. Does not use News Feed to find task (does not seem to realize it is clickable); however, task is already on screen. 

Task 2

  1. Manually scans floor plan for number of vacant rooms rather than looking at "floor stats".
  2. Tried to click the static color key (maybe was looking for information?). 

Task 3 

  1. Used the main page "Start New Task" button rather than floor plan.
  2. Used the "Useful Information" "Show Available Rooms" dropdown for looking up rooms - but did not use it to autofill.

Task 4 

  1. Used autofill capabilities of "Show Available Rooms" dropdown this  time.
  2. Used the MIT people directory to look up information about Lydia. 
  3. Took a significant amount of time to figure out how to "add a new subtask".

Prototype Iteration 

Since the testing for this prototype was very recent, decisions on the changes which should be made to the interface have not been decided upon yet.

  • No labels