Scenarios
Revisited
When we
first created the task scenarios, they were ordered by "designer"
logic:
1.
Registration
2.
Immediate event planning/email options
3. View MySFnight gather general information about
possible future events, without explicit action such as emailing
options
4. Write an after event review.
For the
low-fi prototype testing, we changed the order of user tasks
to reflect the level of customization and therefore number of
users who may use a particular feature. It is expected that
as customization level increase, the number of users will decrease.
This order also reflects more realistically the way most users
develop trusted relationships by taking incremental steps. The
new task order is:
1.
Immediate event planning/email options
2.
Registration
3. View MySFnight gather general information about
possible future events, without explicit action such as emailing
options
Task
4 for writing a review was cut to keep the low-fi testing
within reasonable amount of time.
Low-fi
prototype testing showed us that task
#3, based on Stefan's scenario, was not well worded. Participants
were not sure what they needed to accomplish. The problematic
initial design for MySFnight only confused each participant
further. We decided that the scenario definition that task 3
is based on is still valid. All other tasks
scenarios still work well for this stage of the design process.
Changes
Resulting from Low-fi Prototype Testing
The low-fi
prototype testing generated several types of information for
the design team: participants' written and verbal feedback,
team members' observations, and ensuing discussions. For the
first interactive prototype, we focused most of our efforts
on two major areas that are considered to add the most value
to the user customization experience: event planning using a
list that can be emailed and customizing MySFnight. They were
also the most problematic areas for participants in the low-fi
prototype testing.
Much of
the user input for these two areas can be categorized easily
into known types of cognitive problems with corresponding design
solutions. Some of the solutions, however, conflict with different
usability theories. In situations where no perfect solution
can be found, the team examines the issues in light of usability
theories and practices and tries to come up with the best solution
that best meet the current needs of SFnight at this stage of
the process. The validity of some of our revisions is subject
to further usability tests, including the heuristic discovery
in the immediate next stage.
Task
1: Planning an Event As before, we want to allow
a user to create a list of options and email the choices to
friends. This feature is available to all visitors of SFnight,
whether or not they have a customized account with SFnight.
This should encourage users to start developing a positive
and meaningful relationship with SFnight. This feature needed
easier access that is also ubiquitously available in the entire
web site. The interaction model need to be intuitive, with
lots of good feedback and use of clear labeling/buttons/icons.
Task
3: Create & Customize MySFnight This task involves
a high level of user interaction. Even though we were especially
concerned with the registration process in the initial design,
low-fi prototype participants did not have significant problem
with the interaction flow. The customized area in the home
page was considered good feedback once a user completes the
registration process. The MySFnight page, however, was extremely
problematic. Users did not understand what could be done in
this page and the uniqueness of some of information presented.
Participants did like the potential of
1.
Having special editorial recommendations based on their
own interests,
2. Having an area displaying
a. events happening at venues that they have chosen and
b. specific events they have chosen,
3.
having the information presented in a calendar format
The design
team also has been struggling with how to successfully combine
the ability to add an event/venue to MySFnight and the ability
to add to the list for emailing from other parts of the SFnight
without confusing users.
It's
worth to note that after working on this issue for so long
we may be losing the perspective of a normal user. This highlights
the need of bringing in outsiders to evaluate our current
progress and solutions.
Some
Design Solutions
1.
Distinguishing Different Lists. In Lo-fi prototype
design, users could not distinguish the function Add to MyEmail
List from the function Add to MySFnight list. The
revised design uses a combined click-able image of distinctive
icon and explicit text to make the difference more clear. When
user clicks either image box, s/he will get immediate feedback
relevant to each list.
a.
When a user clicks Add to MyEmail List, a new page
displays the current items in the list. In the page, a user
can remove items, go back to select more options, update the
list, save the list for future reference, and/or email the
list immediately after filling out the necessary email addresses.
It is
possible that each time a user adds a choice, it can be annoying
to see the display list every time and have to go back to
make more selections when the user is not ready to email the
list. The annoyance could be so much that some users complete
give up using the tool. A
partial solution that addresses this concern by adding a checkbox
to each item in the search result pages and in the MySFnight
page. User can make multiple choices and add them to MyEmail
list altogether. User only gets one feedback instead of many.
Another
solution that we explored in this prototype is to mimic more
closely the shopping cart/basket model with a combination
of feedback mechanisms such as:
- make
it possible for each item to be added individually with
something like an icon/button,
- gray
out the icon/button once the item has been added
- use
something to indicate the number of items in the list
- make
the ability to view the list part of global navigation
Since
there is limited amount of time to create the first interactive
prototype, one team member started to implement the first
solution using a new window to display the selections, allowing
multiple selections in the search results and MySFnight page
before the user clicks on the image-button and get a new window
as feedback. Even though we continued to explore different
design solutions, time limitations did not allow us to implement
another design. We stayed with the first solution for this
prototype to have evaluators help us better judge the design.
b.
Add to MySFnight MySFnight also needs better user feedback
to orient the user at every stage (see 1).
The same feedback considerations and solutions for the email
list also apply. Another design change that is not used with
the email list involves the change of color and text as feedback.
A user may come back to the same event page and may forget
s/he has already added it to MySFnight. A change of color
and label from Add to MySFnight to Added to MySFnight
makes it clear that user has already done it before.
2.
Labeling to Distinguish Editors Choices Section and Users' Own
Choices Section in MySFnight Page. We decided to
use wording and geometry treatment together to highlight the
distinction and hope user can better appreciate the difference
between the two. Editors choices section would be: Editor's
Picks. A user's own choices section would be: Your Picks. The
effect is yet to be tested.
3.
Improved Approach to Attract User to Sign up with MySFnight
when the User Emails a List of Options. We greet
the user with the following: "You don't need to sign up with
MySFnight to use this list, but your future visits will be enhanced
if you do so: you will be able to save this list for up to two
weeks. Sign up MySFnight now!" This is more than a mere
cosmetic change, in that it is friendlier, more positive and
less assertive.
4.
Making the Calendar More Explicit and Prominent, or Not. In
all the scenarios we explored, our users seem more concerned
with calendar concpet or timeslot of an event than anything
else, regardless of whether they are planning or just browsing.
We had a calendar presented in a subtle manner in the MySFnight
page for the low-fi prototype, and users like the idea of having
the information presented in a calendar format. In response
to user feedback, we started to implement a design that makes
more explicit use of the calendar concept, including creating
a new MyCalendar icon and making the layout more look like a
conventional calendar. All of the Editor's Picks and user's
Your Picks would be incorporated into one calendar.
After several
design iterations, however, we decided that there would be too
many problems associated with the traditional calendar format
and the benefits are not enough to outweigh the problems. Some
of the issues are:
1.
There will not be enough space to include the different
actions users can perform for each event/venue.
2.
Users would need to differentiate their own picks from the
editors'. This would imply more design elements and "noise"
in the information.
3. In implementation, the user's Your Picks can be
easily deleted, but the Editors's Picks are search results
crossing users preferences with what is available. To delete
the latter would require making a hidden list, which changes
everyday. This adds to backend software complexity significantly.
4. There are also issues of how to effectively highlight
the current day, the different months without introducing
more design elements.
After several
tries, we decide to follow Kevin preliminary suggestion: At
MySFnight page, we keep the Editors Picks and Your Picks separate.
Each event/venue would be organized into Monday through Sunday
columns, with the actual date listed as part of the description.
Other functionality include:
1.
From Editor's Picks, users would be able to use a checkbox/icon/button
(see discussion about Differentiating Different
Lists) displayed in each event [arrow_down] to copy into
to Your Picks area. Essentially, editors may suggest a number
of options that the user won't be interested in, the user
can just select the options of interest and keep it in their
personal pick area.
2.
Once a user has reviewed all the Editor's Picks and selected
only options of interest into Your Picks, user can minimize
the Editor's Picks section. All other sections in the MySFnight
page can be minimized as well, but will not be implemented
for the prototype.
3. The users can add events/venues to the email list
via check box/icon/button that is available for each event/venue.
4. The Your Picks area can also include selections
made from other parts of the website, including individual
event/venue profile and search results. From Your Picks, users
can remove anything they have added.
5. Instead of a searching tool in this area, we added
buttons below each week day [the name could be "more >"…].
This "button" will bring the user to search results based
on the day of the week, where they can further narrow by event
type, music type, day etc. From the search results the user
would go back to MySFnight page via global navigation button
at the top of each page.
