Posts in Category "User Experience"

Remote User Testing Musings

I went to a BayChi meeting last night with my web UE team. The title
of the talk was “Hello
Morae, Farewell VHS!
” by Emily Hebard and Joanna Sim from Intuit. The
talk was good and I learned a bit about Morae.
But for some reason I had got it into my head that Morae could be used
for remote user testing (with the users being remote as opposed to just
the viewers). It was my bad basically for not doing the research.

What my team and I really want to start doing is remote user testing.
I’ve heard a bit about Ethnio, which
looks quite promising for what we want to do here for Also
there is a lot of customizing that can be done to Breeze to
gear it up for use in remote user testing. So there are things out there
that can help us.

More than anything, what I would want out of a remote user testing is
just to allow users to click through a proposed experience on their own
without anyone “watching”. The session would be recorded and include
mouse click data and other actions/events. In addition the user would
fill out a brief questionnaire related to the experience they just had.
They would be compensated in some manner and they’d be on their way.
Then, all the data would be magicked to a central repository where a
user experience professional could browse at will. Something like this
would really ease the overhead of running testing. Over the next month
or so the Web User Experience team will begin to explore and try out
various methods of creating a persistent, predictable, and actionable
input stream from site users (how’s that for a mouthful of mumbo jumbo…).

If anyone reading this has had experience with remote user testing of web sites, I’d
love to hear about it. “Day 1” Web Site

The "Day 1" web site has arrived! The "Day 1" site is how we've been referring to the modified web site that would go live once Macromedia became "the company formerly know as…".
Which is now! As the chief info architect for the web site I wanted to have
the chance to explain some of the things we did and why.


Design goals for Day 1 Web Site

(1) Ease transition pains for users
We knew we had to make some changes
to to communicate to folks that we are now Adobe. But we were
concerned that making any drastic changes to the web site would hurt our regular
visitors and customers (or at least inconvenience them, which is the same thing).
Ever since one fateful redesign many years ago, we've been chanting "evolution,
not revolution" every
time a redesign comes due. So our number one design goal for the Day 1
web site was "do no harm". We wanted to allow developers and others who use
the site on a regular basis to easily get to information and resources they
use regularly (dev center, support, forums, downloads, Labs, etc).

(2) Answer the important question: what about me?
We also anticipated
that folks would have concerns and questions about their products ("are you
still going to support <ProductName>?") and their relationship with
us. So we wanted to provide easy site-wide access to acquisition information
that would help answer these questions.

(3) Allow easy cross-travel
We know that many
of our customers use both Macromedia and Adobe products And
that many are regular users of both sites. For the "Day 1" web site we wanted
to create a convention for crosslinking that would allow easy access to and
from each company's
web site in places where it made sense. Some examples are the home pages for
support, products, downloads, and solutions.

(4) Provide contextual help
convention we used for crosslinking not only gets the user to the parallel
area on the other web site, it also provides contextual help where relevant.
For example on the support home the crosslinking pod contains: "Have questions about how this affects your support? Learn more