Motion

Motion should occur in the primary available axis. The field in error should expand downward to accommodate the new information, and all other items below it—including the field now in focus—should slide down the page.

My static examples don’t show motion. If indications of errors appear instantly, they won’t be as visible. On the other hand, shifting items about on a page might be confusing and cause users to lose their place.

Instead, motion should occur in the primary available axis. The field in error should expand downward to accommodate the new information, and all other items below it—including the field now in focus—should slide down the page. This ensures users are aware that a change has happened, so they tend to reconsider the entire page and immediately notice the field that is in error.

Animations should usually take between 200 and 300 milliseconds, but their duration depends on the amount of movement that must occur.

Moving the Focus to the Next Field

It is difficult to discuss requirements for error messaging without coming back to overall form design. Here we encounter another requirement: The cleanest way to initiate inline validation is for the user to move the focus to another field, so don’t place a field that is likely to cause errors last in a form.

Once a user fills in the last field in a form, the user is likely to proceed immediately to the Submit button, regardless of whether the last field is likely to cause errors—for example, a password field. While you can still do inline validation in such a case, error correction will not have the same degree of seamlessness and will be more intrusive. Users may have greater difficulty noticing error messages, and they can correct issues only by reading the messages.

Plan your overall form design to work well and make sense regardless of whether users make errors.

Grouping Related Fields

If you’ve grouped a set of fields to order the entry of data, it may be more helpful to highlight and provide hint text for the entire group rather than for individual fields.

If you’ve grouped a set of fields to order the entry of data, it may be more helpful to highlight and provide hint text for the entire group rather than for individual fields. Think of multipart phone-number fields or address groups in which Street address, City, State, Country, and Postal code are individual fields.

Not only is it sometimes hard to refer to a specific field in a group, users often conceive of the group as a single entity. In addition, errors may be the result of tabbing incorrectly or filling in fields out of order. Making corrections to just one field may not make sense, and multiple errors may conflict with each other or add confusion as a user attempts to interpret the actual error.

Also, think carefully about when you actually need to provide separate fields. Not doing so can be especially helpful in solving user-interface design issues in international products. I have gotten along pretty well with single fields for phone numbers and even for addresses. Add parsing rules that trigger on submission and check what a user has entered, then add the data to the database as appropriate.

Providing Hint Text

Place any hint text below fields. Then, you can overwrite the hint text with error messages and economize on their use of space.

You didn't put your hint text—which tells users the rules for providing a value for a field—inside the field, did you? If you did, users can’t see the hint text once they’ve filled in the field. Instead, place any hint text below fields. Then, you can overwrite the hint text with error messages and economize on their use of space. But make sure that you restate any information users need to be aware of to correct an error condition in the error messages.

While we’re talking about the placement of hint text, the need for error correction is why you should never place field labels in fields either, as Figure 4 shows. While there are a few cases in which this can work, don’t let your quest for clean design or using space more efficiently get out of hand.

Figure 4 —The placement of field labels

My recommendations for the design of Web forms for the desktop deviate from or perhaps supplement Luke’s by suggesting that you can highlight the applicable parts of the hint text to communicate an error. Password fields provide a good example:

Must be between 7 and 20 characters.

Cannot be your phone number, account number , or Social Security Number.

phone number, , or Social Security Number. Cannot comprise only numbers.

Cannot contain any spaces or characters that are not on the keyboard.

While this works for the desktop Web, using bulleted lists for hint text is clearly space intensive—even without considering their use to communicate errors. For compactness, hint text on mobile devices tends to be in a sentence format, as shown in Figure 5.

Figure 5 —Hint text on a mobile device

However, as you can see, it is still possible to highlight parts of the hint text in the same way. Do everything you can to make the words stand out. In Figure 5, I’ve used not just color, but two style changes—the error text is bold and is not italicized.

Also, remember that, by using the right input widget for fields, you may obviate the need for hint text. For example, if a field allows only numeric input, there may be no need to say numbers only.

Setting User Expectations

When designing mobile forms, always communicate what users need to do and directly assist them in accomplishing their goals whenever possible.

Be sure to set user expectations—both when first presenting a form and for each change or additional component. Introductory copy may follow some of these guidelines, but it must often adhere to marketing requirements, so I am not going to talk about this specifically.

