Summary: Not every dataset is a story—and sometimes, what people submit isn’t meant for storytelling in the first place. When you’re handed a JSON response with an error message, particularly one around account balance, you’re not looking at narrative material. You’re looking at a machine warning a human that the math doesn’t work. Parsing this as if it were a novel wastes time, and worse, it ignores the real issue: misalignment between system communication and user expectation.
Error Messages Are Not Content—They’re Warnings
Let’s be direct. Getting a message like { "error": "Insufficient account balance" } is not a story. It’s the digital equivalent of a red warning light in a car: it’s telling you something has gone wrong, specifically that your account can no longer fund a requested action. If you’re trying to generate content or extract a story from that, you’ve misunderstood the purpose of the message. That isn’t failure—it’s feedback. The system is doing its job, and it’s your turn to respond appropriately.
But this raises a better question: Why would someone attempt to repurpose a raw JSON response into a narrative anyway? Is it confusion over what type of input is required? Or perhaps a flaw in how the process was explained to the user? This is an opportunity to teach, not to criticize. Empathy over blame. Curiosity over assumption. So—why do you think someone might confuse a technical output for creative input?
Where Communication Usually Breaks Down
A misstep like this is rarely about the software. It’s usually about expectations that haven’t been aligned. Was the user told, “Paste your text here” when what the system actually needed was a raw story? That’s an interface problem. Was there no confirmation dialog helping them validate their input type? That’s on the onboarding team. Was the error message helpful in redirecting them? Probably not—and that’s where most systems fall flat.
Here’s a better alternative: Create error messages that give direction, not just blockade. Instead of saying “Insufficient balance,” the software could’ve said: “Your account can’t currently process this request due to inadequate balance. To try again, either top up your account or contact support.” Plain, forward-facing, and concerned with the user’s next step instead of just slamming the brakes.
One Message, Several Audiences
Let’s not forget—every error message has at least three potential audiences:
- Developers, who need to see what broke.
- Users, who need to know why their action failed.
- Support teams, who need a trail to diagnose behavior.
If your product is only serving one of these with its error feedback, you’re missing the chance to solve tomorrow’s problem today. Great system design assumes confusion. It prepares for misunderstanding. It builds in clarifiers that real humans actually read—because the design process included actual human thought. You wouldn’t build a bridge without first modeling the traffic it’ll carry. Why would you build a user interface and then be surprised that users don’t behave like engineers?
From JSON Rejection to Business Insight
This misalignment offers a clear business insight: Build outputs that show users you see them. Not just “error,” but empathy. Not just JSON, but meaning. If someone is trying to feed machine-readable text into a tool expecting human prose, then you’re watching a breakdown not of logic—but of language. That’s not a tech problem—it’s a marketing one.
What might that suggest to your product team? Maybe this user misunderstanding is a common one. Maybe this is a signal, not a bug: that your audience wants to tell stories but is stuck in the syntax. What would happen if you made space for raw text and validated input with gentle correction? Would users feel assisted instead of shut down?
Power in a Precise “No”
Let’s bring in clarity from Chris Voss’s playbook: a clean “No” is not the end—it’s a beginning. When your system says “Insufficient balance,” it’s a defensive stance. But it should be an invitation—“No, you can’t do this—and here’s what to do now.” People don’t hate getting rejected—they hate feeling stuck after they’ve been rejected.
What would your system look like if every rejection opened the door to a next step? What if “No” was just the start of an intelligent, respectful negotiation with the user’s intent?
A Better Design Message: Teach As You Block
Your system should never just say “error” and walk away. It should explain. It should invite the user back. Otherwise, that unprocessed JSON message isn’t just a failed input—it’s bad business. People may accept that something doesn’t work. But they’ll remember—often permanently—if they weren’t treated like someone worth explaining things to.
So next time someone tries to extract a story from a system alert, don’t just throw validation flags—offer context. That’s what good marketers do. That’s what good engineers do. That’s what good businesses do.
#UXDesign #ProductMessaging #UserError #SystemFeedback #SoftwareDesign #MarketingClarity #CustomerSupportTools #ErrorHandling
Featured Image courtesy of Unsplash and Markus Spiske (9wTPJmiXk2U)
