Errors occur after someone has taken an action and our product fails. Clear feedback to users increases their trust and engagement in our products.
Guidelines
- Clearly communicate what happened. If we know what happened, tell the customer.
- Represent the highest severity error first, and display errors in descending severity order successively.
- When possible, use proximity to address errors where they occur.
- Always present an action or next step to the user. (Even if it’s to refresh the page, try again at a later time, or contact support)
- Preserve as much of someone’s input as possible.
- Inline field errors
- NotificationBar
- Full page takeovers
- Modals to display your error. Most errors don’t need to prevent someone from interacting with the rest of the page.
- App notifications. Most errors should be displayed when a user encounters them.
- Toasts. These are used as confirmation for when an action has been successful.
Determining error types
What is the scope and impact of an error? Is there something preventing a user from taking action, or a specific screen or feature that is failing?
Error types depend on the degree of user control and the severity of the issue.
Guidance for error patterns
| Level | Guidance | Example |
|---|---|---|
| high severity | Use more of the screen, including full takeover experiences. | Loom.com is down (4) |
| low severity | Use less of the screen; error inline alongside the problem when possible. | A form is incomplete (1) |
| high user control | Provide direct guidance to users about what to do next. | A user is on an unsupported browser (2) |
| low user control | Tell someone why they’re seeing an error and what the next steps are. | A user has tried to view a private video (3) |
Common error types
Incorrect inputs
High user control, Low severity
If someone is trying to submit information inside an input that the system won’t accept, label the element with an error state and provide clear messaging on the appropriate format.
Examples
- Exceeds character count → Showing the character count to the user
- Character symbols not recognized by the input → Show which symbols can be accepted
- Incomplete form → Highlight the fields missing information
- Tell the user the appropriate information format in advance or when relevant.
- Mark required fields as required.
- Use a banner when there are multiple errors in a form.
- Just tell them their input is invalid.
- Call a general page-level error.
Lens components
Permissions restrict content
Low User Control, Low Severity
When someone has tried to access a page or video that is unavailable to them based on their account.
Examples
A Viewer tries to access a video that a Creator set to private
- Tell them that the content is restricted
- Show them which account is currently trying to access content
- Tell them something is “unavailable” (unless for specific security reasons)
Admin/service unavailable
Low User Control, High Severity
When the entire application is unavailable do not display a page with many broken components. Replace the experience with a descriptive message to inform users, and redirect them is necessary.
Examples
- Loom app is down (503)
- Link is broken (401/3)
- Page not found (404)
- Explain what went wrong
- Provide a next step, like troubleshooting, visiting loomstatus.com, or visiting the help center.
- Use generic error copy
Internet connection interrupted
High User Control, Low Severity
We know the issue is on the user’s internet connection.
Examples
- A user records a Loom but gets disconnected before they finish
- A user tries to post a comment, but there’s no connection
- Preserve as much of the user’s input or content as possible
- Reassure them that we will post their content when they’re back online
- Tell them something is “unavailable” (unless for specific security reasons)
Feature fails to load
Low User Control, Low Severity
We can render the rest of the page, but a feature on the page has failed to load. Place the error as close to the source as possible. If possible, provide a next step in the same place.
Examples
Engagement insights fails to load -> Display a message inside the feature
- Offer a local way to reload the feature
- Disable other features unless absolutely necessary
- Crash the entire page
Unsupported browser
High User Control, High Severity
A user tries to use Loom.com on an unsupported web browser.
Examples
For our supported browsers page, we display the user’s current browser version to them. We also map this value into the support button. The support team can efficiently triage a customer’s concern with extra data that our product provides them.
- Be clear about what the user needs to do in order to access Loom.com.
- Link to specific existing support policy.
- Confirm which browser we see them on, and relay this data to support automatically if a user tries to contact them.
- Tell users the site is broken.
Further reading
Troubleshooting as a user
When possible, provide a path forward for a user to begin resolving their problem. Be specific.
Examples
- Include a relevant support article.
- Display an error code that identifies the precise issue.
- Redirect to loomstatus
- Provide a way to contact support.
Note: We have a support team that we love. When redirecting customers to contact support, demonstrate stewardship over our product by including as much information as you can about the error.
For our supported browsers page, we display the user’s current browser version to them. We also map this value into the support button. The support team can efficiently triage a customer’s concern with extra data that our product provides them.
Displaying feedback to the user
Displaying multiple errors
Represent the highest severity error first, and display errors in descending severity order successively.
Here is a list of errors displayed in descending order of severity:
- No connection
- Loom is down
- Issue with a user’s account
- Access is restricted
- Feature fails to render
- Invalid input registered