Monthly Archives: February 2013


We are designing a smartphone app meant to be used as a reference to find information, approximate arrival/departure times, distances between stops, and other related information about Boston’s MBTA, specifically the subway. The idea is to keep the app as simple as possible, allowing users to glance at information already familiar to them during their commute/trip to find what they need quickly and efficiently. The system can give some granular information if observed closely, but it can also only be used as a simple, quick reference.

We are conducting a study to discover how people interact with the system. Your personal information (i.e. your name) will not be recorded or published; this study is meant only to discover how our potential demographic will be able to use the system.

The system should be straight-forward to navigate through, especially if you have any working knowledge of the MBTA. The purpose of this study is for us to confirm or deny how user-friendly the interface is. Instead of using an actual smartphone, we have created paper versions of what we want our interface to look like. I will act as your “smartphone,” moving the pages around to simulate what the system would do when actually implemented. Other members of the team will act as observers, taking notes on how you interact with the system.

This is not meant to be a test of your abilities. This is a test of our system. Since you are imitating what a user would do in real life, our team will keep explanations as minimal as possible. If you find any problems or cannot proceed, that is a problem with the system that needs to be fixed. Upon completion, please tell us what makes sense, what’s confusing, any questions you may think of, and what did or did not work as you expected.

Scenario Tasks:

(1) Use the search to find Roxbury Crossing Station information.

(2) Find information for the Orange Line and then navigate to a map of the Blue Line.

(3) Find bus connections for Roxbury Crossing.


Seeing as Boston is known for being a “college-town” (that is, it is a city with lots and lots of colleges and universities that people come from anywhere and everywhere to attend), it is filled with lots of young adults and even teenagers.  We figure a major demographic and who we really have in mind when designing the system is college students and other young adults.

Keeping this in mind, we tested a handful of college students (with no prior knowledge of the system other than the briefing above) on how well they could complete the above tasks.  These students ranged from ages 19-22 of varying racial/ethnic backgrounds.  The users were tested on a college campus and in apartments.  The users were given all the time they needed to complete the tasks, which ended up being pretty quick.  Beyond the paper prototypes, no other equipment was necessary to complete the tasks.

Observations & Results from Interviews:

Task One:  We had included a search box in the top right corner of the interface, which was what we had intended the users to use the type in a station name to jump right to that station’s page.  However, we had a user who completely missed the search box and physically and literally “searched” for the station with our more obvious drop-down menus.  While it technically worked to get to the result we wanted, it completely missed how we wanted to get there.  After talking to the user, he mentioned not seeing the search box at all.  Between noticing that we made the drop-down menus much larger and the user’s comments, it would probably be best for us to modify the search box somehow.  Perhaps we should move it to top left corner, following the “Z” a person’s eyes follow when looking at something.  Maybe it needs to simply be bigger.  Or a different color to stand out.  Or some combination of the three.

Task Two: Again, the users completed the task we wanted, but not how we wanted them to get there.  Next to each station on the map is a colored-square showing other connections available to it (e.g. State Street has a touchable blue square next to it that, when touched, will take the user from an Orange Line map to a Blue Line map).  However, without fail, the users would go to an Orange Line map, navigate away from the map to the home page, and then navigate to a Blue Line map.  According to the users, it is not apparent that those colored squares were touchable buttons.  Those obviously need to be made apparent that they are actually buttons and not just for giving information.

Task Three: Yet again, the users missed what we wanted them to do.  We wanted the users to touch the little circle next to a station to display a speech bubble displaying bus connections.  But our station pages also display bus connections.  The users simply navigated to the station pages completely unaware that the button on the Line map even had that capability.  Just as the problem with the second task, the apparentness of the buttons has to actually be made instead of just assumed by us as designers to be buttons.


Team Roles:

Since the overarching design of the application had already been worked out and agreed upon, creating paper prototypes needed little more than designers and testers, of which both roles were filled simultaneously by both team members.  Matt and Mark each designed different parts of the system (certain pages or functions of the pages) and tested different users or observed the users instead of “playing computer.”


Design Alternatives/Descriptions:

main design sketch proto 1main page design sketchmain design sketch proto 2

These were possible designs for our main screen.  Initially, the thought was to either pick a line or station from drop-downs.  But then we realized this would be a bit too cumbersome when scrolling through all the possible stations.  After realizing this, we added filters to the stations and lines as to save the users time when finding a station they want.  Then, we realized the users might want to change general settings (e.g., brightness) as in most other systems or simply search right away for what they specifically have in mind, adding the settings and a search menu.

In the final design, this first main screen that users will encounter upon opening the app.  It will allow the users to search the app for either a specific line (i.e., Blue, Green, Orange, Red, or Silver) or a specific station.  Selecting a line from the first drop-down (Green Line in this case) will filter possible station selections to only stations that are on that specific line.  Shown next to each station’s name on the drop-down is colored squares (shown with letters for their respective line names) representing which lines they are on.

red line design sketch

Shown here is a map view of the Red Line.  It displays each station on the actual line (not to scale, just a rough estimate) with brief information about each line (i.e. bus or other train connections) and clickable/touchable links to train connections displayed next to applicable stations.

station design sketch

Shown here is the individual information page for the Downtown Crossing station.  It displays a close-up view of the station (relative to the entire overarching line map) allowing it to show any intersecting train lines that are available to that station (in this case, Red, Orange, and Silver).  Beneath the map are links to line pages that are available to that station.  So for this example of Downtown Crossing, the user is able to click either the Red Line, Orange Line, or Silver Line links that will take them to the respective line pages.

station & main deisgn sketches

Here are rough initial sketches meant to serve as jumping off points for both the individual stations maps (on the top half) and main screen (bottom half).  These were used to bring out ideas as to how the app will work and interact with itself.


(1) Searching

main pagesearchingsearch resultsscience park page

(2) Going from line to station

main pageselect linegreen line pagescience park page

(3) Going from station to line

main pageselect pagescience park pagegreen line page

Roles and Tasks:

For this part of the project, Matt acted as architect, bring out overarching ideas as to what the system will do between pages and within pages while Mark acted as the designer/web designer, figuring out the small details of how the system/interface will look and feel.  Matt and Mark both acted as business analysts, deciding what users would need and eliciting respective requirements.





The possible interaction metaphors we decided upon are a picture of a house to represent the link to the Home page, a gear to represent the link to Settings, a magnifiyng glass to represent Search, train track to represent going to Lines, trains will represent each individual train on the line, and colored square to represent the lines on each map.

For this iteration Matt and Mark both worked as business analysts to determine what tasks needed to be achieved and how to best decide how to accomplish them. Both Mark and Matt also served as web designer/engineer to upload images and write out parts of the process online