A CMS Prototype Is Only Half the Implementation Story
A polished website prototype can create a dangerous feeling of certainty.
The homepage looks convincing. Product cards exist. Blog, recipe, event, and product templates have been designed. The component library contains reusable patterns. Stakeholders can click through the experience and understand the intended direction.
It feels as though the project has moved beyond planning and is ready for development.
A prototype usually answers only one part of the implementation question, though:
What should the website look and feel like?
It rarely answers the full set of questions required to build a maintainable content platform:
Where does each piece of information come from?
Which fields can editors change?
Which structures must remain locked in code?
Which content belongs in the CMS?
Which data belongs in another system?
What happens when content is missing?
Who can create, review, approve, and publish it?
Which variations are required?
What happens on mobile?
What happens in every loading, empty, error, expired, unpublished, or unavailable state?
Which ideas are confirmed launch requirements, and which are still exploratory?
A prototype earns its value by establishing design direction, testing user journeys, revealing reusable components, and helping stakeholders discuss the future website, well short of serving as an implementation specification.
Treating it as one forces developers to fill every missing decision with an assumption. Those assumptions then become schemas, APIs, component contracts, permissions, migration scripts, and production behaviour.
By the time the original ambiguity becomes visible, the team is already paying for it in rework.
What a prototype actually proves
A good prototype can confirm several important things.
It can show the intended visual hierarchy, page composition, interaction direction, brand character, content density, navigation model, and general relationship between different page types.
It can also reveal useful reusable patterns.
A multi-brand health and wellness platform we recently reviewed already had directional designs for:
product cards
recipe cards
blog cards
event cards
resource cards
store cards
product detail pages
article templates
recipe templates
event templates
homepage marketing sections
health-goal and ingredient visual systems
That was valuable work. It showed that the future platform could be built from a coherent, reusable frontend design system rather than assembled from unrelated one-off pages.
That library already contained the beginning of a reusable frontend design system, even though it hadn't yet confirmed the production contract behind those components.
A product card might visually contain an image, product name, category, short description, badges, and a call to action.
That does not tell the implementation team:
whether the product name comes from the CMS or a product information system
whether the image must come from an approved DAM
whether editors can override the image
whether badges are manually selected or derived from product data
what happens when a product is unavailable in one region
whether the short description is localized
whether the entire card is clickable
whether the call to action changes by website, locale, or product status
whether product cards support multiple visual variants
whether editors can manually select products or only define filtering rules
whether product information has already passed regulatory approval
what tracking event should fire when the card is clicked
how the card behaves when required data is missing
The component can be visually complete while its implementation contract remains mostly undefined.
Design intent, component design, CMS design, and implementation are different layers
Many projects collapse four separate layers into one.
1. Design intent
Design intent describes the experience the team wants to create.
It answers questions such as:
What should receive visual emphasis?
How should the brand feel?
What should the user notice first?
How should content be grouped?
Which journeys should feel simple?
Which page types should look related?
Figma prototypes are effective at communicating this layer.
2. Component design
Component design turns repeated visual patterns into reusable frontend units.
It defines things such as:
product card variants
article card variants
hero layouts
banner styles
content sections
navigation patterns
responsive rules
spacing and typography systems
visual states
Storybook can be useful here because it isolates components and shows their supported variants, though a reusable React component still doesn't automatically define a reusable CMS structure.
A frontend component may accept a loose object containing a heading, text, image, link, and presentation options, without editors necessarily getting unrestricted control over every one of those properties.
3. CMS and content design
CMS design defines how editors create, connect, review, and publish the information shown by those components.
It answers different questions:
Is this a collection, global, block, relationship, or configuration?
Which fields are required?
Which fields are localized?
Which values are derived automatically?
Which values can be overridden?
Which content types can use this component?
Which roles can edit it?
Does it require approval?
Can it be scheduled?
Does it reference a product, person, asset, category, or campaign?
What validation rules protect the frontend?
How should existing content migrate into the structure?
Payload configuration belongs primarily to this layer.
4. Production implementation
The implementation specification connects all previous layers and defines how the system must behave.
It must cover:
frontend behaviour
CMS schemas
external integrations
permissions
workflows
localization
accessibility
analytics
responsive behaviour
empty and error states
migration rules
performance constraints
acceptance criteria
launch scope
future scope
A prototype contributes to the specification without replacing it.
The prototype shows one successful state
Most prototypes show the website under ideal conditions.
The image exists. The title fits. The description has the expected length. The product is available. The event is upcoming. The article has an author. The translation is complete. The external API responds successfully.
Production systems must also handle everything around that ideal state.
Consider an event card.
The prototype may show a date, title, image, location, and registration button.
The specification must decide what happens when:
the event has no image
the event is online rather than physical
registration happens through an external community platform
registration happens through Zoom
registration is handled directly by the new website
the event has reached capacity
registration has closed
the event has been cancelled
the event date has passed
a replay is available
the French translation is not complete
the event belongs to one brand but appears on another site
the registration provider is temporarily unavailable
These details determine the content model, integration boundaries, component states, editor fields, automated status changes, and testing requirements.
The prototype represents an example, while the specification defines the system behind it.
Visual flexibility isn't the same as editorial flexibility
One of the most important questions in a CMS project is deciding which parts of the design should become configurable.
A prototype may include a homepage made from several visually distinct sections. It's easy to conclude that every section should become a CMS block editors can reorder freely, though the actual requirement is often much narrower:
the homepage hero remains fixed
marketing can update a rotating banner
featured products can be selected
approved marketing sections can be enabled or disabled
editors can change copy, assets, links, and scheduling
the overall layout and interaction model remain controlled in code
This still gives marketing useful autonomy without turning the homepage into an unrestricted visual page builder.
The distinction matters because every configurable property becomes part of the product.
Supporting section reordering requires more than a drag-and-drop field in the CMS: it also requires the design and development teams to confirm that every permitted section works correctly before and after every other permitted section.
The system must handle spacing, background transitions, repeated calls to action, duplicate headings, incompatible combinations, mobile behaviour, accessibility landmarks, and visual rhythm.
A prototype may show five sections in one carefully designed order, though that doesn't prove all 120 possible combinations are valid.
A visible component may hide several systems
Modern websites rarely own all the information they display.
A product page may combine:
product data from a PIM
website-specific content from Payload
approved assets from a DAM
inventory information from an operational system
store availability from a locator service
reviews from a review platform
lead capture through a CRM
related articles and recipes from the CMS
analytics and personalization from separate services
The prototype can present this as one cohesive page, while the implementation specification has to define the boundary between every system behind it.
For each section, the team needs to identify:
the source of truth
the direction of data flow
whether data is fetched, synchronized, referenced, or duplicated
whether editors can override it
what happens when the source is unavailable
whether the content requires another approval
how frequently it updates
how it is cached
whether it differs by locale, brand, region, or environment
Without these decisions, the easiest development path often wins.
That can result in product data being copied into the CMS because it is convenient, approved assets being uploaded again because the DAM integration is not ready, or external form pages continuing to control the website experience because nobody defined a cleaner boundary.
The website may match the prototype while the architecture quietly becomes harder to govern.
Deciding whether something is a template, block, collection, or integration
A page visible in a prototype can be implemented in several very different ways.
A giveaway page could be:
a generic page assembled from blocks
a fixed giveaway template
a dedicated Giveaways collection
a campaign record connected to a form
a manually edited page with duplicated contest rules
a frontend route powered by an external contest platform
All six could look almost identical, even though only some of them would actually support the operational requirement.
When giveaways happen repeatedly, a dedicated structured collection may be more appropriate. The record could contain the prize, products, eligibility, start date, end date, rules, form configuration, winner announcement, campaign tracking, and archive status.
One structured record can then populate the landing page, contest rules, campaign listings, scheduled activation, expiry behaviour, and archive.
The prototype shows the giveaway page, while the specification identifies the giveaway as a repeatable business process.
This is why page-by-page implementation is often misleading. What appears to be a page may actually need to become a content type, workflow, integration, or reusable domain model.
The difference becomes expensive during migration
When a prototype is treated as a specification, migration planning often begins too late.
The development team builds the new templates first. Only afterward does someone inspect the existing WordPress content and discover that:
articles use several incompatible field structures
product references are embedded inside rich text
recipes contain inconsistent ingredient formats
microsites use one-off page-builder layouts
some event registrations point to external tools
lead magnets are hosted through CRM-generated pages
important files are linked from public cloud storage
metadata and URLs vary across sites
older pages contain functionality not represented in the prototype
At that point the new design may not have a destination for everything that already exists.
A proper specification connects the future design to the current content before implementation is locked.
For every existing page type and capability, the team should know whether it will become:
a Payload collection
a fixed template
a reusable block
an external integration
an unchanged external platform
a manually rebuilt experience
a retired page
a redirected URL
a later implementation phase
This coverage map is part of the implementation specification. The prototype can't provide it on its own — it describes the proposed experience, and the migration responsibility sits elsewhere.
Backlog ideas must not silently become launch scope
Prototypes frequently contain a mixture of confirmed requirements, designer proposals, stakeholder suggestions, and future ideas.
They may all look equally real once they appear on screen.
A designer may include:
product reviews
a nearby-store widget
configurable product FAQs
a custom event landing page
social media promotion
enhanced product storytelling
a locale selector
a saved-items feature
Some may be approved launch requirements. Some may be useful concepts. Some may depend on systems that do not yet exist. Some may have been mentioned once and never validated.
The implementation specification must label them clearly.
A practical classification is:
confirmed launch scope
confirmed future phase
exploratory design direction
integration-dependent
awaiting stakeholder decision
excluded
Without this classification, estimates become unreliable.
Developers either build everything visible in the prototype, or they omit features that stakeholders assumed were included because they had already seen them demonstrated.
Both outcomes create conflict that a better specification could have prevented.
Storybook documents components, the CMS documents content
Storybook is valuable because it can document reusable frontend components, their props, and their visual states.
It can help answer:
Which card types exist?
Which variants are supported?
What happens with long text?
How does the component behave at different viewport sizes?
Which visual states have been implemented?
Which patterns are truly reusable?
Storybook typically documents the frontend component contract, while the CMS still needs its own separate content contract.
For example, Storybook may show that a banner component accepts:
eyebrow
heading
body
image
link
alignment
theme
size
The CMS specification must decide:
which page types may use the banner
whether every theme is available on every brand
whether editors choose the alignment
whether the image is required
whether mobile and desktop images are separate
whether links may be internal or external
whether the banner is localizable
whether it can be scheduled
whether it requires marketing approval
whether the CMS should expose the technical size property at all
A component prop and an editor field are two different decisions. Many component props exist to support implementation flexibility, and only a subset of them make sense as editor-facing fields.
The missing artifact is a design-to-CMS mapping
Before production implementation begins, every important page type and component should be mapped across design, frontend, CMS, and systems.
A practical mapping can include the following columns:
Area
Questions to define
Purpose
What user or business need does this serve?
Design pattern
Which prototype or component represents it?
Frontend implementation
Which component or template renders it?
CMS model
Collection, global, block, relationship, configuration, or none?
Data source
Payload, PIM, DAM, CRM, ecommerce, API, or derived data?
Editable content
What can the editor safely control?
Locked structure
What remains controlled by design and development?
Variants
Which approved variations exist?
Required fields
What must exist before publishing?
States
Empty, loading, unavailable, expired, unpublished, error, and fallback behaviour
Permissions
Who can create, edit, review, approve, and publish?
Localization
Which fields and behaviours vary by locale?
Analytics
What must be tracked?
Migration source
Where does equivalent current content exist?
Scope status
Launch, future, exploratory, excluded, or unresolved?
This mapping converts a visual proposal into a buildable system definition, and it reveals where the prototype is incomplete without devaluing the prototype itself.
What implementation-ready actually means
A design does not need every sentence of final copy before implementation begins.
It does need enough definition that the team is no longer making structural product decisions accidentally during development.
A page or component is implementation-ready when the team can answer:
What is its purpose?
Is it a fixed template, reusable component, configurable section, or one-off experience?
What data does it require?
Which system owns each field?
What can editors change?
What must remain locked?
Which variants are supported?
What happens when data is missing, invalid, unavailable, unpublished, or expired?
How does it behave across mobile, tablet, and desktop?
Who can create, approve, and publish it?
How is it localized?
What existing content must migrate into it?
Which integrations does it depend on?
Is it required for launch?
How will the team verify that it works?
Not every decision must be final. Unresolved decisions can remain open when they are documented with an owner, an assumption, a deadline, and an understood implementation impact.
The real risk is hidden uncertainty dressed up as completion.
A better prototype handoff process
The prototype shouldn't be thrown over the wall to developers with a request to "make this editable in Payload."
A stronger handoff runs through several deliberate steps.
Step 1: Identify the reusable visual system
Review the prototype and Storybook for repeated templates, cards, sections, controls, states, and responsive patterns.
Separate genuine reusable components from elements that merely look similar in one prototype.
Step 2: Identify the content domains
Determine which repeated experiences represent structured content types.
Examples may include:
articles
recipes
products
events
giveaways
ambassadors
resources
campaigns
lead magnets
microsites
Match these to real content domains rather than defaulting everything to generic Pages and Blocks.
Step 3: Define system ownership
For each visible data point, identify its source of truth.
Product data may come from a PIM. Assets may come from a DAM. Lead submission may belong to Salesforce. Inventory may belong to an operational platform. Payload may only own the website-specific presentation and relationships.
Step 4: Define editorial control
Specify exactly what editors can change, what they can select, what is derived automatically, and what remains fixed.
This is where the project converts visual flexibility into controlled autonomy.
Step 5: Define states and edge cases
Document mobile behaviour, empty states, errors, expired content, unavailable integrations, missing translations, long text, absent images, and unpublished relationships.
Step 6: Separate launch scope from future ideas
Label every visible or discussed capability.
An attractive prototype shouldn't get to turn optional ideas into invisible commitments.
Step 7: Connect the future model to migration
Map existing content and functionality into the proposed collections, templates, integrations, and retirement decisions.
Step 8: Produce acceptance criteria
Define how the team will know that the implementation matches the intended experience and operational requirement.
Only then does the prototype become part of an implementation-ready package.
The prototype remains essential
A strong prototype remains one of the best tools available for aligning stakeholders, testing hierarchy, revealing reusable patterns, and making an abstract platform direction tangible.
The mistake is asking it to answer questions it was never designed to answer.
A prototype should communicate the intended experience. A component system should define reusable frontend behaviour. A CMS blueprint should define content structure, editorial control, permissions, relationships, and system ownership. An implementation specification should connect all of these into a testable production contract.
When those layers are separated clearly, the design can remain ambitious without forcing developers to invent the architecture underneath it. When they get collapsed together, the prototype creates false confidence, and the website can look almost finished before the project has actually decided how it works.
That is the gap teams need to close before implementation begins.
A CMS prototype shows what the platform could look like; an implementation specification defines what it must do, who controls it, where its information comes from, and how it behaves once reality stops matching the perfect screen.
