I am attempting to redesign an internal form that we use to set up new clients.

I am repositioning the labels on the left hand side of the form elements to being on top of the elements. I think this makes the form flow a lot better while reducing the amount of space it takes up.

Once the user fills out the basic information, a packet is sent to the client requesting the rest of the information we require (a few pages to fill out and some documents we need). This is where I seem to run into trouble as to what the best way to request where and how to send this to the client is.

I know that one of the most important rules when designing a form is to be consistent with your label placements on like items (always on top, or always to the left/right). So I guess my questions basically boil down to:

  • Is it okay to break a design rule if it does not change the flow of the form or the quality of information received (for example, the form becomes confusing)?
  • Is it ever okay to give a form inconsistent label placements like below?

This is what the form would look like if I were to do this.


download bmml source – Wireframes created with Balsamiq Mockups

  • What's the inconsistent placement, the final row? Or just that some fields are multiple column/not full width?
    – Zelda
    Commented Apr 16, 2013 at 15:41
  • @BenBrocka The inconsistency is that the labels for the last two fields are to the left (as in a sentence) rather than being above the input/combobox they are requesting the information for.
    – Kyle
    Commented Apr 16, 2013 at 15:44
  • 1
  • What about additionally having placeholder text? That way the only thing they have to look at is the form they're going to be entering data into.
    – mowwwalker
    Commented Apr 16, 2013 at 18:46
  • If you think about the nature of the label and the input, it makes sense that there are not consistent because it works better with the flow of the form. If you reword the last two labels then apply the same format as the rest of the form would make sense.
    – Michael Lai
    Commented May 10, 2013 at 5:48

3 Answers 3


I think you should be fine as your form is not very long and the users can quickly scan the form to know what details they need to fill in. Labels above input elements generally fail when the form is really long. To quote this article from UX matters

“Matteo’s eyetracking study proved conclusively that placing labels above form fields is optimal in short forms, because they are very closely coupled visually with their fields and users can take in both with a single fixation,” acknowledged Pabini. “I often place labels above fields in dialog boxes and other short forms, especially when asking users to provide familiar data. Plus, when localizing a user interface is necessary, placing labels above fields eliminates the layout problems that can occur when translations result in much longer labels. However, I don’t think placing labels above fields is optimal for long forms. In such a form, there are likely to be group labels above closely related fields. In such an information hierarchy, placing form fields to the left provides a clearer distinction between the two levels of labels.”

I also recommend looking at this article also from UX matters on eye tracking studies performed on label positioning which has this to say about label positioning on the top of the form elements

enter image description here

Placing a label right over its input field permitted users to capture both elements with a single eye movement. Also, if a label indicated data that was very familiar to users—for example, their first name or family name—users did not fixate on the label separately to read it. They were able to view both the label and the input field in the same foveal area; thus eliminating the need for additional fixations and saccades.

That said the article cautions against using bold labels when positioned directly above the input element as highlighted below :

bold labels resulted in an almost sixty-percent increase in saccade time to move from the label to the input field—from 50ms without bold labels to 80ms with bold labels—with no apparent advantage from the more prominent labeling. Bold labels were more difficult for users to read and perceive—probably because there was more visual confusion between the bold text and the heavy adjacent borders of the input fields.

enter image description here

With regards to your last form field which breaks the labelling flow, i recommend highlighting it so that users notice it and are not surprised by the shift in label flow while scanning through the form as shown below


download bmml source – Wireframes created with Balsamiq Mockups

  • Great response with links to good reading (reading them now). Can you elaborate a little more on your last statement? I'm not sure I understand. The packet is the same regardless of how it is sent.
    – Kyle
    Commented Apr 16, 2013 at 15:52
  • @Kyle I've edited the wireframe to reflect your original form.
    – JonW
    Commented Apr 16, 2013 at 15:56
  • @JonW Thank you. I think I understand what he is referring to now.
    – Kyle
    Commented Apr 16, 2013 at 16:05
  • @Kyle I believe what Mervin is referring to is more the highlighting of the fields (i.e. putting the border and background around them) rather than the labels of the fields themselves.
    – JonW
    Commented Apr 16, 2013 at 16:11
  • @JonW Thank you for the clarification. After seeing your update to the wireframe, I thought that as well.
    – Kyle
    Commented Apr 16, 2013 at 16:18

