UX/UI design / DIJION
How can an error message help users move forward?
Separate input, connection, permission and unconfirmed-operation errors, then explain a safe next step.
“Something went wrong” can be accurate and still leave someone stuck. They cannot tell what changed, whether their input remains or whether retrying is safe. A useful message describes the interrupted task and the next possible action rather than exposing a technical log. The examples below are illustrative; they are not measured results from a released Dijion product.
Classify the failure before writing the message
An empty field and an unavailable server need different responses. Show a correctable input error beside the relevant field. Explain a connection or service failure at the level of the interrupted operation. For a permission denial, explain why access matters and offer a way to continue without it when the feature supports that path.
Treat an unconfirmed outcome as a separate case. A request may reach the server while its response never reaches the phone. Calling that operation a failure and immediately repeating it can create duplicate records or transactions. Describe only what the system can verify.
What happened, what remains and what can happen next?
Build a message around three questions: Which task could not be completed? What part of the person’s work remains? What is the next safe action? You do not need three sentences every time, but the interface should have an answer to each question.
Do not ask someone to correct something they cannot control. Retyping an email address will not repair an unavailable service. A Retry button also needs context: when might another attempt help, and what happens to the existing input?
Eight adaptable examples
Scroll the table horizontally to see all columns.
| Situation | Message | Next step |
|---|---|---|
| Missing field | Enter your name. | Focus the relevant field |
| Invalid email | Enter an email address in the form name@example.com. | Keep the value for correction |
| Short message | Add a little more detail; at least 10 characters are needed. | Continue in the message field |
| Offline submission | You are offline. Your message is still on this screen. | Retry when connected |
| Service failure | The message could not be sent. Your text is still on this screen. | Retry or use another channel |
| Permission denied | Camera permission is needed to add a photo. | Open settings or continue without a photo |
| Rate limit | There have been too many attempts. Please wait a moment. | Retry after waiting |
| Unconfirmed result | We could not confirm that the operation completed. | Check the operation status |
Only say that text remains if it does. Do not call a message Saved when closing the screen will lose it. If the product cannot check operation status, explain the recovery or support route that it actually provides instead of copying a fictional action.
Place the explanation where recovery happens
Field errors should appear as text associated with their labels and inputs. For multiple errors, a short summary with links to affected fields can help. A red border alone hides the reason and makes the problem harder to identify for people who cannot distinguish that color.
On the web, associate visible errors with their inputs and use an appropriate live region for status changes. Native Android and iOS interfaces require their platform accessibility behavior. Web ARIA is not a native mobile API; test the actual flow with a screen reader.
Protect effort during recovery
Keeping input on the current screen is a useful starting point. Persisting a draft to storage is a separate decision, particularly when sensitive information is involved. Consider deletion, visibility and privacy before automatically retaining every field.
Limit repeated activation while a request is pending. Decide whether retries are safe with the server behavior in mind. If an operation is not protected against duplicate execution, do not silently repeat it just to make the interface appear smoother.
A pre-release checklist
- Does the message describe the actual state?
- Is the correctable field identified?
- Can someone understand the error without relying on color?
- Does input remain after a failed attempt?
- Is there a safe verification or support path for an unknown result?
- Do both languages promise the same behavior?
Do more than review screenshots. Disconnect the network, enter invalid values and complete the recovery flow with a screen reader. The words, behavior and next action need to work together.