Channels ▼
RSS

All Those Opposed



"It takes experts to understand user behavior. We don't have that kind of money."
It's true that you can spend a fortune on research and analysis of user behavior if you are so inclined: field studies, ethnographic research, and contextual inquiry methods can require some pretty rarefied expertise. But adopting a user-centered approach doesn't require such lavish expenditures. Taking a day to talk with a few users over the phone can provide a wealth of useful insights into their attitudes and expectations. And you don't have to have any specialized equipment or an advanced academic degree to be successful.

"It doesn't take experts to understand user behavior. We'll figure it out as we go." Successful user experience design calls for understanding the nature of the problem before you set about constructing a solution. If you don't understand the problem, the only way you can solve it is by accident. User experience problems tend to be so complex that the odds are against you from the start if you expect to stumble upon the solution. It doesn't take experts, but it does take a willingness to plan your approach. Common sense alone isn't enough to guide you to the correct answer.

"We'll fix it in QA." When there are problems with the user experience of a site, they often aren't as easy to isolate as the kind of coding errors that the quality assurance process is designed to catch. User experience issues are frequently more systemic, requiring rethinking of fundamental aspects of the entire site. And because QA comes near the end of the overall development process, there's rarely time to undertake the kind of large-scale design reworking that's often needed. (Besides, your QA team has plenty to do as it is, without trying to identify user experience issues.)

"We can't make room for it in the schedule." In the heat of development, it's easy to forget that the launch of the site is not the end of the process—it's the beginning. Your attentiveness to the calendar is unlikely to mean very much when the resulting site isn't meeting user expectations. The amount of time you spend on user experience at the beginning of the project is nowhere near the amount you'll spend retooling the site and taking another blind stab at meeting user needs. The ultimate success of the project is not about getting to launch. It's about what happens after that.

Reaching Accord

Creating a successful user experience isn't simple common sense, but it isn't rocket science either. User-centered design isn't a methodology or a collection of tools and techniques. It's a way of thinking about how you design the site so that your decisions are rooted in an understanding of the underlying strategy. It's a philosophy that seeks to remind us: If you're only looking at the problem from your own point of view, you're only going to be, at best, half right.

Asking the Right Questions

Jesse James Garrett's new book The Elements of User Experience (New Riders) deals with the fundamental concepts of user-centered design for the Web. In this exclusive excerpt, Garrett talks about good and bad ways to adapt user-centered techniques to fit limited budgets and schedules:

Facing the tangle of small problems to be solved in creating the user experience can sometimes be disheartening. Occasionally, a solution to one problem will force you to rethink other problems you thought you had already solved. Many times, you will have to make compromises and evaluate tradeoffs between different approaches. When you're in the middle of having to make these kinds of decisions, it's easy to become frustrated and question whether you're taking the right approach. The simple fact is this: The right approach is one in which no aspect of the user's experience is left to chance. Make every decision consciously and deliberately, and ground each decision in your understanding of the underlying issues at play.

Having the right frame of mind about approaching the problems you are facing matters most. Every other aspect of the user experience development process can be adjusted to fit the time, money, and people at your disposal. No time to gather market research data on your audience? Maybe you can find ways to look at the information you already have, such as server logs or feedback emails, to get a sense of the needs of your users. Can't afford to rent a usability test lab? Recruit friends, family, or coworkers to participate in informal testing.

The worst mistake you can make is to gloss over the fundamental user experience issues of the project in the name of saving time or money. On some projects, someone will thoughtfully tack on some form of user experience evaluation to the very end of the process—long after the time to actually address those issues has run out. Racing toward launch without looking back might have seemed like a good idea back when the launch date was set, but the result is likely to be a site that meets all the technical requirements for the project but doesn't work for your users. Even worse, by tacking user experience evaluation on at the end, you might end up launching a site that you know is broken but have no opportunity (or money left) to fix.

Some organizations favor this approach, calling it "user acceptance testing." The word "acceptance" is very telling here—the question is not whether they like the site or will use the site, but rather can they accept the site? This type of testing all too often happens at the very end of the process, by which time countless assumptions have gone into shaping the user experience without ever being examined. Those assumptions can be extraordinarily difficult to uncover in user testing, because they are hidden behind layers of interface and interaction.

Many people advocate user testing as the primary means of ensuring a good user experience. This line of thinking seems to be that you should make something, put it in front of some people to see how they like it, and then fix whatever they complained about. But testing is never a substitute for a thoughtful, informed user experience design process.

Questions that focus on specific elements of the user experience can help you gather more relevant input from your users. User tests constructed without an eye toward the elements of user experience can end up asking the wrong questions, which in turn can lead to the wrong answers. For example, when testing prototypes, knowing what problem you're setting out to investigate is crucial to presenting your test subjects with an experience that doesn't cloud the matter with unrelated issues. Is the problem with that navigation bar really just the color? Or is it the wording that your users are responding to?

You cannot depend on your users to articulate all of their needs. The challenge in creating any user experience is to understand the needs of the users better than they understand those needs themselves. Testing can help you understand the needs of your users, but it's just one of many tools that can help achieve the same end.

—JJG


Jesse James Garrett is a founding partner of Adaptive Path, a user-experience consultancy based in San Francisco, and author of The Elements of User Experience: User-Centered Design for the Web. Contact him at jjg@adaptivepath.com.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video