Luke Wroblewski's seminal Web Form Design: Filling in the Blanks on the subject:

I've often been asked if mixing label placement within a form or an application is problematic. After all, there may be cases within a form or an application where you want people to slow down and consider their options, in which case, left-aligned form fields might work best. In other cases, getting people through familiar inputs might steer you toward using right-aligned labels.

I actually haven't seen any conclusive data that mixing label placements within an application doesn't' cause problems; rather, in my experience, context often wins out over consistency. But be sure to tread carefully when using different form layouts in the same application. While people might not be able to remember the differences between forms, they may subconsciously consider applications with many different kinds of forms "hard to use." Unless you have a very good reason to change alignments between forms in the same application, a single layout will mitigate any consistency issues.

Changing label alignments within the same form, however, should really be avoided since it can cloud the clear path to completion people seek.

The general advice above is a great starting point. In your case, by the "book", the answer would seem to be "don't do it". However, I think that this is an edge case where you can argue that the label alignment in question is more usable in the current format even though it "violates" the pattern.

I say this because within the context of the question you are asking the user, the diagram you present puts the form element clearly within the scope of the label. The label and form element read like a sentence, which makes it very clear to the user what is being asked and how to provide their input.

In other words, your placement provides "a clear path to completion" which is the requirement you need to meet.

  • Thank you for the quote and explanation. That was the main reason for my asking this question. As you said, by the book, I shouldn't change. However, when I made a few tests with the inputs above the elements, it just looked very confusing as to what was being asked.
    – Kyle
    Commented Apr 16, 2013 at 15:55
  • If anything the only "rule" I follow is follow the rules except when you don't. In this case, I think your approach makes more sense for the user, and that's all that matters. You could do some usability testing or A/B testing to try to get some numbers and see what the affect is on conversion rates. Commented Apr 16, 2013 at 15:57

A couple of comments on this form layout:

1) If your product is internationalized (or ever will be), using composite strings (i.e., sentence structure) to string form elements together is not good practice. It makes translation much more difficult and costly, and may force a form redesign down the road. You might try restructuring to -

Delivery method for packet setup:

[email, fax]

Email address: (Or alternatively "FAX number", if this field label is conditional)

[entry field]

2) Yes, it IS okay to break your form structure as long as it is a logical grouping and not unfamiliar to users. For instance, "city" and "state" and "zip" often fall as 2 or 3 columns even in a traditional single column form, and that is one of the few exceptions. As you indicated, the flow of fields should be as consistently aligned as possible to cut down on cognitive load.

If you were to drop "Country" down to the next line, and pair it with "Phone", you could use a 2-3 column approach for all the fields after "City".

3) As an aside, you may also want to look into asterisk placement for required fields. Studies have shown that placing asterisks to the left is considerably more usable than placing them to the right of the label or the field.

A few helpful form structuring resources:

Forms that work http://www.formsthatwork.com/Appearance

Label Placement in Forms http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

And then of course there's Luke Wroblewski's "Web Form Design" book, or "Forms that Work" by Jarrett & Gaffney.

  • Thank you for the additional reading. I will definitely look into it. :) Your point #1 is very good regarding internationalization. As I said in my original post, this is an internal utility so internationalization isn't a big concern unless we suddenly move to another country but is definitely something to consider.
    – Kyle
    Commented Apr 16, 2013 at 18:56
  • Got it - I had missed that it was an internal app the first time through. :)
    – Joanna K
    Commented Apr 16, 2013 at 21:35
  • Not a problem. It is still something that should be taken into consideration when designing things like this.
    – Kyle
    Commented Apr 17, 2013 at 12:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.