Theory: Form Guidelines

One challenging aspect of working with enterprise software is the overwhelming amount of data being managed. Generally, the tried and true vehicle for managing this data is the web form.

You see forms all over the place. They are used in a variety of scenarios and contexts, and can range from basic (log in forms) to the absurd (have you ever completed a FAFSA form?).

Specifically, when trying to develop design patterns and guidelines for forms in the past, I've struggled. When should I use two columns? How many fields are too many? Do they deserve their own page, or can I display them in-line? The reality is that, like most design components, it depends on the context and the task at hand.

It's worth noting that I do not believe in "rules" for design. I prefer to establish guidelines (think defaults) for designs, and leave it up to my fellow designers to make their own decisions.

Four or More

One approach currently working for my team can be summed up in one sentence: having four or more fields changes your design.

This is the cut off point where, in my opinion, a form goes from basic to complex. When you're working with fewer than four fields, it's generally less of an issue if you don't group the right fields together, or don't maximize screen real estate.

Naturally, there will be situations where this doesn't work. But just as we design for the majority of users and the tasks they perform, it only makes sense that our guidelines apply to "most of the time" as well.

  1. Use one (1) column when displaying up to three fields
  2. Use two (2) columns when dealing with four or more fields
  3. Larger elements, such as a text area, can span across both columns of a two-column layout
  4. Exception: nearly all forms should wrap underneath to a single column in responsive design mode
  5. Exception: if a form has content to the right or left, and/or vertical space available

If you're still reading, that means your at least willing to hear me out. Which is good, because I'm going to justify this approach.

This form is still considered "basic"...

This form is still considered "basic"...

Simple, right? Now let's see what happens when we add a field, and kick off the Four or More madness!

... and now it's complex.

... and now it's complex.

Let's start with the obvious question: "Is there such a big difference between three and four fields?" Probably not. It's depressing to think of how much time was spent trying to decide on the criteria for this, but at the end of the day, I believe it works, and it just feels right. Here's why:

Any more than three form fields, and you really start pushing a vertical layout. This is usually not optimal for us, as our target resolution is 1024 x 768, and by default, we want to promote a horizontal layout for desktop and tablet.

Also, I knew the guideline had to apply to modals and popups. Our modals are more horizontal in nature, and by default, I don't like using them for anything other than displaying messages or very simple tasks, such as Upload File. However, seeing as how Upload File is the most basic of forms, I thought that could be stretched to include other basic forms.

You can already see the three fields are pushing the modal window's layout towards a more vertical format.

You can already see the three fields are pushing the modal window's layout towards a more vertical format.

Even though we're using wire frame images here, the height of the modal in the above image is very close to our default modal height in our HTML prototype environment, and eventually, in the released product. It just so happened that three fields (plus an action) fit nicely in our default modal, but four would initiate scrolling within the modal.

This also answers the "how do I know when a form needs its own page, and when it can be displayed in a modal, or in-line?" question. Three or less fields, and you, as the designer, might be able to edit records via modal without leaving the current page, Four or more? We're sending you off to a separate page, pal!

As with everything else, there are no hard, fast rules that apply to every possible situation you'll encounter. That's why we use guidelines instead of rules. And there may come a time when we have to revise or completely remove this guideline - if our designs evolve, that's always a possibility, right?

For now, this guideline seems to be working quite well, and the consistency it helps create within our product is rewarding.