Summary: This post explores why a simple JSON error response stating an “insufficient account balance” does not qualify as a narrative or main story. It’s a necessary distinction for marketers, UX designers, copywriters, and developers who use automated systems. Mistaking raw technical data for communicative content leads to wasted effort and distorted messaging. Let’s clarify the language of systems and how it differs fundamentally from human-centric storytelling.
The Error Is Not the Story
When someone receives a message that reads: {"error": "Insufficient balance", "code": 403}, that person is not looking at a story. They’re looking at an automated response designed to stop a transaction, not to elicit emotion, connection, or engagement. What’s happening here is not narrative—it’s enforcement.
This distinction matters. A narrative has a beginning, middle, and end. It involves conflict, tension, resolution, and ideally, transformation. It appeals to memory, emotion, and identity. An error code does none of these things. So when we hear marketers or product designers trying to “extract the story” from an error like this, we have to ask: What story are you trying to create—and is it the system’s job to provide it?
System messages are guardrails. They stop bad behavior before it breaks things. They exist in binary logic: on or off, allowed or denied. If we turn mechanical feedback into storytelling without context, we project intent where there is none.
Where the Confusion Starts
Too often, marketers or content teams pulling API data or system logs look for messages to “repurpose as content.” It’s easy to conflate structure with meaning. Just because something is organized (like JSON) doesn’t make it a story. Just because it includes real consequences (like denying a transaction) doesn’t make it interesting. And just because it appears in a user-facing part of your product doesn’t mean it’s saying something people want to read.
What’s the danger? Miscommunication, wasted time, and poor UX. If a design team treats system feedback as narrative, they risk inserting ambiguity. The user doesn’t want a paragraph; they want a solution. At that moment, sympathy wastes more time than guidance.
Why This Matters to Marketing and UX
Marketing thrives on story. UX thrives on clarity. These two forces don’t always go hand in hand. A JSON error like “insufficient balance” needs immediate resolution, not empathy. It does not need to be rephrased as “Looks like we couldn’t complete that for you. Maybe check if there’s enough in your account?” That’s too vague, too soft.
Users want clarity in failure. You need to tell them:
- What happened (in plain terms)
- Why it happened (based on inputs they control)
- What to do next (with minimum friction)
Apply this to real-world UX writing. Would you mirror back their frustration, or would you give them control? Saying “It looks like your balance isn’t high enough to process this request. Please add funds to continue” is clearer and more actionable than trying to soften or dress it up. It respects the user’s intelligence. It gives them power without judgment.
The Value of “No” in System Messages
Chris Voss, in Never Split the Difference, points out the power of “No.” It creates space. It gives people permission to pause and regroup. That’s what a system error often does. When the message is clear, users don’t panic; they plan. When it’s ambiguous, they freeze.
So let the “No” be firm. Train your system to be human, but not insecure. Speak plainly. Don’t mask the limits—highlight the next step. If a message stops the action, it should start the solution.
How Good Product Teams Handle Error Content
Smart teams build separation between system logic and user language. Developers write structed messages like "error_code": 402. Content writers interpret that without overwriting it. You don’t repurpose the error message—you contextualize it.
Doing this well requires coordination. Developers describe the boundaries. Writers craft the bridges. The end result should be one clear human-readable message that:
- Matches the system’s declared reason for failure
- Respects the urgency or priority of the user task
- Eliminates ambiguity
If your text doesn’t help the user understand what just happened and what to do next, it doesn’t matter how polite—or how poetic—it sounds. It failed.
No Story? No Problem
Not every message needs to be a story. Stories move people, but not everything people see has to move them emotionally. Some things should just get them moving practically. Systems run that way because humans built them that way—because in failure, clarity is more valuable than charm.
So when you confront content like an “insufficient balance” JSON response, don’t go looking for metaphors. Don’t ask: “What’s the emotional through-line?” It’s not there. Ask instead: “What does the user need next?”—and write for that.
Let the technical content do its job. Your job is to bridge the system’s silence with the user’s needs, not invent a story where there is none.
And if someone insists there must be a story anyway—mirror their own wish back to them: “It sounds like you want to help the message connect better. What outcome are you hoping users will reach faster?” Let them talk. Then bring the conversation back from narrative fluff to functional purpose.
#UXWriting #ErrorMessaging #PlainLanguageMatters #MarketingClarity #UserExperienceDesign #FunctionalContent #DigitalProducts #NoIsPowerful #MarketingThatRespectsBoundaries
More Info — Click HereFeatured Image courtesy of Unsplash and Ilya Semenov (6uFROinaC3g)
