“Forms suck.” So begins Luke Wroblewski’s new book on how to design Web forms.
He’s right. Nobody likes having to fill out a form. It’s the red tape we must cut through 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.
© ACM, (2008). This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in interactions 15, 4 (Jul. 2008), 68-70. DOI= http://doi.acm.org/10.1145/1374489.1374506
While users may find forms a headache to use, 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. Users filling out forms will not write us 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 our innovative tab order is. When we achieve the highest praise possible for form design (“Well, that wasn’t too bad”), we still must pay for our own beer.
While forms thrill neither the user nor the designer, they are nevertheless important. When a customer must wrestle with a form, we frustrate the very people we are trying to please. They feel worse about our brand, and buyers can become so confused that they abandon the transaction, leaving money on the table.
My bank’s website, for example, stubbornly rejected my work unless I specify 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. No matter if choosing the right flight takes a while and involves weighing many factors and consulting with others. If you take too long it gives you the boot. Imagine a Nordstrom’s 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?
Form design is not solely about giving users a warm and fuzzy feeling. Usability issues can profoundly affect the bottom line. 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 web form that is effortless for people to fill out is deceivingly difficult to create. There are myriad factors to consider, fanning out in a quickly growing decision tree. Each decision has several possible solutions, and each solution has several pros and cons to weigh. 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? How 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 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, not the machine’s, the differences between radio buttons and drop-down menus, and so on.
For veteran designers the book is a convenient reference of factors to consider and a pragmatic synthesis of research findings. 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. There are bound to be some insights and ideas that old timers hadn’t thought of.
I picked up several nuggets along the way. One of them pertains to the placement of labels next to fields. I already had a preference for right-justifying field labels just to the left of the fields. Wroblewski affirms this practice. What was news to me was the fact that placing the labels 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 spare the extra height required by this approach. It’s also handy if the form is to be internationalized, because it leaves plenty of elbow room for the labels to stretch out when translated into less dense languages, such as German.
Before we let new users in to play with our app, we need to have them register, right? Not so fast. While this is the most common practice, Wroblewski challenges this basic assumption. First of all, it turns out to be a major source of UI friction, and we lose a lot of potential users at the registration step. Secondly, it turns out that it is often possible to do this the other way: confer value first, ask questions later. Drop brand new users right into the application to begin experimenting. No friction, no demands, no commitment required. Once they are engaged and they can see the benefit, they will be far more 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, rather than expecting them to pay the price of filling out the registration form up-front.
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 exist not for any benefit to the user, but for the marketing department. They were a major source of attrition on eBay, 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, Web Form Design is highly usable. The tone is straightforward, clear, and friendly. It is loaded with example screenshots, making it quick to read or skim. Every chapter ends by summarizing best practices.
The book is also thorough. Before reading it, I made a list of design issues relating to forms to see if they were covered. 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 other narrow topics I was hoping to see treated, such as dealing with credit card numbers (verify the internal checksum instantly on the client side), birthdays (avoid forcing users to divulge their age), time zones (infer a default by looking up the geography of the visitor’s IP address). And it would have been nice to see a discussion about the wealth of insight that can be gleaned by mining the depths of historical usage data.
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 for any of us designers 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. In fact, some eye-tracking studies were conducted just for the book. 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.
———
D. Philip Haine founded Obvious Design, LLC, a San Francisco consultancy specializing in product vision & design, in 1997.
