View source for Set users up for success

[[Category: Design Principles]] 

Setting users up for success means providing an interface that allows users to flow through a process as efficiently and cleanly as possible, even if there are issues or mistakes during the process.

It also means being empathetic and conscious of how a design will make a user feel. Users don't want to make mistakes, they don't want to feel like they made mistakes, and they don't want to feel like they were expected to read the designer's mind.

The [[Principle of Predictive Aiding]] aligns with this principle by pointing out that proactive actions are more effective than reactive actions. In other words, proactively providing users with the information they need to successfully complete a task will reduce the cognitive load of the task and make the task easier to complete than a design that forces the user to react to information or situations they were unable to anticipate.

While the example below is about a specific interaction design, this principle of design starts at the highest architectural level and works its way down to the details. The goal is always to set users up for success - success at their goals, success at their tasks, and success at their microinteractions.


== Three examples of telephone number fields ==


We often prompt people for information that requires specific formatting to be better understood. Dates are one example, telephone numbers are another. In the United States, a telephone number is ten digits, generally formatted with a three-digit area code, three-digit prefix (which used to specify which switch the telephone was connected to), a hyphen to separate the prefix from the line number, and a four-digit line number. Depending on the developer doing the coding and the sophistication of the site, users have often been required to submit not only the telephone number digits, but also the formatting keys (parentheses, etc.) as well. The problem is that not all sites have required the formatting characters, some have disallowed entering them, and the user can't tell what will or won't be required just by looking at an empty text box.&nbsp;


=== Example one: yell a lot. (NOT PREFERRED) ===


For example, if a user is filling out a form and a specific date field is required, a very common (but unfortunate) pattern is to provide the telephone number field with no information about how the data would be formatted, then return an error if the user chooses the wrong format.

!invalid phone number.png!
_An example of an invalid phone number, taken from_ _[Validating Data Using Data Annotation Attributes in ASP.NET MVC|http://www.codeguru.com/csharp/.net/validating-data-using-data-annotation-attributes-in-asp.net-mvc.htm]_ _\-\- because they have a good screenshot.&nbsp;_

When the user has only one formatting error on their page, this design pattern can seem relatively harmless. However, let's say the user accidentally filled out the form with multiple mistakes, or hit the Enter key before completing the form. There's a good chance that the form greeting the user would look a lot more like this: !Validating-data-Figure02.png|border=1!
_An example of an entire invalid form, taken from_&nbsp;_[Validating Data Using Data Annotation Attributes in ASP.NET MVC|http://www.codeguru.com/csharp/.net/validating-data-using-data-annotation-attributes-in-asp.net-mvc.htm]__. Every field in&nbsp;the form is followed by an "Invalid\!" message in bold red text, often with an explanation&nbsp;_{_}point. At the end of the form, a list of every error is repeated to ensure that the user didn't miss seeing one and is suitably furious.&nbsp;_

Obviously, a user who gets a form filled with errors doesn't feel successful, they feel frustrated and annoyed. This frustration and annoyance is compounded by the lack of direction that the initial design provided. How were they to know what a valid URL would look like or the length of a name if we didn't tell them? This design does not set the user up for success.&nbsp;

h3. Example two: guide the user so yelling can be avoided

A better pattern is to provide guidance in the form field or next to it (preferably next to it so the user can access it after they start typing).&nbsp;

!home telephone number with guide.png!
_An example of a telephone number field with guide text directly below to specify the layout of the form. Built from Boomi components._

When we present guidance text, the user still has the opportunity to enter the content incorrectly, but at least we're kind enough to communicate our expectations to them in advance. This sets the user up for success but also still provides a number of different ways they can fail due to the rigidity of the system. The user might rightfully ask "Why am I expected to enter the parentheses? They're not valuable or unique data." Relatively small decisions such as whether the system requires no whitespace around a hyphen or expects a set number of characters may still result in the user receiving an error message, even though the key data the user provided (the actual numbers) are accurate.&nbsp;

This design sets the user up for success, but only if they follow the narrow path that we guide them to using our guidance text.&nbsp;

h3. Example three: make the system smarter (PREFERRED)

The best solution, however, is to make the system smarter so the user doesn't have to read our minds. There are two ways to handle this approach: either accept all formats regardless of what the user enters in, or provide a service that automatically corrects a user's formatting either during or directly after their entering of the information.&nbsp;

If we accept any input that can be parsed to an American phone number, any of the following formats would be accepted without presenting any type of error message to the user:

(610)555-1212

(610)5551212


610-555-1212

610555122

All of these formats are relatively easy to recognize as a telephone number; just strip out anything that's not a number, and if there's a total of 7 characters left, it's a phone number. If it's more or less than 7, then throw a validation error. The user doesn't have to worry about the formatting, the system receives what it needs, and validation messages are only provided when necessary.&nbsp;

The other approach is to provide extra functionality in the field so that as a telephone number is entered, the form field modifies the input to display the formatting characters.&nbsp; !edit on the fly.png!
_An example of a telephone number with an automatic reformatting feature, from_ _[Vanguard.com|http://www.vanguard.com]__. As the user types the characters 610, the field automatically surrounds the area code with parentheses so that the number is formatted correctly._

Once again, the user could still type too many or too few digits, but there's a better chance that when displayed in the normal formatting of a telephone number, the user is less likely to make mistakes. Note that if the user chooses to enter the formatting characters there are no errors thrown, the system simply doesn't "correct" the format.&nbsp;

This design truly sets the user up for success because it expects the user to be, well, human. It allows the user to enter the right information in the format that best fits the user, and makes the system smart enough to decode the user's input and extract the important information. Thus the user has much less of a chance of receiving any error message, the system still receives what it needs, and the changes of a successful interaction are significantly higher.&nbsp;

h2. Conclusion

Whenever possible, the flow and interface of a system should make it easy for users to meet their high, mid-level, or low-level goals without the distractions of having to change their mental model or actions to meet the computer's (expressed or hidden) expectations. They should be properly guided to the right information and process, and they should be given every opportunity to complete their task successfully.&nbsp;

h2. Additional Reading

* [Add Descriptions to Checkout Form Labels (92% Get It Wrong)|https://baymard.com/blog/checkout-form-field-descriptions] by Baymard Institute