When we talk about creating Web sites and online experiences, we talk about users — as in, user experience, usability, user-focused design. The emergence of an entire discipline focused on end users has essentially revolutionized the Web industry (even though better serving your audience with intuitive content and design, if you really think about it, seems like a “no-duh”).

But there’s a debate simmering in the online and software communities about whom we as user experience professionals are really serving. It’s not really about who they are, but about what we call them. A number of influential people in the profession have spoken out (some vehemently) about dropping the word “user” when we think about and speak about … well, about the consumers of our work.

What’s in a word?

It seems nit-picky, but people are passionate about the word choice. Some argue that “user” bears too much resemblance to the term describing drug addicts. Others argue that it doesn’t do justice to who the person on the other side of the computer screen really is, and what he or she is out to accomplish when interacting with a site.

“The idea to design for a ‘user’ is so reductive and limiting that I think we should rid it … from our vocabulary and design practices forever!” says Pietro Turi, author of the site iamnotauser.com.

The problem is that “user” has become the anonymous and generic word for a faceless, nameless avatar of a person. A “user persona” is a made-up description of some fictional person we invent to try to get in the minds of people who use the sites we create. A “user account” is a bunch of numbers and gobbled code managed impersonally by an IT guy who doesn’t care about the frustrated flesh-and-blood having a breakdown in some cubicle somewhere because she can’t remember her password. (You might have guessed that the latter bears an uncanny resemblance to me.)

I’m fascinated by this debate as someone who is a linguist at heart and a writer by craft. I spend my days fighting for the honor of words endangered by misuse and disrespect. And I agree that we as Web experience designers and strategists must be deliberate about everything we do — including how we refer to the people we serve, if we really care about serving them with excellence.

Designing for earthlings

It’s difficult to find an alternative word that can serve as the all-encompassing description of our audience the way that “user” does. “User” reminds us that the person is more than a reader, more than a viewer. He or she can be a customer, a reader, a game-player, a journalist looking for more information. Depending on which discipline they’re most interested in, different experts have suggested substitutes — content people prefer “readers,” customer experience specialists advocate for “customer.” But therein lies one of the biggest challenges we face in Web: that specialists think and operate in silos, concerned with their own piece of the pie. UX specialists were meant to be the point of connection for everyone — the nucleus that holds everyone together to think about the cohesive experience of the — who are those people again?

There is a movement to switch to that very term: people. We design (and write) for people! Which we do … except, is the term descriptive enough? Do we design and write for just people, or for people who are information seekers and performers-of-tasks, people who are actively engaged in making our content and tools work for them?

I have been more mindful of avoiding the generic and careless term “user” as I map out strategies for successful content and design with my clients. Where possible I talk about “customers” (even when the audience may not yet be customers — I like to be aspirational). When I know the people we’re specifically creating sites for (as I often do in the B2B world), I call them that: the jewelers, the pharmacists, the employees.

Officially I am not taking a stand for or against “users.” But I do strive to keep in mind that these are real people, with real problems. They will each experience the site or application in a different way, based on their individual histories and perspectives. We can generalize but should never be dismissive of this fact: that our “users” are doing more than using. They’re learning, absorbing, solving problems, improving their lives. If we can strive for those goals with genuine humans in mind, we’ll transcend the semantics of the word and do our jobs well.

As an active Web user, you most likely fill out several forms online every day, at a minimum. Forms are how we interact online, and they’re very much a part of our personal and professional lives, like it or not.

So why, as ubiquitous as they are, do so many Web forms leave us feeling frustrated? Why do so many users abandon  a form before they’re finished filling it out? Why does Luke Wroblewski, the man who literally wrote the book on Web form design and usability, feel like he has the right to stand up in front of several hundred Web designers (as he did at An Event Apart in San Francisco last December) and tell us that our forms “look like a poo storm?”

Forms are everywhere, and most of them are ineffective at best, downright unusable at worst. Even veteran Web users struggle to fill them out sometimes. Wroblewski explains the convoluted process that often turns the horse into a hobbled camel: regardless of who initially designs the form, marketing, sales, and IT all have a stake in what it inevitably becomes, each adding their own touches and requirements to it. And often nobody is minding the store to make sure the final form achieves its primary goal: getting users to complete it.

Here are some tips – from Wroblewski’s AEA presentation as well as a couple of my own — for the next time you have to manage the design of a Web form:

1. Resist the urge to ask for every last detail. It’s understandable why it happens. The rare opportunity to get prospects to turn over information about themselves gets your salespeople and marketing teams salivating. But do you really need to ask for a person’s fax number? How about street address? What’s the least amount of information you can collect at this moment? People are more likely to fill out the form if they don’t have to labor over it. Consider each field and requested piece of information carefully before including it. And don’t forget to tell users how you’re planning to use the data, Wroblewski says — people won’t give you an email address or phone number if you’re planning to sell it to someone else or spam them repeatedly.
2. Think linearly. How does the user’s eyes move through the form? Chances are, they do not naturally jump back and forth between side-by-side fields. Users tend to scan down the left side of the page, so your form should be designed accordingly, Wroblewski says. If you do need to jump around, use strong visual cues to draw users’ eyes to where you want them to go next. And by all means, avoid placing the “Clear All” button where users expect the “Submit” button to be — the biggest faux pas of Web form design is to stick a button in a user’s natural flow that will wipe out all of their hard work instead of rewarding them. It’s quite possible they’ll be so disgusted that they won’t bother filling the form out again after that.
3. Don’t break with convention. Because we fill out so many of these things, we’ve all become very accustomed to the design standards of Web forms. Occasionally a talented interaction designer finds a way to tighten up space and give a form a truly unique look that also functions well. But often those who set out to build a better mousetrap fail in their attempts. Certain conventions work, so stick with them. For example, a trend is to place the field labels inside the fields. Designers also try placing them to the right or left, or underneath the field. But Wroblewski says studies show that users complete a form 10 times faster when the labels are placed above the field. Smart, thoughtful design is always welcome, but it’s not always necessary to innovate when a convention works perfectly.
4. Treat the form as a holistic experience. Users get to the form from someplace, and when they finish the form they expect to be taken someplace else. People who create forms sometimes forget this, and focus more on the form itself than on the entire user flow. When sending the user to the form, be careful to only make promises based on reality — let users know what to expect and exactly what they will get from filling out the form. If using a multiple-part form, consider using a progress indicator, and make sure it’s accurate. (Wroblewski uses Fidelity.com as an example of a four-step progress indicator bar that misleads users by failing to mention the requirement to create an account in the middle of filling out the form, a major disruption in the flow.) And by all means spend as much time considering the confirmation page and process as you do the actual form. Users want to know they were successful, and want to be able to do something next as an immediate reward for their efforts.
5. Use a writer. I’ve known some IT people who were great with words. Designers too. But much of the time, forms need content help. Instructions, labels and buttons often don’t communicate clearly what exactly users should do. Calls to action are unclear or nonexistent. And the opportunity to provide context-based help (such as pop-ups explaining what the information is for or why the company is requesting it) is often overlooked. An experienced Web writer can help you see the form from the user’s point of view and craft language that will make your form successful.

A few weeks ago my favorite usability guru issued an Alertbox reminding communicators of the importance of always maintaining context when writing Web content:

Writing for the Web differs because various users might approach a given piece of content in different ways … In some of these scenarios, users see only a small portion of the content displayed out of context. They might, for example, see only a headline, or perhaps a headline, summary, and a thumbnail photo.

This concept recently demonstrated itself in my own life when I signed up for InstaPaper. I have probably 200 different publications and blogs that I really like to read regularly, but unfortunately my days are so crammed with client deadlines that taking the time to peruse a long and thoughtful article or blog entry about a topic I’m interested in is a pure luxury. I’ve used Bloglines for years to manage RSS feeds for all the blogs, but unfortunately I’m guilty of letting my Bloglines feeds fill up and remain unread (it’s not unusual for some of the more prolific ones, like Boing Boing and TechCrunch, to hit the max of 200 feeds and stay there for weeks).

My husband recently introduced me to InstaPaper. It’s similar to delicious in the way that you can capture articles to read later, which was always my second step after finding an article I wanted to read in more depth in my RSS feeds. With InstaPaper, though, once you grab the article, you can instantly load it into an iPhone app, where the entire article appears and can be read offline at anytime.

So just to review:

An article about, say, electronic medical records that I want to read on The New York Times‘ Web site, would be carefully presented when it appears on its primary site. A catchy blurb and thumbnail on the site’s home page would draw in readers. An intelligently written headline and subhead, along with callouts, might entice readers to read further. Design-wise, photographs are strategically placed, along with captions, to help guide the eye. The entire article appears in the selected NYT online typeface. Ads appear as they are intended, to draw readers interested in similar topics but to avoid being so intrusive as to annoy readers. Related articles of interest are listed to the side so readers can easily jump to other places they’d like to explore. The experience is carefully controlled.

Then: I pull the article into Bloglines. The original headline and a blurb from the article (sometimes just the first few lines or paragraph) are the only things working to encourage me to read further. Photos may appear, but it’s often hard to predict where they’ll show up, and captions don’t always come with them.

I click the headline to be taken to the NYT site, where I can definitely dive in to the article in its original intended form — except I don’t have time to read it right now. Later. Mañana. I click my “Read Later” InstaPaper bookmark button on my browser toolbar and InstaPaper captures the article. Later, while waiting in line at the bank, I fire up my iPhone, refresh my InstaPaper app, and I see this:

The mobile version of InstaPaper articles take you back to the Web circa 1995 — all text, blue links, the most basic of HTML. You don’t see images, you see image ALT tags (so don’t forget how important those ALT tags can be!). Banner ads that flow with the text on the original site show up as ALT tag text in the middle of an article, sometimes disruptively. And only some of the supporting text shows up; captions, related articles, subheads, callouts and other elements often get lost in translation.

It makes me think about how we can often be dismissive of the need to “design for mobile,” especially these days when devices such as the iPhone have Web browsers that typically present sites the way they were originally intended. But the more important thing is that it’s important to always keep in mind that readers may be seeing your content in many different ways — and that it may change hands, and formats, many times between its original posting and a reader’s experience with it.

The Wired article about Google’s new Web browser, Chrome, talks about how the software engineers essentially threw every preconceived idea about the Web browser toolbar out the window, and started from scratch. Tools such as the back button made the cut to be included in the toolbar; something like the bookmark bar is optional only if users depend on it, since Chrome is introducing several new navigation methods that user testing shows are more effective than bookmarks.

There’s something really wonderful about throwing out all assumptions and starting over, instead of just repeating the same standard nav tools that were built into browsers 13 years ago. Yet Google remained sensitive to the familiarity quotient, knowing they’d have the best success if they didn’t completely move users’ cheese.

And from a communications point of view: how smart is it turn a technical explanation of Chrome into a comic book, with Google software engineers as the characters? Talk about knowing your audience …