Debates about web form design

18 Apr 2012 - 11:37pm
2 years ago
11 replies
1847 reads
Formulate
2007

I'll shortly be giving a talk that plans to address some of the most commonly debated elements of web form design.

I know what questions I get asked over and over again, but want to make sure my view isn't biased. So I'd like to hear from you. 

What debates — about competing approaches to the design of web forms, not general considerations per se — have you been involved in?

Examples provided so far (on other forums) include:

  • whether to place the main action button on the left or on the right;
  • whether to place field labels above or to the left of fields;
  • whether to indicate required fields or optional ones; and
  • whether to lay the form out in one column or two.

 

Feel free to declare a vote for any of these debates and/or add your own. 

By the way, I plan to share some of my answers to these debates more widely than just the talk. 

Comments

19 Apr 2012 - 2:36am
Sathyan V
2009

One issue i'm working on currently!!

_Action Buttons (Save, Cancel, etc) after couple of page downs in a long form. Is it better to break the form into tabs? Or is it better to have it at the end provided the user has to completely fill it from start to end.

19 Apr 2012 - 9:01am
Formulate
2007

Thanks Sathyan, that's a good debate.

FWIW, I would only use tabs if the questions in the different tabs can be answered without reference to the other tabs (i.e. there user doesn't have to follow a strict flow from one section to another). Tabs can also get easily missed, and you've got to deal with the issue of what to do if the user clicks into a different tab without saving the answers (if any) they've given in the current tab.

Perhaps you should be looking at single-page versus multi-page instead? With multi-page there is a linear flow, and the chance to save data (back to the server) on a incremental basis. It might also make your form look less intimidating than one long page. 

For more on this issue, perhaps this post on UX.StackExchange will be useful: http://ux.stackexchange.com/questions/19617/how-does-having-multiple-stages-of-a-form-affect-conversion-rate/20250

19 Apr 2012 - 9:11am
holger_maassen
2010

Sorry I'm busy but here are two hints ...

1st Discussion about placement of OK, CANCEL buttons:

http://www.boxesandarrows.com/idea/view/13639

and 2nd an article regaring your debate: 

 http://ux4dotcom.blogspot.de/2009/06/form-of-forms-we-need-them-but-also.html

20 Apr 2012 - 6:35am
Formulate
2007

Hi Holger

Thanks for taking the time to comment.

The OK/Cancel debate is a good one, although I personally think it relates more to dialog boxes than forms. My take on that one is that the platform convention is the one to stick to.

Your article on basic form design is a good one. I would agree with many of the points that you make. I guess I was more interested in finding out about design principles/practices that are debated. For example, your point 5 says "Mark mandatory fields obviously and clearly". But some would argue that it's better to mark optional fields (see, for example, http://www.netmagazine.com/features/10-things-every-designer-needs-know-about-forms). It's these sorts of debates that I'm interested in hearing about (and hopefully then bringing together all the points of view to make one sturdy recommendation).

19 Apr 2012 - 11:30am
Adam Korman
2004

All the answers are here:

Web Form Design: Filling in the Blanks by Luke Wroblewski

http://www.lukew.com/resources/web_form_design.asp

20 Apr 2012 - 6:42am
Formulate
2007

Hi Adam

Thanks for joining in the discussion.

Luke's book is an invaluable one but I'm afraid it doesn't have all the answers. For example, when it comes to label alignment, Luke relies on a small study conducted on one very simple form, with particularly short field labels. The learnings about eye movements, speed etc are valuable...but they don't by any stretch represent the final word on the matter. One big problem with labels on the top of fields is that they make the form twice as long, vertically. Not a major consideration when you only have a handful of easy questions, but if you're trying to get people to fill out a loan or passport application, however, the length could become very intimidating and thus a real issue.

So, despite the publication of Luke's book — which was sorely needed, as was the excellent one by Jarrett and Gaffney — there are plenty of important debates still being had. It's those debates that I hope to examine for peopl with the aim of coming up with some actionable recommendations.

22 Apr 2012 - 12:29pm
StevenDufresne1
2012

Addittion: Do you necessarily need a standard sign up form?

 

http://www.lukew.com/presos/preso.asp?25

20 Apr 2012 - 11:07am
Caroline Jarrett
2007

Thanks for starting this thread and many thanks for the recommendation of our book. I'm enjoying following up the various links people have mentioned- keep them coming!

On the buttons debate, I recently did a short presentation looking at some of the research - including LukeW's, plus a couple of more recent studies:

http://slidesha.re/HDw7zN

Best

Caroline Jarrett

@cjforms

20 Apr 2012 - 12:46pm
LFrancis
2009

Yes, thanks for starting this thread.

So many forms on the web today...almost always some element in anything we do these days it seems.

I think that having these great books as a foundation is really important because we have to start somewhere and there is real value in building upon knowledge and wisdom that has been collected by observing people using things. I think that as a best practice, we should start with a resource like Luke's book. Then comes the art of interaction design, the scenarious we are designing for which include different types of people, goals and data scenarios. Each of these and all their permutations need to be considered in the design. And, as our awareness increases, we need to consider web accessibility as well in many cases. 

So, how do we figure this out? The best way I think is to use some of the techniques for rapid prototyping to flesh out the various scenarios and mock up prototypes for them. Then take these and get them in front of non-team people for feedback. In the case of forms, it can be pretty easy to build a working prototype and this is an excellent step as the delivery mechanism for error messages and guiding people through the form can be enhanced with visual clues (mouseovers, java script etc..) (remember with Java script though that it won't be web accessible). We can go a long way with paper testing though, using post it notes and cutting and pasting. This is where we learn about what people see and what they need as far as help to fill in the form.

Testing a working prototype is a great way to measure people's reaction to a long form. We should be careful about assumptions that people don't like a long form. We should step back first off and make sure that we need to collect all that information at that moment, and if we do, keep looking for the best way to collect it. By having a form all on one page, a person can scan up and down and get a sense of how much work there is. If there are unknown numbers of pages, that can seem daunting. Or it can seem daunting if we tell them there are x pages. Here we might consider sharing how much time we expect them to spend and how much time is left...for example. So there are many ways to address things that come up that might prevent people from completing the form, or ever wanting to come back and do something else.

So best practices are excellent for a starting point and one of the best practices is consistency and alignment of flow. So pick something, and then work with people to sort out what seems to work and then make sure you have ways of testing it in production. Create logs that tell you if certain error messages are displayed, that tell you what fields were valid when someone cancelled etc...customize the logs so that you can get the behaviour information that is truly going to inform where the form is working and where it isn't.

Finally, remember that the form itself is part of a continuum of touch points a customer has that set their expectations and provide knowledge about the form. The design of the form must take into consideration these other elements if it is truly going to be successful and easy (intuitive) for people to complete.

20 Apr 2012 - 1:56pm
hassan.schroede...
2009

While all your debate topics are relevant, I'd say they're secondary compared to the worst web form offense: poorly crafted questions.

I can cope with a lot of form vagaries but what's an instant show-stopper is a question I can't answer: not because I don't know the answer, but because you won't let me give you the answer.

"Well, it's complicated... " -- but your form field will only accept 20 characters.

"Select one: " -- but the set of radio buttons doesn't include my answer, or selecting only one would be a lie. Wait, you want me to lie?

(Maybe someone's already expanded this thesis into a collection of anti-patterns, because that's only scratching the surface.)

So, depending on how badly I want whatever is behind this form, I'll either abandon (and probably ignore anything from you in the future) or I'll give you an arbitrary answer for that question and all the questions from that point forward, making you the proud owner of not just invalid but misleading data.

This is unfortunately so prevalent that I now cringe at the sight of any survey, and most forms that ask for other than the most commonplace (address, phone) info.

FWIW,

21 Apr 2012 - 7:01pm
Formulate
2007

Hassan, I couldn't agree with you more. 

Poorly crafted questions are really the big issue when it comes to forms. In an attempt to address the problem I wrote an article for the UPA magazine on how to write good questions, and Jarrett & Gaffney's book deals with the topic in a fair amount of detail. 

But rightly or wrongly, web developers keep having these debates. So I thought I'd attempt to give them some answers, and then finish by delivering the message you deliver here.

Thanks for your comment.

Syndicate content Get the feed