Summary: When you encounter a technical error like, “Unfortunately, the provided text does not contain a story that can be extracted and rewritten. The text appears to be a JSON response containing an error message related to an insufficient account balance,” it’s tempting to discard it and move on. But inside that bland, robotic phrasing is a sharp signal about how we build—or fail to build—experiences that can be interpreted, understood, and acted upon by real people in real situations. Let’s not waste what’s useful just because it looks boring. Let’s talk about what this kind of message really means for technology design, human communication, and customer trust.
The Misery of Machines That Only Speak to Themselves
When software talks to software, it doesn’t default to storytelling—it defaults to structure. JSON (JavaScript Object Notation) was never meant to sing. It was meant to convey data cleanly between two endpoints. So when you see a JSON error message about insufficient balance, you’re not seeing a failed narrative—you’re seeing a design assumption: “This output is for a developer, not a person.”
But here’s the problem: software is only useful when humans can act on its output. So what happens when that message accidentally lands in front of a user, not an engineer? Confusion. Doubt. Frustration. That breaks trust. If someone sees an error and doesn’t know what to do next, the system has failed—no matter how technically accurate that message may be.
Error Messages Aren’t Just Notifications—They’re Moments of Truth
A thrown error is not just a systems log; it’s a critical part of your user interface. Just because it’s wrapped in JSON doesn’t mean it’s excused from clarity, empathy, or logic. An “insufficient account balance” error is not a failure to process a transaction. It’s a moment where the system says: “We won’t continue because you don’t meet the requirements.” That’s a boundary. And boundaries, when poorly explained, erode commitment.
This is why every error is a chance to reaffirm trust. Not just by pointing to what went wrong, but by guiding the user toward what to do next. If people end up stuck, restarting the app, refreshing the browser, or abandoning the platform altogether, you’ve lost not just a transaction—you’ve broken momentum.
What the JSON Message Really Says About Product-Business Fit
Let’s break down the visible structure:
{
"error": "Insufficient account balance",
"code": "ERR_BALANCE_LOW"
}
This isn’t just a technical message. It tells a story about how the business logic sees the world: It assumes balance must lead transaction. That’s fair as logic—but cold as experience. There’s no warm handoff, no context, no path forward offered. The user might be trying to complete something meaningful—a payment for a loved one, a donation, or a subscription that marks professional growth. Instead, they get shut down by two lines that might as well have been written in Latin.
The Real Cost of Ignoring Empathy in Technical Interfaces
At first glance, a JSON error like this seems purely technical. But behind the scenes, your customer team now has to field support calls. Your product team is losing user confidence. Your marketing team’s carefully built stories are cracking under user disappointment. This is the silent bleed of poor design choices: backlogs, bottlenecks, and brand distrust.
So here’s a question you need to ask every time you build a message, return an error, or block an action: “How does this sentence help the user succeed?” If it doesn’t, fix it. If it points out a problem, offer a bridge. Strategic silence—just like in a Chris Voss negotiation—can be unnerving. But structured silence with empathy? That builds trust. Syntax without empathy does the opposite. It erects a wall where there should be a doorway.
“There’s No Story Here” is a Story in Itself
Our initial prompt says it: “There’s no story that can be extracted and rewritten.” That sentence is already full of assumptions. It assumes stories only come from characters and arcs. But every honest error in a system is a friction point between intent and output. If you hit “Submit” and the system hits “Error,” that’s conflict. That’s plot. What happens next? Do you rage-quit? Call for help? Try again with a workaround?
That’s user behavior. And user behavior is your product’s real-world storyline. To say there’s no narrative in an error is like saying there’s no relationship in a disagreement. There is—but only if you care enough to decode it. Only if you listen.
Fix Your Errors, Not Just the Code
Business owners, developers, product managers—listen up. You’re not handed loyalty just because your code compiles. You earn it when things go wrong and your system responds like a teammate, not a bureaucrat. When a JSON message like this one shows up, trace back:
- Is there a user-facing interface that hides this friction?
- Does the message explain both the problem and the path out?
- Are you using plain language or tribal techno-speak?
- Can your grandma read it and take meaningful action?
And before you say: “But our audience is technical,” remember this—technical people are still people. No one enjoys cryptic feedback when their money, data, or time is at stake. No one thinks “ERR_BALANCE_LOW” makes them feel supported.
Treat Messaging Like Marketing Because It Is
Marketing doesn’t end when the sale is made. It continues in every system touchpoint that supports, informs, or fails the user. You know what marketing really is? Managed perception. If your app or product throws up a dead-end error message, what perception are you curating there? One that says “we don’t care enough to explain ourselves”?
Every touchpoint either continues the promise or contradicts it. Marketing isn’t the billboard. It’s the refund policy, the error message, the loading screen. If their story ends badly, they’ll tell others. Not with a blog post. With one-star reviews.
So What Now?
Start by assuming every system message is a small conversation. Make it helpful, not cold. Make it honest, not vague. Make it directional, not paralyzing. How would you explain the issue to someone standing next to you—without jargon, without hiding anything, and without abandoning them to figure it out for themselves?
And maybe, most importantly, ask: “What story is the user telling themselves right now—and how do I help them write a better next line?”
You’ll know you did it right when they don’t even notice the error—because they already knew what to do next. That’s not just good UX. That’s leadership inside the product.
#UXWriting #ErrorMessages #ProductDesign #HumanCenteredDesign #DigitalTrust #CustomerExperience #SoftwareFailsWell #PlainLanguageForTech #JSONandHumans #EmpathyInTech
Featured Image courtesy of Unsplash and Marija Zaric (AXL7xerPCUU)
