Channels ▼
RSS

All Those Opposed


In any commercial enterprise, Web sites exist for one of two reasons: to help the organization save money, or to help it make money. In both cases, the user experience can make the difference between a successful site and a failure. An intranet can save you money—but only to the extent that it helps employees find information and perform tasks more easily and more efficiently than they can through other means. Putting detailed product support information on your site can save you money by reducing the burden on your customer service department—but only if users can find the information they need.

Providing a positive user experience on a public Web site can help a company make money even if the company doesn't sell its products directly over the Web. Good experiences encourage customer loyalty; sites that are structured to anticipate user needs and facilitate user tasks convince customers that your organization is interested in, and concerned with, their satisfaction and success.

User-Centered Design

Whether your site is for your customers, your business partners, or your employees, you will always be more successful when you take user needs into account. Fortunately, the process of accounting for user needs is a lot more straightforward than the dating process. In fact, the tools and techniques involved in designing Web sites with users in mind—user research, persona and scenario development, and usability testing, among others, have proven remarkably effective.

We have seen, in a few short years, the rise of user-centered design as the leading solution to the problems involved in creating successful Web sites. A growing number of books, articles, and seminars have educated Web designers and developers about the importance of user experience. So why aren't Web sites getting any better?

Obstacles

Most Web sites are not designed. They are, at best, contrived—roughly patched together using a mix of half-understood guidelines, imitations of approaches taken by other sites, and personal preferences masquerading as "common sense." It seems as if, for every Web developer who "gets it," there are ten other people—managers, engineers, even other designers—who don't get it.

The main problem with these "undesigned" sites is that their strategic value to the business is never clearly defined. Too many companies are on the Web because they're afraid of being seen as out-of-step; or they're excited about newfound possibilities, but they don't know what they have to gain from employing Web technologies. In the absence of a defined strategy, every possible application for the site becomes equally important, and the overall user experience becomes a blurry mess.

Whether providing a good user experience saves you money or makes you money, the result is the same: an essential competitive advantage. When the strategy of your site is closely aligned with your business strategy, making the site successful helps make the business successful. If your competitors are investing in user-centered design while you continue doing things the way you always have, you'll soon find yourself falling behind: in customers, in productivity, and in revenue.

Refuting Common Objections

Introducing a user-centered design approach can sometimes be difficult for an organization. Objections inevitably come up as the organization wrestles with the best way to create a successful user experience. Let's take a closer look at some of the most common objections.

"We know our users—they're just like us." It's easy to fall into the trap of thinking that what works for you will also work for your users. But, as much as you might have in common with your users, their needs, circumstances, and behaviors will differ from yours in crucial ways. It's not a question of whether the site works for you. After all, as the site's developers, you know more about the site than anyone. The question is whether the site works for your users.

"We know our users—we've done all this market research." Market research is great, and it can be an undeniably valuable tool in the user experience design process. But it won't do you any good if there is no user experience design process that determines how to apply your research. Relying on your engineer's ability to recall relevant research findings while he's in the middle of coding the interface is a very poor substitute for explicitly planning the user experience of your site.

"All we have to do is follow this list of guidelines." The demand for easy shortcuts that solve difficult problems seems insatiable. Selling lists of such rules of thumb has proven a profitable enterprise for a number of self-appointed gurus. But the promise of a secret formula offered by these guidelines is rarely fulfilled. The variety of problems and solutions in Web user experience design is so broad that general rules invariably fall short. Checklists are fine for inspecting a finished product; they're nearly useless for designing one from scratch.

"The interface is trivial compared to the technical work we need to do." Technical problems can certainly seem complicated when you're planning a Web project. But even the most difficult technical problems yield to analysis and careful consideration. The same level of consideration is necessary to crack user experience problems. In the case of user experience, you have to contend with many factors that are not so easily identified or even named as the factors involved in a technical problem—simply because user experience problems fundamentally come down to human cognition and human behavior. Figuring out technology is easy compared to trying to figure out people.



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