One of the skills marketing platform engineers need to get very good at is designing editorial experiences.
Not the pixels or the exact design visually speaking, but rather the semantic experience of interacting with the editor. There’s an art to it.
If you work on a marketing platform long enough, you start to realize that the editor is a core part of the product for a large group of people. It’s not the whole thing, but it’s the part most people experience most often. Designers, authors, marketers, PMMs, SEO specialists, ops folks, sometimes even founders. Anyone who touches content ends up living inside the editorial experience in some way.
And importantly, this isn’t your system. It’s the system you’re charged with designing, curating, and maintaining in service of the marketing team.
Their day-to-day relationship with that system shapes how fast they can work, how confident they feel, and how effectively they can focus on the actual work.
You don’t need to be a UX designer to do this well. You do need a deep understanding of how the people using the editorial experience think and operate.
Editorial experience is not just “the UI”
When people talk about editorial UX, it often gets framed around questions like:
- Is it visual or form-based?
- Is it flexible or structured?
- Is it WYSIWYG or field-driven?
Those questions are important but they aren’t complete.
The core question is:
Does the system help someone express intent clearly and predictably?
A strong editorial experience is semantic. It helps people interacting with content answer questions like:
- What kind of thing am I working on?
- What matters here versus what’s optional?
- How will this content behave elsewhere?
- What decisions am I making right now?
When those answers are unclear, teams rely on conventions, Slack messages, Notion docs, and shared context to compensate. When they’re clear, work moves faster with less coordination overhead.
This matters no matter what CMS you’re using. It’s true whether you’re working in:
- A heavily field-based CMS
- A visual, block-based editor
- Something hybrid in between
The technology changes. The problem doesn’t.
In a field-based system, poorly defined structure can lead to bloated models and inconsistent usage. In a visual-first system, unclear semantics lead to fragile layouts and unpredictable outcomes.
In both cases, the job of the marketing platform engineer is to create guardrails that encode intent.
That means thinking carefully about:
- Naming: what words we use for blocks, fields, and sections. (Yes, naming is hard. Worthwhile things usually are.)
- Structure: what’s repeatable, what’s composable, what’s fixed
- Defaults: what happens when someone does nothing
- Constraints: where choices are intentionally limited and why
These are product decisions, even if they’re expressed in code.
Marketing platform engineers aren’t product engineers, but product thinking is valuable when shaping the marketing platform editorial experience.
The shape of a good editorial experience
When I think about designing a strong editorial experience, a few questions always come up:
- What does the setup state look like, and when do we need one?
- What does the editing experience look like once someone is past that initial moment?
- Can people jump straight into editing, using sensible defaults to communicate intent?
- What does the preview state look like, and where does it live?
Each of these moments sets expectations.
A thoughtful setup state orients someone without slowing them down. Defaults communicate intent without requiring explanation. A reliable preview experience builds confidence and trust between the editor and the system.
None of this happens accidentally. It’s the result of deliberate design decisions.
Why this is both taxing and rewarding
Personally, I find this part of the work the most taxing and the most rewarding.
It lives in the space where design intent, marketing goals, technical constraints, and human behavior meet. There’s rarely a single correct answer, and feedback often comes from real usage rather than upfront validation.
But when it starts working, the impact compounds.
People stop asking for exceptions. Designers trust the system. Engineers spend less time handling edge cases. The platform starts to feel aligned with how the team actually works.
That alignment is designed.
Marketing platform engineering is partly about empathy
Marketing platform engineering eventually becomes about understanding people.
Understanding how different roles approach content, where uncertainty shows up, and what the system needs to make obvious.
If you’re building platforms for marketing teams and you’re not designing the editorial experience with this level of care, you’re leaving leverage on the table.
And if you are, you’re doing meaningful product and design work alongside engineering, whether or not your role explicitly names it that way.
Leave a Reply