Enabling better outcomes and experiences

XV.4 July + August 2008
Page: 68
Digital Citation

(P)REVIEWWeb form design

D. Haine

back to top 

Luke Wroblewski
Rosenfeld Media, 2008
ISBN 1-933820-24-1
$36.00 (paperback and digital)
$19.00 (digital only)

Reviewed by D. Philip Haine

"Forms suck." So begins Luke Wroblewski's new book on how to design Web forms.

Nobody likes having to fill out a form; it's just that bit of red tape that must be dealt with before we get what we want. Before we are approved, there is an application form. Before we get to use a Web service, there is a registration form. Before our purchase is complete, there is a payment form. Form completion is a cost we must pay before we benefit.

Users may think that forms are a headache to use, but they aren't such a kick to design, either. What's fun is designing the heart of a product—the parts people enjoy, appreciate, and want to use, the parts that make a difference in their lives. With forms, users will not write us with heart-felt stories about how their lives were improved by our right-justified labels. They will not thank us profusely for putting just the right amount of explanatory text underneath a field. They will not tell their friends about how innovative our tab order is. When we achieve the highest praise possible for form design ("Well, that wasn't too bad"), we have to pay for our own celebratory beer.

While forms may thrill neither the user nor the designer, they are nevertheless important. Wrestling with a form frustrates the very customers we are trying to please: Customers feel worse about our brand, and people can become so confused or alienated that they walk away from the transaction, leaving money on the table.

My bank's website, for example, stubbornly rejected my work unless I specified the dates in the format MM/DD/YYYY. Imagine a human teller saying: "I'm sorry, the date on your deposit slip is not formatted according to our standards. Please fix it and get back in line."

Or consider a major airline's website that, even today, times out if the form goes untouched for a while. This is like a department-store clerk saying: "I'm sorry, you've been standing in the same area for too long. To continue shopping please leave the store and come back." If you must start over, how likely are you to walk into the same store?

Business-wise, form design is not solely an issue of customer satisfaction and retention. Usability issues can affect the bottom line directly and extremely. The book describes a Web retailer whose revenue increased by $300 million after a small change to the checkout process (the company eliminated the requirement for shoppers to register before checking out).

A well-designed form is barely noticeable. But that doesn't mean the design process is. Like most design problems, achieving a concise design that seems, in retrospect, obvious, requires much work. There are myriad factors to consider, each with multiple alternatives, each with its pros and cons. Should we have one long form or a sequence of short forms? Should help be provided in-line with the form controls, on the side, or on top? At what point should we validate fields and deal with errors? You could fill a book with the subtleties of form design.

Fortunately, Wroblewski has written that book. Drawing on years of experience designing for eBay and Yahoo, he has cataloged the major considerations involved in creating forms. He walks the difficult line between writing for novice and veteran designers.

For beginning interaction designers and de facto designers with nondesign job titles such as engineer, product manager, or founder, Wroblewski's book serves as a primer on interaction design. It covers basics like thinking of the problem from the user's perspective, rather than the machine's. It covers the differences between GUI elements like the radio buttons and dropdown menus.

For veteran designers the book serves as a convenient reference and cheat sheet of things to consider. Before embarking on a new form design project it would be worthwhile flipping through the examples and advice to become re-sensitized to the issues. Plus, there are bound to be some insights and ideas that old timers hadn't thought of.

I picked up a few nuggets along the way. One of them pertains to the placement of labels next to fields. I already had a bias toward right-justified labels positioned just to the left of the fields, a practice Wroblewski affirms. What was news to me was how having labels above the fields is even more efficient. Citing an eye-tracking study, Wroblewski demonstrates that this arrangement allows the user to take in both the label and the field with a single eye fixation. It's a good design choice for layouts that can afford the extra height this approach requires. It's also handy when the form will be internationalized, because it leaves plenty of elbow room for the labels to stretch out when translated.

Another assumption Wroblewski challenges is that users must always register before they get to use our Web app. It's a logical and standard way to proceed, but there are costs. We are making a demand from users before demonstrating value, the opposite of a normal sales process. It's therefore a source of friction and a point at which we lose people. Wroblewski gives examples of a different strategy: Play first, ask questions later. Drop the new user right into the application to begin experimenting. No friction, no demands, no commitment required. If it works for them, they will be willing to register to save their data or to access other juicy features. Wroblewski calls this strategy "gradual engagement," because we tempt the user with our product in stages.

Another discovery I found fascinating pertained to marketing questions like: "What's your household income?" or "What is your date of birth?" These intrusive questions are on the form not for the user, but for the marketing department. For eBay, they were a major source of attrition, and removing them resulted in far more successful registrations. The fascinating part is that by asking the marketing questions later, after registration, significantly more people were willing to answer them.

As one would hope for a book written by a designer, it is highly usable. The tone is straightforward, clear, and friendly. It is loaded with example screen-shots, making it quick to read or skim. Every chapter ends by summarizing best practices.

The book is also thorough. When I began reviewing it, I made a list of design issues relating to forms to see if they were addressed. It fared well. In-line validation of fields as you go? Check. The perils of putting field labels within the fields themselves? Check. Strategies for revealing contingent fields? Check. Dynamically checking user names for availability and passwords for security as the user types? Check. And my No. 1 pet peeve: requirements for formatting phone numbers, social security numbers, or dates in a particular way, rather than accepting any reasonable way? Check.

There were a few specific topics I was hoping to see, such as dealing with credit card numbers (verify the internal checksum instantly on the client side), birthdays (avoid forcing users to divulge their age when possible), time zones (infer a default by looking up the geography of the visitor's IP address). It would have been nice to see a discussion about the incredible insight that can be gleaned by scouring historical data for patterns of input and error.

I would also have been grateful for specific treatment of international concerns, particularly the details of how common fields like names, addresses, and phone numbers should change for users in different locales. This is difficult knowledge to come by, and often, these locale-specific factors are the only thing preventing people from around the world from benefiting from our work.

Wroblewski rightfully avoids giving blanket advice to any given design problem. Again and again, he emphasizes that the correct answer depends on the situation. He follows through by laying out what those factors are.

Wroblewski is upfront about the sources of his opinions. Some of his claims are backed up by published or unpublished usability studies. Some eye-tracking studies were conducted just for the book. And when no definitive evidence is available and Wroblewski must resort to his professional opinion, he says so.

The world of form design will continue to evolve, and best practices will continue to emerge. Hopefully, Wroblewski will return with updated editions of the book as the field of interactivity continues to mature.

Web Form Design: Filling in the Blanks is an excellent guide for new or de facto designers and a handy reference for veterans. Wroblewski has done the dirty work for us in researching what works best. By following his advice, we—and our users—can quickly and competently get through the forms and onto the fun stuff.

back to top  Author

D. Philip Haine founded Obvious Design, LLC, a San Francisco consultancy specializing in product vision and design, in 1997. His articles can be found online at StealThisIdea.com. For more information on Haine, please visit http://obviousdesign.com.

back to top  Footnotes

DOI: http://doi.acm.org/10.1145/1374489.1374506

back to top 

©2008 ACM  1072-5220/08/0700  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2008 ACM, Inc.

Post Comment

No Comments Found