The paper prototype tests suggested the need for the following changes
to the interface which we implemented:
We decided to display trip arrival times and durations, and
to visually show traffic densities along alternative routes,
in the main route and traffic view. This decision was based upon strong
user preference for a view that included these features (as seen in
the fourth sketch on the Brianna Bridger
scenario page) over an alternative solution.
The first tested user expressed a strong desire to save multiple
routes, (not just a single primary route), to view traffic
forecasts for these routes later on. We added "save this commute"
links as well as a way to access these saved links (via the profile
page) to the paper prototype and later users seemed to clearly understand
and appreciate this functionality.
We added action buttons (labeled with "Done," "Next,"
etc. as appropriate) to the bottoms of pages where users expressed minor
confusion about what to do after reaching the bottom.
We added a "Welcome, [username]" phrase that
appears at the tops of pages after a user has logged in, based on a
user's request.
We changed the design and functionality of the logged-in-user's
homepage; that is, the first page that a user sees after logging
in or returning to the site with a cookie. The old page included generalized
traffic news. The new page is identical to the route and traffic page
view that appears after a user specifies starting and ending points
for a route.
A profile page helps users to keep track of, and
return to, information they've fed into the system, including saved
commutes, home address, etc. Our first prototype did not include such
a page and our first tested user specifically asked for a page that
would display her saved commutes and her preferences and default choices
about how the system should operate. We introduced such a page into
the next version of the prototype and this element seemed to imrpove
performance and clarify the configurations that users had at their disposal
as well as the current state of those configurations.
The need for clear top level navigation, and in particular,
clarity about how to get back to the home screen from anywhere else
in the site, emerged early on as users demonstrated confusion about
navigating the site after completing a task.
Unaddressed and partially-addressed findings:
The first tested user expressed a desire for a portion of the application
she could use on her PDA on the road. We decided not to address this
in the current version of the product due to time and resource limitations.
Two users expressed much confusion about realtime traffic
displays versus traffic forecasts based on historical data. We
attempted to address this by placing prominent labels on the displays
identifying them as one or the other. This improved matters but still
some confusion remains. Two questions we will explore more fully include:
Would it be preferable
to show the user just one view? Perhaps these two concepts
are foreign to users' mental models of traffic and routes. Perhaps a
single view that consolidates historical data with realtime data to
always show a single forecast (or a single realtime view, based on whether
the user is viewing traffic now or in the future) would be preferable
because this simplifies the mental model that the system reflects. (For
such a gain in simplicity, however, our users would lose some accuracy
in traffic predictions). The first user expressed a desire to be able
to see both realtime and average-historical traffic data, but this preference
was not strongly stated, and this preference emerged only after we verbally
described these two alternative views, so this preference may not comprise
sufficient evidence to support showing two views.
If two views are preferable,
what choice of wording will most clearly and efficiently label the views?