Technically Correct, Practically Useless.
β Beyond Buzzwords
Published on 22.03.2026
The error message explains the error.
So does the documentation.
Neither gets you any further.
The error appears: “Authentication token expired.”
The UI shows: “Error: Authentication token expired.”
You open the docs. They say: “This error occurs when the authentication token has expired.”
Three stops. The same message. Not once an answer to the one question that matters: Now what?
Passed along, never explained.
The system reports a state. The UI displays it.
The docs describe it. Nobody translates it.
System: “Connection to server lost.”
UI: “Error: Connection to server lost.”
Docs: “This error occurs when no connection to the server can be established.”
System: “Invalid input.”
UI: “Error: Invalid input.”
Docs: “This error occurs when the input does not match the expected format.”
Because nobody in the chain shifts perspective, the developer’s language reaches users unchanged β people who just want to know what to do. Depending on the complexity, that ends in frustration, lost time, or a support ticket nobody needed.
None of that would have happened if someone, at any point in the chain, had stopped to ask:
What do users need to do right now?
The UI could already start that shift β and the documentation can take it further.
Same information, different perspective.
The shift begins with deliberately stepping away from the developer’s view.
Not describing the system β but understanding the user’s situation:
What happened? What do they need now? What’s the next step?
UI and documentation answer these questions at different levels β but both from the same perspective.
System: “Authentication token expired.”
UI: “Your session has expired. Please log in again.”
Docs: “Your session expires after 30 minutes of inactivity. Just log in again β your data will be there waiting.”
System: “Connection to server lost.”
UI: “No connection. Please check your internet connection.”
Docs: “Check your internet connection and try again. If the problem persists, the server may be temporarily unreachable β try again in a few minutes.”
System: “Invalid input.”
UI: “The date must be entered in DD/MM/YYYY format.”
Docs: “Use the format DD/MM/YYYY β for example, 24/03/2026. Spaces and hyphens are not accepted.”
Same information β but this time from the perspective of people who need to know what to do.
The difference is a choice.
Documentation can make up for what the UI missed β but it costs users an extra step. It works better when UI and documentation write from the same perspective from the start.
That requires someone to stop describing the system and start asking:
What do you need right now?
Documentation inherits what was left undone before.
And is, at the same time, the last chance to fix it.