Summary: Not every piece of text holds a story worth rewriting—and sometimes, that’s exactly the point. When working with structured text like a JSON API response, especially one communicating an error, trying to force a story from it misses both the purpose of the format and the business logic behind it. This piece examines a common misconception among content creators and marketers: assuming every string of words must be narrative-ready. We’ll discuss what the JSON message really communicates, why its structure matters, and how to distinguish between data formatting and storytelling opportunities.
What Does the Text Actually Say?
The original text in question reads much like this:
{
"error": {
"code": 402,
"message": "Insufficient account balance."
}
}
No plot, no characters, no moral takeaway—because that’s not what it’s built for. This is a machine-readable error response from an API, specifically one notifying the user or system that the account doesn’t have enough credits to process a request. It’s transactional, not transformational. That distinction matters.
Why You Can’t Rewrite a Non-Story
Trying to conjure a story from it is like trying to explain the history of a country using only its zip codes. There’s no story arc, no protagonist, no human conflict. This isn’t art. It’s infrastructure. And it’s doing its job exactly as intended: efficiently alerting whoever’s on the backend that something needs attention—usually more money in the account or a usage reset.
Now here’s the tension a marketer might feel: “But Joe, can’t we humanize this message somehow?” Sure—you can write an interpretation or create a user flow where error messages are part of a story-driven user interface. But the raw output? It’s not broken. It’s not meant to be pleasant. It’s meant to be precise. It’s not supposed to tell the company’s founding story or bond with users emotionally—it’s supposed to signal a system constraint.
Mirroring the Intent: Function Over Feeling
Let’s mirror what’s happening here: the system ran a process. The user had insufficient balance. The code returned a 402. Each part of this process is meant for clarity and automation.
So what’s the emotional resonance of “insufficient balance”? Uncertainty. Friction. Maybe even embarrassment or fear, if the service is vital. That emotional landscape—that’s fair game in a story. But again: you’d be building a different product around it, not rewriting the API message itself.
In Chris Voss’s terms, this is a moment for calibrated questions like: “What’s making this situation difficult?” Or “How would you handle it in real-time if this affected a paying customer during a checkout experience?” You’re digging into the context, not the code.
The Temptation to Over-Story Everything
Marketers, writers, and even junior developers often fall into the trap of turning technical outputs into brand messaging. Sometimes, the urge comes from trying too hard to build empathy or engagement into areas that demand function and responsibility. But this distracts from solving the actual user problem.
A better question to ask: “What story should the user be told before they encounter this error?” That’s where the opportunity lies—not in rewriting the error message, but in anticipating it. Preventing it. Or making sure that, when it does appear, the framework around it supports understanding and resolution through design, UX copy, and technical flow. Think consistency. Think downstream trust.
Don’t Story-Polish a Design Problem
Trying to stuff personality into this particular error message is like executing a joke during an evacuation drill. Wrong tone, wrong timing, wrong tool. If your balance is low, you don’t want jokes or literary prose—you want clarity, action, and speed.
The API isn’t your brand voice. It’s your brand’s backend. The frontend is where your values, stories, and empathy should show up—before the user ever meets this message. So what story are you telling there? What path are you shaping to minimize user friction? If a user sees this error, it’s not a narrative opportunity—it’s a systems failure, a trigger point for operational design thinking.
From Message to Strategy
Let’s bring this full circle. The JSON message you were given isn’t a shape-shifting myth—it’s a fixed point in a system. But what lives around it can be optimized. Think pre-payment alerts, tier warnings, credits dashboards, or even a proactive chatbot. Those are the touchpoints where human language belongs.
None of this is about neglecting emotion. It’s about placing it where it belongs, where it can move the user forward. Otherwise, you’re not crafting a story—you’re masking a flaw. Stories belong where humans make choices, not where systems make calls.
Conclusion: The plain truth is, you don’t need to force narrative into cold, hard data. Not everything talks. Treat infrastructure for what it is and give your messaging room to breathe elsewhere—along the customer path, in the decisions users face, and in the emotions they carry. Save your storytelling for the moments that benefit from it. Let code be code.
#APIResponses #UXDesign #MarketingWisdom #TechnicalCommunication #ContentStrategy #HumanCenteredDesign #ErrorMessageDesign #ChrisVossNegotiation #ClearMessaging
Featured Image courtesy of Unsplash and Joshua Hoehne (vCO1Frox2j4)
