Summary: Not every piece of input is meant to reveal a story. Sometimes, what looks like data is just that—raw, instructive, and mechanical. A plain JSON error message is one such case. It isn’t narrative. It doesn’t hide wisdom waiting to be rephrased. It’s a signal. Understanding the limits of what content can be meaningful for storytelling is just as important as knowing how to squeeze rich insights from a human voice or user behavior.
When Structure Isn’t Substance
The text in question reads like this:
{
"error": {
"code": 402,
"message": "Your account balance is too low to complete this request."
}
}
This is not material from which stories emerge. This is a system message—structured data output, not human experience. Think of it like a stop sign. It’s clear, it’s useful, and it's doing its job. But no one writes a novel around a stop sign. Why? Because it’s not the story—it’s part of the infrastructure. Mistaking it for content is like trying to turn traffic lights into musicals.
The Difference Between Data and Narrative
Marketers, especially in SaaS or fintech, often get carried away trying to make everything a 'content opportunity.' That leads to fluff, speculation, or invented drama just to spin something that was never meant to be spun. This hurts credibility more than it helps visibility. People can smell manufactured engagement. And nothing says "we think you're dumb" louder than dramatizing a routine message meant for system developers or support staff.
Let’s keep this grounded. JSON is Data. Data is raw input. Stories are structured meaning built around desires, decisions, or dilemmas. Where’s the dilemma in line 3 of a system response? What personal transformation hinges on an account balance message? Who's the protagonist? Who's the antagonist? Who changes?
How Marketers Go Wrong Chasing Non-Stories
This mess happens because we often confuse communication with narrative. Not every message deserves a voiceover or brand moment. There’s value in understanding when silence—or simplicity—is more effective.
Here’s where Voss’ method applies. When someone forwards this message asking, “Can you rewrite this into a user-friendly story?”, don’t just say, “Sure!” Instead, use a calibrated question: “What outcome are you hoping to achieve with a rewritten version?” Pause. Let them reflect.
Then mirror the key phrase: “You mentioned you wanted a narrative here. When you say narrative, do you mean a user-focused explanation or a dramatization?” From there, you pivot the conversation into useful territory—maybe they need an error-handling write-up for end-users, or an interface rewrite for UX. But either way, you tactfully help them realize: rewriting data as a story won’t add clarity. It just adds noise.
What You Should Do Instead
Instead of trying to twist these into pseudo-content, ask better questions. Are users seeing these errors without understanding them? Maybe the real job is improving the display language in the UI—not turning backend messages into blog posts. Are engineers the audience? Then clarity and brevity win, not creativity.
This is the Chris Voss “No” in action. You reject a bad idea gracefully, not by shutting the door but by redirecting the energy. You say, “This doesn’t seem like the right place for a story—what’s the bigger issue you’re trying to solve?” People appreciate clarity. And you build authority by showing restraint—by *not* spinning wheels just because someone said “content.”
Respect the Boundaries of Format
Copywriters should have the discipline to recognize when meaning is absent. That’s part of what separates professional writing from idle wordsmithing. A system message tells the truth with zero sugar. It’s a mirror of function. Let it do its job.
Trying to extract a story from a plain JSON error is like opening an ink cartridge and expecting a novel to pour out. It’s not broken—it’s just not what you thought it was. The failure isn’t in the data; it’s in the assumption.
Leverage the Message, Don’t Romanticize It
There’s still utility here. Turn that raw message into better developer documentation, improve error handling procedures, or smarter friction responses for UX. There’s business value—but not in storytelling form. Honor the function. Don’t fake its purpose.
Do you want clarity for the user? Then write like a scaffold, not a symphony. Do you need logs that speak to devs? Then precision beats polish.
Some inputs aren't vehicles for metaphor. They’re checkpoints, protocols, or constraints. They're honest signals that say, “You can’t pass yet.” And sometimes, the best copy respects the silence of a system doing exactly what it was designed to do.
#TechnicalWriting #ErrorMessages #ContentBoundaries #UXCommunication #MarketingDiscipline #SaaSClarity #ChrisVossTactics #MarketingThatRespectsLogic #SoftwareDesignThoughtfulness
Featured Image courtesy of Unsplash and Patrick Martin (UMlT0bviaek)