Summary: When software applications fail to deliver because an account is out of funds, the resulting error responses can seem cold, abrupt, and entirely devoid of human context. A simple message like “error: insufficient account balance” in JSON format isn’t a story—it’s a dead-end. And yet, even in this data-driven wall, there's something important to extract—not a story, but a systemic insight. This post explores what happens when raw machine communication falls flat and what marketers, developers, and system designers can learn from that.
Machines Speak Literally, but People Expect Meaning
“Unfortunately, the text you provided does not contain a story.” That sentence is completely correct but also completely human. It reveals a truth we often overlook in technical systems—humans want to read into everything, even cold error messages. But a JSON response like:
{
"error": {
"code": "INSUFFICIENT_FUNDS",
"message": "Your account balance is too low to complete this transaction."
}
}
…is not a narrative. It’s not designed to be one. It doesn't inform you of what led to the shortfall or what you might do differently. It doesn’t acknowledge your frustration or care if this is the third time the transaction failed. But that disconnect creates a passage worth exploring.
Why Context Is Always Missing from Error Outputs
Machines don't care about how you got here. They point at the now. System responses like these are absolute, and that rigidity gets painful when users expect validation, not verdict. Unfortunately, this behavior is part of how APIs are designed—tight, constraint-driven protocols delivering one-shot stateless feedback. But what does that imply?
It implies that you, the user or developer, must build your own narrative from scratch based on limited clues. That isn’t just inefficient—it’s alienating. And alienation creates resistance. If your users feel stonewalled when things go wrong, how likely are they to trust your system again?
No Story Means No Engagement
Let’s call it what it is—when a system kicks back plain error data without explanation or remediation, it’s a failure of engagement. And engagement isn’t luxury; it’s survival. If your user is denied a sense of agency when facing a problem, they’re cut off emotionally. That’s when churn starts to grow. That’s when frustration builds up stronger than product loyalty.
We often treat error handling as a backend technical problem. But how would your customers describe that JSON message? Confusing? Frustrating? Cold? That reaction is telling. Emotions matter in every frame of the user journey, not just the highlight reel.
How to Turn Dead Data into Something Constructive
So the message says “insufficient account balance.” That’s not useful on its own. But the question is: what could be done to change that?
- Could the system show when the last successful payment was made?
- Could it offer a timeline of upcoming charges?
- Could it suggest ways to reinstate service immediately?
- Could it include a link labeled “Why did this fail?” that leads to guidance, not just form words?
If the system asked better questions, would customers give better answers? What if the message shared a common cause or typical fix? Suddenly, the cold wall becomes a doorway back into the conversation.
Designing Communication That Doesn't Stonewall
Here, we get into the domain of service design. Your API thrown error may be technically correct, but that’s not the same as being useful. Let's reframe this with the help of negotiation techniques.
In Chris Voss' method, silence is powerful. But silence must be strategic—not abandonment. A blank return code or error without color is abandonment. Instead, what if the system treated failed payments the way a skilled negotiator handles objections? What if it mirrored the user’s frustration via interface language?
"This action couldn’t go through. It’s usually because of not enough funds. Maybe your last payment didn’t clear? What happened just before this?"
By asking, by inviting, by mirroring — we reopen the channel. Instead of just saying “no,” we offer the space to explore and fix. That’s what storytelling inside systems should do: not entertain, but engage.
The Cost of Silence Is High
When you say nothing of value in response to a failed action, two things happen: users lose trust, and your service loses opportunities to learn. Every failed transaction carries a reason, a story, maybe even a pattern that could inform design, fraud checks, messaging, or retention workflows.
But those insights vanish if no one is listening. What system do you have for extracting meaning from something “that does not contain a story”? If it were your business, your customer, your conversion at stake—wouldn’t you be more curious about the dead ends?
The Point Isn’t to Write a Story for the Error
You're not rewriting error logs into novels. That’s not the goal. But if your interface is customer-facing, every message—especially failures—is part of the perception stack. A terse JSON fragment saying “balance too low" without highlighting path, fix, timing, or tone... that’s not neutral. It is a disappointment. And disappointment without recovery is defeat.
When people say, “There’s no story here,” what they mean is: “There’s nothing I can do with this.” And when that becomes a pattern, your users stop asking questions altogether. They simply leave.
How Are You Responding to Failure?
Let’s call the error message what it really is: a boundary. And the way you handle boundaries is one of the most persuasive, brand-defining choices you'll make. Do you use it to shut someone out—or draw them closer with clarity and confidence?
If your system, platform, service, or team is content to throw blank JSON messages without a recovery path — what does that say about your commitment to user success? What would it take to make your failure modes teach instead of punish?
Re-read your last error response from the perspective of someone who’s not in control of the backend. Ask: what do they feel reading this? Confusion? Shame? Disbelief?
And then ask the most important question: what do they do next?
Design for that moment. That’s where story starts—not with fantasy, but with friction.
#ErrorDesign #UserExperience #HumanCenteredTech #CXFail #TechWithEmpathy #ServiceDesign #SoftwareCommunication #APIDesign #BlairWarren #ChrisVoss #FailForward #GrowthFromFailure #MarketingClarity #IEEOMethod
Featured Image courtesy of Unsplash and Markus Winkler (-q8MdTL2998)