Avoiding Errors

If a user cannot submit a form until it is valid, there’s no need for an intrusive error message.

I don’t claim to have invented this whole approach of inline validation, but the way I arrived at it during design may be enlightening.

My ultimate and achievable goal for designing Help systems is not to design them at all. But to make Help systems unnecessary, users must understand how a product works. Similarly, my goal for forms is to prevent all errors. But so far, I’ve never quite gotten there. There’s always at least the chance of a system outage. Nevertheless, this is a design objective that should drive your decisions.

The first thing I do when sketching a design—or scribbling over an existing screen to revise it—is to make the Submit button initially unavailable, as shown in Figure 6. Simply giving the button a dimmed appearance sets user expectations, and including hint text that explains why the button is not available prevents user confusion. If a user cannot submit a form until it is valid, there’s no need for an intrusive error message. Using inline validation and following the guidelines I’ve outlined so far supports this goal.

Figure 6 —Initially making the Submit button unavailable prevents errors

Figure 7 —Messaging when some fields are in error

Once users have made errors, display the same error icon that you’ve used for inline validation—or, if not applicable, a similar one—to the left of the hint text and the unavailable Submit button, and change the hint text to an error message, stating specifically that the user must correct the errors before submitting the form.

Figure 8 —Messaging that appears once the Submit button is available

Once the form is ready to submit—whether because a user has completed all required fields or corrected all errors—the Submit button becomes available, indicating that the form is complete.

If you have a sufficiently long form, especially when many fields are optional, you may want to add another Submit button at the top of the page, which is fine. Just make sure every instance of the Submit button conforms to the proper state, as I’ve described, and appears with the appropriate messaging. Both buttons should become available at the same time.

Using Application Buttons

The iOS Human Interface Guidelines suggest that designers place buttons on an application’s title bar. A lot of apps don’t follow this guideline, but native apps usually do, and so should you. You may already have noted that the behavior of giving a button a dimmed appearance until it is flagged as having a valid state is built in.

Of course, there really isn’t room for adding any commentary next to OS buttons that are unavailable, so that’s probably out. Android gives somewhat more room for placing and styling a button as you want, but also incorporates the behavior of making a button unavailable when form data is not acceptable.

It is my expectation that making Submit buttons unavailable until a form is complete will train users to expect forms to provide implicit validation and prevent errors on submission. In fact, we may soon be able to set aside the common practice of using static buttons that too many developers still espouse, and move universally to using the dynamic buttons of mobile devices.

I hope that, in just another year or two, we can get by with much less annotation of errors, and explanations of why a Submit button doesn’t currently work won’t any longer be required.

Exceptions: When Inline Validation Is Not Enough

Sometimes, you simply cannot check a value inline. In such cases, users must submit the form, then view the errors once the screen has refreshed.

There are, of course, exceptions to all guidelines. Sometimes, you simply cannot check a value inline. In such cases, users must submit the form, then view the errors once the screen has refreshed. This need may arise because of technical constraints or for security purposes such as authentication. Or a two-tier system may be necessary, where you can do inline validation to check that values have met basic constraints—for example, are in the proper format—but the actual validity of the form requires submission. Do not give in too easily to such technical constraints.

In any case, when redisplaying the form with errors, you should follow all of the guidelines I’ve presented in this column. Display a summary of the errors above the form, note errors for individual fields, and again make the Submit button unavailable, as shown in Figure 9. However, if it’s still impossible to detect whether a particular value is valid, make the Submit button available as soon as the user changes the field in any way.

Figure 9 —Displaying errors detected on the submission of a form

If submitting a form generates errors, be sure to provide an error message beneath the page title that informs the user what has happened. (Depending on your standards for contextual titling, the page title may or may not change.). The error message should comprise an error icon—similar to the field error icons—and a clear message that indicates the form has errors.

If a form is too long to fit in the viewport without scrolling, in either orientation, some fields won’t be visible when the form loads. In this case, a list of the fields that are in error should follow the error message. On the desktop, I’ve always gotten good results from indicating the field and the error. However, on mobile devices there simply isn’t room to do this without the whole viewport’s displaying nothing but an error message, so just list the fields. Use the fields’ actual labels in the error message, so users don’t have to interpret that Phone means Your phone number when scanning the form to find the fields that are in error.

