UX Patterns
Errors alpha

General Rules

Easily-Fixable Errors

If there's an error which can be easily fixed by us with code, we should provide a way to in one click rectify the error.

Writing Style

Refer to our Voice and Tone and Writing Status Messages Guidelines

Submit Buttons

If there's an error, disable the submit button and add a tooltip to the button telling the user telling them why they can't continue. The tooltip should only be visible on hover.

  • If there's only 1 or two errors, the tooltip should state which fields need to be fixed.
  • Otherwise say "Please fix N errors before continuing" in the tooltip

Example

User Input Errors

Demo

Guidelines

  • Only show the error state when a user is finished interacting with a field
  • If possible, do the validation as soon as a user is finished interacting with a field
  • By default, if there's a problem validating the user input, put the example/rule broken in red (example A)
  • Otherwise, state very plainly what went wrong, and if possible provide a way to fix it (example B)

Server Errors

Demo

Guidelines

  • If the error happens as a result of a form submission, we should very plainly tell the user what happend right under the submit button and provide a quick way to rectify the situation
  • If the error happens when the user was not actively using our product, use a Fail Alert Box
  • Otherwise show an Alert Modal

No Permissions

Demo

Guidelines

  • For items where a user could have permissions in one place but not another, we should show the action through the method way we display it if enabled (e.x. only on hover/always visible, etc.), however it should be in the disabled state, with a tooltip saying something to the effect of: "You don't have permission to change this".
  • For items where a user would never have permissions (things like settings), just don't show the action.

Changelog

  • April 3, 2016 - Added rules for no permissions
  • December 9, 2016 - Promoted to Alpha