How We Think About Content Structure While Building JustBlogged

Most posts about building a writing platform turn into a rundown of the tech stack. This one isn't that. Instead, I want to talk about something developers usually skip over: content UX. The invisible structure that decides whether a piece of writing actually gets read, or just gets published.

Why Developers Should Care About Content UX

We're used to thinking about UX in terms of buttons, load times, and responsive layouts. But content UX. How information is structured, paced, and formatted. Is just as much an engineering problem as it is a writing one.

If you've ever built a blog, a docs site, or any tool where users create content, you've already made content UX decisions whether you realized it or not. Every default font size, every character limit, every "are you sure you want to publish?" prompt shapes how people write, not just how they read.

For developers, this matters because bad content UX creates bad content and bad content is a support burden, a retention problem, and eventually a churn problem. A writing tool that makes structure hard will produce walls of text. A tool that makes structure easy will produce content people actually finish reading.

How Writing Tools Influence Publishing Workflows

The tool shapes the output more than most people give it credit for. A few examples of how this plays out:

• Friction changes behavior. If adding a heading takes three clicks, most people won't bother even if they know their post needs one. Reduce the friction, and structure becomes the default instead of the exception.
• Constraints create discipline. A title field with a soft character limit nudges writers toward punchier, clearer headlines instead of vague run-on phrases.
• Defaults are opinions. Whatever formatting option is easiest to reach becomes the one people use most. If your editor defaults to plain paragraphs, that's what most drafts will look like.
• Feedback loops matter. Tools that show writers a live preview, a reading-time estimate, or a readability signal change decisions in real time, not after the fact.

None of this is about forcing a rigid format on writers. It's about making the good choice the easy choice.

Small Implementation Decisions That Improve the Writing Experience

While building JustBlogged, a lot of the improvements that mattered most weren't big features. They were small, almost boring decisions:

1. Auto-suggesting headings as a draft grows. Once a draft crosses a certain length without a heading, we nudge the writer to break it up. Small prompt, big impact on scannability.
2. Keeping the title field visually separate and slightly constrained. This alone pushes people toward writing sharper, more specific titles instead of full sentences.
3. Inline formatting instead of a separate toolbar. Reducing the number of clicks between "having a thought" and "formatting it correctly" keeps writers in flow instead of breaking their focus.
4. Surfacing structure, not just content, in drafts. Showing a lightweight outline of a post's headings while writing helps authors catch when a piece is unbalanced: too much intro, not enough substance, no real conclusion.
5. Treating whitespace as a feature, not an afterthought. Default spacing between paragraphs and sections was tuned specifically so posts don't feel dense on first glance, which is often the real reason readers bounce.

Individually, none of these decisions is impressive. Together, they add up to a meaningfully different writing experience.

Lessons Learned From Building a Platform for Creators

A few things became clear the more we worked on this:

• Writers don't want more options. They want fewer decisions. Every extra formatting choice is a moment where a writer has to stop writing and start deciding. The best tools make good structural decisions on the writer's behalf by default.
• Structure is a reader-facing feature, even though it's authored by the writer. Every heading, every paragraph break, every list is really a UX decision made for someone who hasn't shown up yet.
• Small nudges outperform big rules. We got much better results from gentle suggestions ("this section is getting long") than from hard constraints or rigid templates.
• The best content tools disappear. The goal isn't for writers to notice the tool. It's for them to notice that writing feels easier, without necessarily knowing why.

If there's one takeaway for developers building anything content-related: the code you write doesn't just render content, it shapes what content gets created in the first place. Treat that responsibility with the same care you'd give any other core UX decision.

---

What's a small tooling decision you've made. In a CMS, an editor, or even a README template that ended up having an outsized effect on the quality of what people wrote? Curious to hear how others have approached this.