Key UX concepts

  • Contextualize error messages

    If possible, always provide contextual error messages below the corresponding control by using the form field error text property. If contextualizing errors isn't possible, such as due to a technical constraint (for example: server-side validation), display a descriptive error message by using the form error text alert property. Server-side validation is invoked on submission, so the alert is located above the submit button in case a retry is required.

  • Make errors discoverable

    In medium to complex forms, it is not uncommon for a user to overlook required fields on the first pass. We recommend keeping the submission button active at all times as a fallback mechanism for validating these required fields. In these scenarios, deactivating the submit button forces them to hunt for their mistake or blocks them from moving forward, leaving the user frustrated and confused. Therefore, providing feedback through error messages invoked on submission is often the most straightforward and clearest approach to validation.

    In the case of very simple forms, such as those with only one or two fields, where the risk of accidentally overlooking a field is close to none, providing validation on submission might be overcomplicating the situation. If deactivating the submission button would make it clearer for the user, this can be an alternative for simple forms. For example, in a delete with additional confirmation modal. When there are very few fields, the risk that the user won't be able to identify which field needs to be completed is much less of a concern.

  • Make errors visible

    When validating on submission, make error states known to the customer. Scroll the top-most error into view, and ensure it has focus. This applies to both client-side and server-side error messages.

  • Be unobtrusive

    Don't interrupt the customer with validation before they're ready. We recommend you delay validation until after a user has entered data, unless the user is in the process of fixing validation errors, in which case you should validate on key press.

Field validation

Initial state

Validate the data after a user submits a form for the first time. Don’t validate before the user submits the form for the first time. On subsequent attempts, validate as the user completes each field.

Create instance

Instance settings

The instance name must contain from 8 to 128 characters. Valid characters are lowercase a-z, 0-9, and – (hyphen).

Validation scenario

  1. The user begins typing data into a form for the first time. Don't validate the data yet.

  2. The user submits the form. Validate the data.

  3. Mark any fields that contain an error, display an error message under each field, and configure the page to scroll to the topmost error. (Don’t display a generic message at the top of the page, such as "Fix all errors on this page.")

  4. The user starts fixing the errors; from this moment on, start validation on every input change.

  5. The user submits the form again. If the errors are fixed, submit the form to the backend. If any errors are still present, repeat this scenario starting with step 2.

  6. After the user submits the corrected form, put the button in a loading state until the response returns from the server. During this time, don't redirect the user to the next page.

  7. For detailed information about how to communicate error and success messages after the form submission, see Create flow or Edit flow.

Create instance

Instance settings

Instance name is required.
The instance name must contain from 8 to 128 characters. Valid characters are lowercase a-z, 0-9, and – (hyphen).

Server-side validation

After data is submitted to the server, server-side validation is triggered in the following conditions:

  • When data can’t be validated on the client-side.

  • In special cases, such as when the server returns an error connected to the resource creation that the user can fix by changing the values in the form. For example, this might happen if a certain type of resource can’t be created in a certain Region. In this scenario, display a global error message below the form, above the form actions using the errorText property on the form component.

Create instance

Instance settings

The instance name must contain from 8 to 128 characters. Valid characters are lowercase a-z, 0-9, and – (hyphen).
EC2 can’t launch the instance because of a permissions problem with your IAM role.

General guidelines

Do

  • Make sure the error messages are visible when launched If there is more than one error, scroll the page so the topmost error is in view.
  • Use inline error text if the error is related to a specific field.
  • Use global alert text if the error is not related to a specific field.

Don't

  • Don't disable the form's submission button. Use the submission button as a fallback mechanism to launch validation error messages.
  • Don't validate before or while a user is entering data; unless the user is in the process of fixing validation errors, in which case you should validate on key press.

Related patterns and components

With the create new resource pattern, users can create new resources.
Ways to communicate specific messages to a user in an interface.
A section of a page that has interactive controls with which a user can submit information to a web server.
With the form field, users can create properly-styled controls in a form.