UXD - User eXperience Design

A Short List for Contextual Inquiry

In its unscientific form, contextual inquiry is simply observing people do what they do. As professionals, however, we can be more effective by applying some science to the approach.

In a nutshell, the following items are recommended for a good contextual inquiry.

1. Understand your audience - do some research on what they do, what their tasks and goals are, and the unique characteristics of the environment in which you will observe them.

2. Make a list of what you want to observe - time with users is usually a precious commodity, so make a wish list of what you would like to get out of the session.

3. Plan a technique for getting rapport - Beyer and Holtzblatt (see reference below) identify several approaches such as the Master/Apprentice. In this approach, you are the apprentice observing the master at work.

4. Define all of your measuring and recording techniques in advance - you may wish to use audio, photography, video, etc., but even for simple note taking you may wish to prepare note sheets in advance to make the best records possible. For example, a "swim lanes" note sheet can be used to record the interactions between what the user is doing vs. what the system or tool is doing.

For more in depth information, you can look to two very good books. The first is Beyer and Holtzblatt's Contextual Design: Defining Customer-Centered Systems. The second is Mike Kuniavsky's Observing the User Experience.

Breaking the First Commandment

The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this.  UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)

If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically: 

Know thy users, and thy users are not thyself

It's a good guideline, of course:  as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.

But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.

And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive:  after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.

To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.

Not-So-Great Expectations

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here's an extract:

So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That's it! That's the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise,  self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.

Learning Complex Domains for User Experience Design (UXD) Projects

Legend has it the famous advertising slogan “Two scoops of raisins in Kellogg’s Raisin Bran” was created by an energetic copywriter who literally dumped out the box of cereal on a table and scrutinized the content for inspiration. Moral of the story:  As designers we have to know our product. But what do you do when your product involves biological science, electrical engineering or any other complex domain? Here’s a few suggestions for getting up to speed in a complex subject areas.

Speak the Language
First, you have to speak the language. Ask your subject expert to outline the top ten or fifteen words or expressions used on a daily basis by your users. Then have him or her define those words in terms that you can understand.  Keep the number of words to ten or fifteen, and only the most important terms.

Key Scenarios
Next, identify the top five or so key scenarios your users do in a typical day. Each scenario should have a simple title and a set of steps. Remember, the goal initially isn’t to do user research, but just to get a feel for what people are doing. Try to cover the five scenarios in an hour or less. This will help your expert from getting too bogged down in details you won’t be able to digest yet.

Map the Scenarios
Once you have the key scenarios, arrange them in a hierarchy. Of course, it’s possible the scenarios are isolated tasks and don’t fit a hierarchy, which is fine. But usually a hierarchy of some kind applies. This hierarchy will become a context for understanding when your user does various things.

Construct a Day in the Life Narrative
To test your understanding of the domain, take the information you have gathered and construct a day in the life narrative of your user. In doing so, you will create a vehicle for refining your domain knowledge and a start to your more serious user research.   

Two Hours or Less
No matter how complex the domain, make it your objective to get through the above tasks in 2 hours or less. By time limiting the exercise, you can keep your subject matter expert from straying into the details before you have the basics solidified.