A practical guide to error handling in product design

A simple guide for designing what happens when the product cannot do what the user asked. This is about making failures clear, protecting the user's work, and giving them a next step instead of a dead end.

By Devendra SinghNotes between me and myself

  1. Error handling always felt like the thing we do at the end.

    Main flow first. Broken cases later.

  2. That is why many products look polished until something fails.

    A checkout screen can be beautiful, then the user taps pay and sees only: Payment failed.

    No reason. No next step. No clear message about money. That is not a small UI problem.

  3. But errors will happen anyway, right?

  4. Yes. The goal is not to remove every failure.

    The goal is to reduce damage when failure happens.

    If payment fails and the user does not know if money was charged, they may leave. If a long form clears after submit, they may not fill it again. If upload fails without retry, they may stop trusting the product.

  5. So where do I start?

  6. Start by listing where the flow can break.

    For signup: empty fields, wrong email, weak password, existing account, slow internet, server issue.

    For checkout: card decline, expired card, wrong OTP, payment timeout, coupon issue, address problem.

    If you do not list them, you will design only the perfect version.

  7. After listing, write the message?

  8. Yes, but write it in normal words.

    Bad: "Invalid input." Better: "Enter a valid email address."

    Bad: "Transaction failed." Better: "Your payment did not go through. Try another card or retry."

    The user should not need to understand the backend.

  9. What makes the message useful?

  10. It says what happened, what changed, and what the user can do next.

    If the email is wrong, take them to the field. If the file is too large, tell the max size. If payment fails, show retry or another payment method.

    Do not only describe the problem. Help the user move.

  11. What about the user's work?

  12. Protect it.

    If a long form fails, keep the typed text. If checkout fails, keep the cart. If upload fails, keep the file name and let them retry. If save fails, keep a draft if possible.

    When people lose work, the error feels bigger than the actual bug.

  13. Should every error sound the same?

  14. No. Match the tone to the cost.

    A missing field can be short: "Enter your name."

    A payment failure needs more care: "Your payment did not go through. You were not charged. Try again or use another method."

    Do not make serious errors cute. Money, account access, and lost work need clarity.

  15. What should I hand off to engineering?

  16. Not just one red message.

    Hand off the failure cases, the copy, the next action, and what should be preserved.

    • What can fail?
    • What should the user see?
    • Can the user retry, edit, undo, save draft, or contact support?
    • What user data should stay on screen?
    • What should happen if the API is slow or down?

  17. So error handling is not decoration.

  18. It is part of the interface.

    Design the happy path. Then design the broken path. List what can fail. Write the message. Add the next action. Protect the user's work. Check it with engineering before handoff.

    A good error state reduces confusion, protects progress, and gives the user a next move.

Back to all notes