Working method · Eight-stage workflow
Editorial Product Workflow
From raw evidence to a published experience a team can build, use and improve.
Most editorial web projects begin with a format: a page, a hub, a campaign or an article.
The Editorial Product Workflow begins earlier, with the evidence and the argument.
It connects editorial judgement with experience design and implementation, so the final product is not simply a container for content. It is a structured way for an audience to understand and act on organisational knowledge.
Definition
The Editorial Product Workflow turns distributed evidence into a coherent, implementable and measurable editorial experience.
The workflow
Eight connected stages
The stages are sequential enough to create clarity, but not rigid. New evidence can change the narrative; build constraints can improve the experience design; audience behaviour can restart the whole cycle.
Evidence
What do we actually know?
Gather the research, interviews, customer stories, performance data, market signals and organisational expertise relevant to the problem.
Editorial synthesis
What does the evidence mean together?
Identify patterns, tensions, recurring pressures and gaps. Separate what is merely interesting from what can support a useful argument.
Narrative
What is the central argument?
Define the throughline, supporting themes and evidence hierarchy. Give the organisation a position it can credibly own and extend.
Experience design
How should an audience move through it?
Translate the narrative into an information journey. Decide what people need to understand, explore and do — then shape the wireframe around that journey.
Editorial copy
What does each part need to communicate?
Write the page-level copy, transitions, context and calls to action required to carry the argument through the experience.
Asset mapping
What role does each asset play?
Connect articles, videos, data, case studies, tools and calls to action to the journey. Remove assets that do not advance the narrative or user need.
Web build
Can another team implement the intent?
Turn the editorial specification into a build the web team can execute without reconstructing the strategy from scattered documents and conversations.
Published experience
What do we learn once people use it?
Publish, observe behaviour and collect new audience, search, sales and stakeholder signals. Feed those signals back into the evidence base.
Learning returns to evidence
The published experience creates new signals. Those signals update the Evidence Engine, strengthen the narrative and shape the next iteration.
What changes
From filling a page to designing an editorial product
Content production
- Starts with a requested format
- Treats source material as input for copy
- Design and editorial often develop separately
- Success is attached to the asset
- The project ends at publication
Editorial product design
- Starts with evidence and audience need
- Uses synthesis to establish the argument
- Designs narrative, journey and assets together
- Success is attached to understanding and action
- Publication creates evidence for the next cycle
Implementation package
What the method produces
The web build should not depend on a development team piecing the editorial intent together. The workflow creates a connected specification.
Narrative brief
The central argument, evidence hierarchy and supporting themes.
Experience structure
The audience journey, page logic and wireframe.
Editorial copy deck
Page-level copy, context, transitions and calls to action.
Asset map
The role, location and requirements of every supporting asset.
Build notes
Editorial intent, component behaviour and implementation decisions.
Learning questions
What the published experience needs to reveal next.
When to use it
Useful when the experience carries an argument
- Research needs to become more than a report launch.
- Several stories, videos or data sources need one coherent home.
- A content hub needs an editorial thesis, not just navigation.
- A web team needs a build-ready specification rather than a loose copy document.
- The experience should keep learning after publication.
Do not over-engineer it
Not every article needs an eight-stage process. Use the workflow when multiple evidence sources, assets, audiences or implementation teams create enough complexity to justify designing the editorial experience as a product.
Developed through practice
A method discovered in the work
This workflow began to emerge while moving an evidence-led project beyond articles and into a connected web experience. The pattern was not “write the copy, then hand it over”. It was evidence, synthesis, narrative, experience design and an implementation package that preserved the editorial logic through the build.
That is the point at which content production becomes editorial product design.
The method is documented here so it can be tested, adapted and strengthened through the next project rather than remembered as a one-off process.
The wider system