Making Errors Friendly

Errors happen. Always.
It doesn’t matter how good your code is or how polished your design feels - users will run into errors.
What matters is how those errors feel.

A friendly error can turn a bad moment into trust. A cold or confusing error does the opposite.

The unhelpful error

We’ve all seen this:

<div class="error">
  <p>Error: Something went wrong.</p>
</div>

This is the worst kind. It tells you nothing.
What went wrong? What should I do? Is it my fault?
Users feel stuck, and stuck users often leave.

The better error

Errors should explain, guide, and reassure.

<div class="error">
  <h2>Could not save your changes</h2>
  <p>Please check your internet connection and try again.</p>
  <button type="button">Retry</button>
</div>

This one does a few things right:

• Says what failed.

• Suggests why.

• Offers a way forward.

The user feels seen and supported.

Error design in forms

Forms are where errors happen most. Bad form errors make users angry. Good ones keep them moving.

Bad example

<form>
  <label>Email</label>
  <input type="email" />
  <button>Submit</button>
  <p class="error">Invalid input</p>
</form>

What’s invalid? The user has no clue.

Good example

<form>
  <label>Email</label>
  <input type="email" />
  <button>Submit</button>
  <p class="error">Please enter a valid email address (example@site.com)</p>
</form>

Now the user knows what to fix. Clear, specific, and calm.

Inline vs global errors

Inline errors point directly to the problem.

<label>Password</label>
<input type="password" />
<p class="error">Password must be at least 8 characters</p>

Global errors work better for things like API failures.

<div class="error">
  <p>Could not connect to the server. Please try again later.</p>
</div>

Use both styles where they make sense.

Errors in APIs

Errors aren’t just for users. Developers need friendly errors too.
A bad API error looks like this:

{
  "error": "400 Bad Request"
}

It doesn’t say anything useful.

A good API error is clear and structured:

{
  "error": {
    "code": 400,
    "message": "Missing required field: email",
    "hint": "Send a valid email in the 'email' field."
  }
}

Developers now know exactly what to fix.

404 pages

A 404 page is an error too. But it doesn’t have to feel like failure.

Bad

<h1>404</h1>
<p>Page not found</p>

Good

<h1>We couldn’t find that page</h1>
<p>The link might be broken or the page may have moved.</p>
<a href="/">Go back home</a>

Even better: add a search bar, some popular links, or a playful illustration.
It softens the frustration.

Errors with personality

Errors can even be fun, if the product allows it.

<div class="error">
  <h2>Oops, something broke</h2>
  <p>Don’t worry, it’s not you, it’s us. Try again in a bit.</p>
</div>

Tone matters. Playful errors work for casual apps. For banking or healthcare, keep it professional and calm.

Empty + error = overlap

Sometimes what looks like an empty state is actually an error.
Example: a list that won’t load. Is it empty, or broken?

Make the difference clear:

• Empty: “You don’t have any messages yet.”

• Error: “We couldn’t load your messages. Check your connection.”

Checklist for friendly errors

• Be clear about what went wrong.

• Suggest what to do next.

• Offer a retry if possible.

• Match the tone to the product.

• Put errors where users need them (inline, global, or both).

• For APIs: give helpful, structured error messages.

• Never blame the user.

Final thought

Errors are not the end of the world. They are part of the journey.
A good error message keeps users moving forward instead of shutting them down.

Make errors friendly, and your product will feel more human - even