--- title: "CMS Prototype vs Implementation: 8 Steps to Avoid Rework" slug: "cms-prototype-vs-implementation-8-steps-avoid-rework" published: "2026-07-02" updated: "2026-07-15" categories: - "Payload" tags: - "CMS prototype" - "prototype handoff" - "implementation specification" - "content model" - "CMS design" - "Payload CMS" - "Storybook" - "migration planning" - "editorial control" - "design-to-CMS mapping" - "component design" - "prototype handoff checklist" llm-intent: "reference" audience-level: "intermediate" framework-versions: - "payload" - "figma" - "storybook" - "pim" - "dam" status: "stable" llm-purpose: "CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance…" llm-prereqs: - "Access to Payload" - "Access to Figma" - "Access to Storybook" - "Access to PIM" - "Access to DAM" llm-outputs: - "Completed outcome: CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance…" --- **Summary Triples** - (Prototype, answers, the look and feel (appearance and interactions)) - (Prototype, omits, content-origin, field ownership, permissions, migrations, edge-case behaviour) - (Treating prototype as implementation, causes, assumptions that become schemas, APIs, and rework) - (Implementation-ready handoff, requires, CMS design, content models, migration map, and ownership matrix) - (Handoff step: component mapping, action, map each UI component to content types and fields) - (Handoff step: editor surface, action, define which fields are editor-editable vs code-locked) - (Handoff step: external systems, action, identify PIM/DAM/CRM data and integration points) - (Handoff step: states and fallbacks, action, document missing, empty, error, unpublished, and expired states per template) - (Handoff step: migration planning, action, produce field-level migration mapping with transforms and validation checks) - (Handoff step: roles & workflow, action, assign create/review/approve/publish responsibilities and permissions) - (Storybook, use, to document component contracts and CMS data bindings) - (Figma, use, to extract content examples, responsive variants, and edge-state visuals) - (Payload CMS, use, to define content types, implement permissions, and run migrations) - (Acceptance criteria, must include, component variations, mobile states, and edge-case test cases) - (Deliverables, include, content model spec, migration map, Storybook examples, and ownership matrix) ### {GOAL} CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance… ### {PREREQS} - Access to Payload - Access to Figma - Access to Storybook - Access to PIM - Access to DAM ### {STEPS} 1. Identify the reusable visual system 2. Map content domains to types 3. Define system ownership and sources 4. Specify editorial control and fields 5. Document states and edge cases 6. Separate launch scope from backlog 7. Connect model to migration plan 8. Produce acceptance criteria and tests # CMS Prototype vs Implementation: 8 Steps to Avoid Rework > CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance… Matija Žiberna · 2026-07-02 # 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: 1. What is its purpose? 2. Is it a fixed template, reusable component, configurable section, or one-off experience? 3. What data does it require? 4. Which system owns each field? 5. What can editors change? 6. What must remain locked? 7. Which variants are supported? 8. What happens when data is missing, invalid, unavailable, unpublished, or expired? 9. How does it behave across mobile, tablet, and desktop? 10. Who can create, approve, and publish it? 11. How is it localized? 12. What existing content must migrate into it? 13. Which integrations does it depend on? 14. Is it required for launch? 15. 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.** ## LLM Response Snippet ```json { "goal": "CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance…", "responses": [ { "question": "What does the article \"CMS Prototype vs Implementation: 8 Steps to Avoid Rework\" cover?", "answer": "CMS prototype pitfalls: an 8-step handoff to make prototypes implementation-ready with CMS design, content models, migration mapping and acceptance…" } ] } ```