Inline Saves

You should automatically save the data that users provide, field by field. In this way, you can eliminate any worries about session timeouts or loss of connectivity.

The unique constraints of mobile devices include their small size and the relative difficulty of inputting data, but more importantly, issues regarding distractions and connectivity. Users may become distracted by notifications on their device or happenings in the real world. When users are on the move, they may lose network connectivity. You must prevent users’ losing their data in both of these cases.

Similar to the way you check data inline, you should automatically save the data that users provide, field by field. In this way, you can eliminate any worries about session timeouts or loss of connectivity. Once users get back online and return to a form, the system should ensure that their information is still there, so users can resume their work without any problems.

Native mobile apps can easily be built to resume in the same state after they are suspended or even quit. Hybrid apps and the Web provide additional technical challenges, but can also be built to support this concept. Users are becoming accustomed to task switching, so may be annoyed if they lose their data as a result.

Technical or security concerns can also come into play. In a registration form, for example, a system generally reserves user names after a valid inline check. But if a user doesn’t complete a registration form, the system should not hold the user name forever. Decide whether you should save reserved user names for an hour, a day, or a week. You should consider setting other limits to prevent excessive use of resources for session preservation, as well. Discuss implementation strategies early on to ensure your design principles present no issues and, if necessary, modify them to yield the best overall product.

Because of the variations in products and platforms, there can be no hard-and-fast rules, just guidelines. Even with technical issues set aside, an implementation depends on the needs, goals, and capabilities of the underlying business processes and systems, as well as your user interface design.

And there may, of course, be exceptions. For example, I generally insist that users be able to enter passwords without masking. This is perfectly safe in most scenarios, but do ensure that passwords get wiped if users leave a page—even though the page should retain other data that they’ve provided.

Using Analytics

Gathering analytics data is a great thing, which I encourage. But following rules too strictly or using excessive, out-of-the-box implementations can lead to a page-centric mentality, which assumes that every condition—including error and success states—must be a page, so it can be tracked as a unique object. This is a greater problem for the Web or when applications use Web-centric implementations.

Specific workarounds depend on your system, but be aware that these are not strict limits. They can be somewhat flexible. For example, some major tools require that there should be only one instance of a clear pixel or tracking pixel per page. But it’s all about how the analysis server processes the data, so it’s possible to either tag states differently and run reports on state changes or just report total pages viewed. Analytics experts can work with you to implement good designs if you explain your reasons for a design.

Error-Free Forms

Lazy registration … can make a registration form optional and prevent data-entry error for almost every field.

In practice, I use the principles of inline validation when designing perhaps half to two-thirds of the forms I work on. For the rest, I have a free enough reign to apply the even more stringent standards of error-free forms. Figure 10 shows a good example that is not yet in production. I’ve sanitized it a bit because it’s still in stealth-startup mode.

Figure 10 —An error-free form

(In this design, I’m experimenting with using iconography for field labels, then letting the hint text get overwritten. I know. I said not to do that earlier. But, this is just one example, and experimentation is how we learn.)

In Figure 10, the form fields are for keyword search, a location constraint, and a price constraint. If a user skips the keyword search field, tapping Show my results loads all search results—by default, in order by recency. Location is generally prepopulated, but can be vague, and a user can overwrite or clear the location. If a user provides no information, a search displays all results for all keywords, at all prices, everywhere. (It is, of course, easy to eliminate price as a constraint. And it turned out to be easy to make sure that none of the fields are required.) In this case, the results are simply a list of recent activity. Displaying this list was already a requirement, and it’s not difficult to search the database for recent activity.

You may think your registration form could not be this easy. But why not? Lazy registration—gathering one or two pieces of information at a time, as people use your product—can make a registration form optional and prevent data-entry error for almost every field. This is also an excellent way to ensure that automatically saved data is put to good use. If users don’t complete a form after a certain amount of time, remind them to come back and finish it.

As a general rule, you can solve technical constraints by using different technology, business constraints by changing business rules, and even change your design practices a bit. However, users won’t change their behavior for a single unique form. Do whatever you can to make sure you are building user interfaces and interactions for people.