Summary: A JSON error message isn’t poor storytelling—it’s not storytelling at all. Parsing a system-generated structure as though it once had a narrative thread to unravel is like searching for meaning in static. This post clarifies what to expect when you’re dealing with technical outputs like JSON, what not to waste time doing, and why misreading it can derail your workflow.
Not Every Text Contains a Story
We live in an age where almost everything—error messages, code output, social media blurbs—is expected to carry subtext, plot, or intent. It’s tempting to treat every piece of content as if it’s waiting to whisper hidden meaning to those who’ll listen. But if you’re staring at a JSON response, especially one returning error information about something like accountBalance, I’ll stop you right here:
This is not literature. It’s not storytelling. It’s a functional object—structured data meant exclusively for machines (and, by extension, developers). Trying to “extract a story” from this type of content misunderstands its purpose and misdirects human attention. That’s not pedantic—it’s protective. Wasting cycles “interpreting” it as something it’s not leads to poor decisions and lost time.
Know What You’re Looking At
Take a typical error-laden JSON object. Usually, it comprises key-value pairs like:
{
"error": true,
"code": 403,
"message": "Insufficient account balance."
}
Nothing in this text wants to be interpreted metaphorically. It’s not a character in a drama. It’s closer to a traffic light than a Shakespearean soliloquy—a simple signal telling you to stop, troubleshoot, and course-correct. So, what happens when people treat this object like a story?
You get confusion. You get someone wasting mental effort trying to rewrite this “plotline” into a user-friendly message—for whom? The message is already direct: the account doesn’t have enough credit to proceed. That’s the actual value.
The Role of Text in JSON
In software systems, JSON (JavaScript Object Notation) lets systems talk to each other. The “text” inside a JSON body isn’t literary. It’s meant to be parsed, not emoted. Its structure is function-first and human-optional. Reading a JSON response expecting a story arc is like using a voltmeter to decipher poetry—it’s the wrong tool for the wrong task.
Now, this doesn’t mean JSON has no value. Quite the opposite—its precision and rigidity are what make it useful. Think about Chris Voss’ negotiation principle of calibrated questions. You don’t ask, “What’s the story here?” but instead ask, “What does this tell me about the system’s condition?” That’s actionable. That moves the needle.
Where the Confusion Starts
The real issue emerges when non-technical users encounter system responses without translation. Yes, a plain-language explainer might help them, but only if it comes from someone who’s asked, “What are they feeling when they see this?” That’s where Blair Warren’s lens becomes relevant: people want to feel smart, not stupid. So don’t just throw raw JSON at them. Translate it—but don’t fabricate a story that isn’t there.
If failure happens—say, a user can’t complete a transaction—that doesn’t mean the error message carries the blame. It means the interface failed to interpret a machine-readable response into a human-readable explanation. That’s the actual failing. But let’s not confuse a badly translated interface with a “narrative failure.” That’s just misframing the problem.
The Discipline of Staying Literal
Literal thinking has its place—especially in technical environments. Cialdini would call this “Authority.” When software talks through JSON, it’s not your job to add a plot twist. It’s your job to confirm the structure is valid, the message is honest, and the next steps are operative. Validate the object. Catch the error. Point to resolution. That’s it.
If you’ve done that, you’ve done your job. Anything beyond that—particularly narrative-fluff—is energy wasted and clarity lost. I don’t care how creative your copywriting skills are. You don’t decorate a wrench with glitter glue. You use it to fix a bolt.
Empathy is Not Decoration—It’s Translation
Still, many users aren’t developers and don’t speak JSON. These users aren’t dumb—they’re just outside the language zone. Here’s where empathy actually matters—not by inventing a story, but by translating meaning without drama. Doing what Voss teaches: labeling the emotion behind confusion, then offering a way out.
“It looks like the system blocked your transaction because your account balance isn’t high enough to cover it. What are you trying to do next?” Boom. That opens a conversation. No story. But plenty of structure with room for intent, options, action.
Conclusion Isn’t Closure—It’s Choice
So, no—you can’t extract a “main story” from a technical JSON message. But you can respect it, interpret it accurately, and use it to ground decision-making. That’s grown-up thinking. That’s efficient. And that’s the only way these systems work at scale without devolving into chaos or confusion.
Let your interfaces interpret for the end-user. Let your writing clarify what the machines mean. But let’s agree once and for all: JSON error messages were never meant to be rewritten like fairy tales. They weren’t written as stories in the first place.
#JSONErrors #TechnicalClarity #LiteralThinking #SoftwareCommunication #UXMatters #NoStoryJustStructure #ErrorHandling #DeveloperTools
Featured Image courtesy of Unsplash and Mamur Saitbaev (r-BTa--K93U)
