Here’s a little exercise for you to keep in mind the next time you design a web page. Bear with me here - I do have a point.

For this exercise, first take a moment to remember why instructive text exists. If you’ve read my article over on Vitamin on instructive design, you know that instructive text can be a great way to help get users oriented and communicate to them how to use an interaction (provided, of course, you keep it extremely short and make it stand out from other design elements).

Remember how the instructive text you’ve seen before looks. Remember that when users see text that stands out, positioned in close proximity to an input field, they’re likely to associate the two things and think the text is somehow going to be helpful. You do this yourself every single day.

Here’s an example of instructive text, in case you need help visualizing something. (In this example, a default value has been created for the email address input field to tell users what to enter.)

Now step back. Waaaaaay back. Imagine you’re not a geek. Imagine you’re, say, a scuba instructor. You have a degree in business, you used to be a rather successful sales manager, and you cashed out early to buy a hosue on the beach and teach people to scuba dive. You’re smart. You’re a bit of a genius, in fact, because you figured out how to live your life better than everyone you know. But you don’t have much experience with computers.

Imagine you know very little about using computers beyond how to buy a book on Amazon, maybe get your bank balance, and check your email. In other words, imagine you know as little about computers as most of the people who don’t work for your company. And imagine you’ve decided to apply for a part-time job at the scuba shop down the street. Sure, it’s a chain, but it’ll be fun. You click a link to get to the job application, and you see this.

Nice enough design. Nice enough logo. OK, let’s get started.

Take a look at what loads next on the page.

The red text here looks like it’s supposed to tell you something important, but it’s not telling you anything you understand. It’s not telling you to stop what you’re doing because there’s a problem with the site. It’s not telling you what to do instead. It’s not telling you it’s sorry for screwing up your plans.

What is it telling you? Seriously. Look at it like you’re new to all this. Close your eyes if you have to. Let all that web expertise drift away and then open your eyes and see this page like you have no idea what a SQL Server is.

Do you see it? Do you see how this looks like it’s supposed to be helpful? Do you see how this would frustrate you when you tried to complete this job application only to realize that the system was down and no one told you? Do you see how this red text is absolutely meaningless?

Good.

Now, come back to reality and tell me how you’re going to prevent this, in every application you work on, for the rest of your life.

Please, please, please. Get this.

Continuing the Design Stories series, here’s a look at the design of character counters (the little text messages used to indicate how many characters can be entered into a text field).

Many sites skimp on the grace that character counters can offer and use something that takes the least amount of work to build, but can be quite frustrating for users. For example, an input field with a set character limit should communicate that limit to users, but many sites leave this important element out. When this happens, you often end up with the ability to enter anything you like, even though the entire string cannot be stored.

In these cases, users are informed of their mistake via an error message.

This method blames the user, essentially telling him that he should have known before pressing the Submit button that he couldn’t enter more than 50 characters. This is no good.

In another method, developers prevent users from being able to enter more characters than the limit allows, and users simply run out of space. So you’re typing along, humming a happy tune, and then your keyboard appears to stop working.

Also not good.

Some sites, hip to the notion that we should communicate to users what’s going on, have opted to use a form of a poka-yoke device. Instead of waiting until the user presses Submit to show an error, these sites warn the user using a bit of instructive text.

This helps. It’s definitely better than the previous solutions (which, clearly, are not solutions at all). But there’s still a big problem. Sure, we’ve warned the user that she can only enter 50 characters, but we’ve also made it her responsibility to count the characters herself.

With all this in mind, the best solution is to present a decrementing number of characters, telling the user every step of the way how many characters can still be entered.

Now, we accomplish several good things. First, the user is aware that there is a character limit from the very beginning. Second, the user knows with every keystroke how many characters can still be entered into the field. Finally, we’ve completely eradicated the user’s risk of hitting the Submit button and getting an error.

Instructive text is a good thing, but when it comes to character limits, instructive text with a decrementing variable makes a far superior poka-yoke device, guaranteeing our users will successfully get past this form element and onto the next step.

Larry Constantine’s new article, Designing Web Applications for Use
, is a great piece about the many flaws of user-centered design, as well as the advantages of focusing design efforts on the activity the application is meant to support. I highly recommend it. It’s great to see more people latching onto Activity-Centered Design.

And in the surreal category, this article tripped me up a little bit. I was reading it just now and generally nodding my head and agreeing with everything Constantine had to say when, quite unexpectedly, I saw a quote … from my own book.

My first-ever Vitamin article is now live! Check out “Communicating web 2.0 through design” and learn to use instructive design elements to teach users how to use all those fancy new gadgets that come with Web 2.0 interfaces.

Thanks very much to Lisa Price and the crew at Vitamin for the opportunity to contribute to such a great resource.

Dan wrote to ask what I think about ads and ad placement in web pages (I didn’t talk about it in the book). He’s been experimenting with some different design styles so the ads appear to be more a part of the page than traditional banner ads and Google’s text ads.

We’ve learned over the years that users ignore banner ads. To remedy this, we tried interstitial ads, animated ads, flyouts, you name it. Nothing has really worked. As soon as a new trick is invented, users catch on and quickly learn to ignore it. Text ads have been most effective, but that’s primarily because the companies serving them have made the ads relevant to the page’s content, and text is the only format left that hasn’t totally alienated our audiences.

You can’t be sneaky on the web. The web always finds out. And when that happens, you’re cooked.

So my answer, Dan, is that, until someone invents a way to make ads meaningful and truly useful, I suggest you do … nothing. Let your users ignore the ads. That’s what they want to do, and trying to dupe them will only drive them away. Your best bet is to keep telling an honest story - on your own site, through the work you do with clients, and so on. An honest story that captures interest earns trust, and trust earns you the traffic you need to raise the incredibly low click-through rate earned by online ads.

The rate will still be incredibly low, but it’ll be slightly less low.

Of course, you could be the guy who invents the new ad-delivery method.

Good luck.