Summary: A JSON-formatted error message is not storytelling; it’s infrastructure talking back. When a user sees “insufficient balance” on a platform interface, that isn’t plot. That’s a rejection. And while rejection rarely needs rewriting, understanding why it happens—and why some mistakenly try to twist raw system outputs into “content”—needs serious attention for anyone building digital tools, customer experiences, or content strategies. Let’s break this down from both a technical and marketing lens.
What You’re Looking At Is Not a Story
The core confusion starts with a misclassification. Systems that throw JSON (JavaScript Object Notation) errors aren’t telling stories. They’re reporting status. A narrative has characters, conflict, sequence, causality, and emotional stakes. A JSON error like:
{
"error": "Insufficient balance",
"message": "Recharge your account to continue your query"
}
…doesn’t give any of that. It’s declarative and transactional. No mystery, no arc, no intention beyond utility. System messages aren’t narratives. They’re compressed logic meant to surface decisions. Rewriting them as stories doesn’t make them useful—it makes them misleading.
Why People Try to Rewrite It Anyway
There’s a pattern behind why some folks try to “humanize” even raw technical data. It comes from a good place: they want to improve UX, reduce cognitive load, and keep users from feeling lost. But this impulse gets derailed when people forget the purpose of a message is to prompt an action, not tell a tale.
Rather than wrapping technical feedback in a fuzzy blanket of storytelling, it’s better to ask: What’s the minimum meaningful information the user needs? And what’s the clearest way to prompt the next step?
Marketing Mistake: Mislabeling Signals as Stories
If you’re running SaaS products or platforms, this is not just a UX issue; it’s a business survival issue. Misclassifying technical outputs as content wastes your user’s time and erodes trust. Users don’t want poetic error phrasing. They want clarity. Their account is blocked. They need to know:
- What stopped working?
- Why did it stop?
- What must I do now?
Overwriting reality with fluffy language turns serious system communication into theater. And no one buys from a clown when they’re trying to troubleshoot.
The Value of “No” in Technical UX
A blunt system message saying, “You cannot continue this operation,” isn’t bad branding—it’s the start of effective communication. “No” tells the user a line was crossed or a limit was hit. That moment, if misunderstood, can waste hours or money. Clarity gives control.
What if you mirrored the user’s likely reaction instead? Start by acknowledging the disruption. Then offer action. Try something like:
“You've hit your balance limit. This query can't run without funds. Want to recharge or review billing options?”
What does that do? It injects empathy (“you’ve hit”), offers a reason (“can’t run without funds”), and gives power back through choices (“recharge or review”). Not a story—but still respectful. Straightforward. Respectful doesn’t mean ornamental.
Don’t Split the Difference with Machine Logic
Chris Voss taught us: never split the difference. Yet that’s what bad UX does when it dilutes a precise system instruction with ambiguous feel-good text. Imagine a hostage negotiator saying, “You’re kind of surrounded.” That’s how diluted your technical feedback sounds when you call it a ‘narrative.’ Systems are binary. Either it runs, or it doesn’t. Terrible place to be warm and fuzzy.
So how should you handle communication? Ask open-ended questions users can act on.
- “What billing plan fits your usage best?”
- “What’s stopping you from upgrading now?”
- “Would you like help understanding your usage history?”
These keep the user in command. And they foster dialogue—real dialogue—through systems, not despite them.
Empathy Without Pretending It’s Fiction
When people build systems or apps with storytelling frameworks, they think of “the user’s journey.” That’s fine for onboarding sequences or brand copy. But when you get into infrastructure, metrics, and limits, fiction has no place. That’s where systems must speak as systems. Empathy is not deceit. Don’t pretend the error is a surprise twist in a plot. Own it. Deliver it clean and honest. Give the user what they need to act with speed and clarity.
If It’s Infrastructure, Treat It That Way
Developers, UX writers, product managers—everyone needs to align here. Don’t push your content team to “rewrite” system JSONs. That’s wasted labor and leads to miscommunication. Instead, ask yourself: does this message create clarity? Does it reduce friction? Does it respect the user’s time?
And if a marketer comes in trying to turn the error into a plot twist? Ask them exactly what outcome they think they’re driving by doing that. Sit in strategic silence, and force the question to hang. What should this message do? What do you want the user to decide?
Closing Thought: Leave Drama Out of System Messages
Drama belongs in copywriting. In storytell-driven campaigns. In client testimonials. But it never belongs in infrastructure feedback. There is no story in a JSON error message because there is no character arc. Only a signal. Don’t force your systems to wear costumes. Let them speak their logic cleanly, efficiently, and respectfully.
#UXDesign #SystemMessaging #NoIsPower #TechCommunication #UserRespect #ClarityOverCleverness #MarketingTruth #StraightTalkUX
Featured Image courtesy of Unsplash and Ilya Semenov (6uFROinaC3g)
