Archive for November, 2008|Monthly archive page

The Importance of Documentation

The title of this post comes off a lot like “The Importance of Eating Your Vegetables”, but I think when you work for a non-profit this really is important.

During the process of researching our users, listening to our stakeholders, developing scenarios and personas, drawing wireframes, and all the other good stuff that goes into developing our website we’ve made a ton of decisions. We’ve weighed different alternatives, had great insights, and ditched some ideas we used to think were great insights. The ramifications of those decisions are obvious to us, but what about the people who follow us?

If we’re replaced, we want new people to at least understand where we were coming from even if they decide to go in a totally different direction. Thus, it’s important that we properly document all of our UX activities. I’m not talking about writing a thick binder that will sit on a shelf somewhere and never get read.
Our web team uses an Assembla wiki to track our activities, describe our research results, and explain the rationale behind our UX decisions. Anyone who comes along later and wonders what questions we asked during our user interviews, or why we made certain changes to our site navigation will be able to get those answers.
That helps the organization by reducing the impetus for new web staff to re-invent the wheel because they don’t understand the history of our site development. The less re-inventing our organization does (without a good reason) the more efficient it is at accomplishing its goals in the real world.
Advertisements

Scenario Creation

So now I’ve done some interviews with current users, I’ve got my survey and card sort results, I’ve crafted personas of the major user constituencies, and I’ve shown some wireframes to potential users to make sure the navigation fits their mental model.

What next? Taking a page from Alan Cooper’s “Goal-Directed Design” method I’ve created some high level scenarios that convey how the new site could ideally interact with our users and help them accomplish their goals. Mr. Cooper calls these scenarios “context scenarios” and one of mine looks like this:

  1. Don gets an assignment to perform a training session for parents on identifying gang-related behavior at a nearby school.
  2. Don visits NCPC.org and looks up information about gangs. Since he has been to NCPC.org before, the site remembers that he’s a law enforcement officer and displays content appropriate for him.
  3. In the Gangs section, Don sees emerging trends about gangs, training materials about gangs, NCPC products relevant to gang prevention, and NCPC programs that help prevent gang-related crime.
  4. Don skims the emerging trends and then looks through the training materials. He finds a training session geared toward parents and downloads the PowerPoint slides.
  5. After conducting his training, Don shares his experience and comments on the material at NCPC.org

This scenario is purely textual, it mentions nothing about specific interaction details on the site. It’s used to describe what an ideal interaction might feel like to our user.

Then, I took my context scenarios and matched them up with the relevent wireframes to create task scenarios. Task scenarios are much more detailed flows of how the user would typically progress through the interface to accomplish their tasks (we think). Once the steps and screens are put together, I’ll take my basic prototype and see if a user can accomplish the steps in the scenario, and if they do it in the way I expect them to.

The feedback I get from those tasks will lead to design changes I’ll put into the next, more advanced set of prototypes.