Developer

Creating sites that meet users' expectations

The aim of designing a usable Web site is building a site that meets users' expectations. While working on a client Web site, the author was reminded of how easy it is to lose sight of such usability basics. He shares his lessons relearned.


The aim of designing a usable Web site is building a site that meets users' expectations. Users base their expectations on previous experiences, such as visiting other Web sites, seeing other pages on your current Web site, or exploring the physical analogs to the various Web design visual metaphors. These expectations comprise much of the conceptual framework that visitors use as the basis for their interaction with a Web site. Expectations also influence where visitors look for information, how they recognize clickable links, and how they accept feedback that a task was completed.

Web builders may be familiar with this usability concept, but that doesn't mean they always implement it successfully. In fact, while working on a client Web site, I was reminded of how easy it is to lose sight of such usability basics. There are some lessons you need to relearn and reinforce from time to time, so I thought I'd share my experience.

The saga of the form
We were working on a long form—an online employment application. Because of its length, it was originally presented as a multipage form with separate pages for instructions, personal data, skills and certification questions, work record, and previous employers' contact information. The idea was that the multiple pages would break the form into logical groupings that were less intimidating and easier to use than a single long form.

We started hearing complaints that the multiple pages made the form seem longer than it was and required too many extra steps to move through the pages. Also, some visitors were having problems moving back and forth to a previous page to confirm or edit their entries. The result was a poor form-completion rate.

Fixing the form
To address these issues, we consolidated the five-page form into two pages. The first page was for instructions and a click-through agreement giving the Web site owner permission to verify the information on the form. The second page contained the actual form elements.

Keeping the text-heavy instructions on a separate page prevented them from expanding the form to an unmanageable length, while consolidating all the form elements onto a single page made it more concise and allowed the visitor to scroll freely through the form to review and edit entries.

Informal testing confirmed that the new two-page form was easier to use than its five-page predecessor. So far, so good.

The problems begin
All we had left to do was implement the back-end form processing and create the confirmation page that the visitor sees after submitting the form.

The form processing consisted of capturing the data in a file for safekeeping and e-mailing a copy to the site owner, who requested that the e-mail version closely resemble the appearance and formatting of the onscreen form. To comply with that request, we were doing a screen scrape of the completed form and sending a slightly modified version to the owner in an HTML-formatted e-mail.

Since the form was so long, someone suggested replacing the brief "Thanks for your submission" message on the confirmation page with a redisplay of the form data so visitors could review and confirm the submitted information. And, showing visitors a copy of the data being sent to the site owner offers them meaningful feedback about the success of their submissions.

On the surface, it sounded good. Unfortunately, the confirmation page didn't have the intended effect because it ended up looking too much like the original form page. Despite significant differences between the form and the confirmation screen, test users assumed their submission failed when, after submitting the form, they saw a screen that was substantially similar to the previous screen. They immediately began looking for a way to resubmit the form and ignored the not-so-subtle details such as the text labeling the page as a confirmation of the data being submitted.

What went wrong
Our good intentions to give visitors confirmation of their form submission failed because we didn't present the information in a format that the visitors expected. As a result, they misinterpreted what they saw. Visitors subconsciously dismissed differences between the form and confirmation page as anomalies introduced by the failed submission attempt and didn't examine them in enough detail to dispel that impression.

On other Web sites, clicking the Submit button on a form usually brings up another page that looks very different. It may present some or all of the form data for verification, but the arrangement and formatting of that data makes it clear that it's a new page.

Success at last
After we realized why visitors were having these reactions to the confirmation page, it was relatively easy to correct the problem. We restyled the form data so there was a clear and obvious difference between the appearance of the form and the verification page. In other words, we gave visitors what they expect: an instantly recognizable change to a new page when they click the Submit button.

Editor's Picks