The challenge: enable page creation without coding
Corey Ward describes building a marketing website and blog for Figma with Gatsby and Sanity. The stated challenge embedded in the implementation is operational: marketing needed to create new pages without coding, while those pages remained structured and ready for search. The project account reports a block-based page builder, a form builder and submission handler, localization with four languages in use at the time, and a blog with search, categories, feeds, multi-author support, and an archive. [1]
That combination suggests a broader design problem than simply placing modules on a canvas. Editors need enough choice to respond to campaign needs, but each available block also creates a promise about what can be published, how it behaves on different screens, and whether it can be maintained. The case describes the capability; it does not establish how often editors used it, how much time it saved, or what effect it had on sales. Those questions would require evidence beyond the implementation account.
Execution: a component system behind editorial choice
Our reading of the page builder is that editorial choice should have a defined boundary. A useful component offers campaign-specific content fields and a small set of approved variations. Layout, responsive behavior and publication safeguards still need an owner, even when an editor can assemble the page without coding.
The useful interpretation is that page flexibility can be delivered through a bounded vocabulary of components. A page builder can let an editor select, order, and populate approved sections without making every visual or structural decision editable. That division keeps campaign assembly in the editorial workflow while the underlying design system remains an implementation responsibility. The source describes these capabilities, but does not specify the complete content schema or prove that any particular editor task required no engineering under every circumstance.
Workshop: a small, explicit content contract
The original model separates the purpose of a page, reusable content blocks and the publishing decision. It is a proposed teaching model, not Figma’s private implementation. The downloadable JSON Schema makes required fields and supported block types inspectable.
| Block | Required fields | Editorial acceptance check |
|---|---|---|
| Text | Heading and body | The heading identifies the section’s actual task. |
| Evidence | Claim, source label, text alternative | The proof remains intelligible without its image. |
| Action | Descriptive label and internal path | The destination matches the promise in the label. |
The sample schema rejects unknown fields and requires an owner rather than treating review as an informal step. Text, evidence and action blocks are distinct because their validation needs differ. A claim needs a source label and a text alternative; a next step needs a descriptive label and a constrained destination. A production CMS would also need role permissions, localization, migration and link validation appropriate to its own stack.
Test the contract by giving an editor a real brief and asking them to assemble a page without a developer. Preview at a narrow width, then remove the image and check whether its argument still works. Record where a new block is actually necessary; adding a visual variant for every exception recreates the maintenance problem that a content model is meant to reduce.
Take the working files
A proposed product-section block
A sensible follow-up would be to define one reusable product-section block with required fields for a heading, concise body copy, one primary call to action, a destination, and an image with meaningful alternative text or an explicit decorative setting. Optional fields could control a small number of approved variations, such as image placement or background treatment. Editors would not receive free-form controls for arbitrary spacing, typography, or layout. This proposal is an analysis of how to operationalize the reported block model, not a claim about Figma’s historical schema.
The block should expose clear validation and preview states: required content is visible before publication, button text describes its destination, and the rendered section follows the site’s responsive and accessibility rules. Keeping variation deliberate makes a block useful for campaigns without turning every page into a custom design surface. The tradeoff is intentional: some unusual campaign concepts will need a new component or developer review, so the system should include a route for requesting those changes.
Draft preview and localization responsibilities
A further proposed step is to make preview a defined handoff between editors and publishing infrastructure. Gatsby’s Sanity source-plugin documentation explains that draft overlays can replace published documents in preview environments, and that preview behavior requires configuration; it also cautions that drafts may not satisfy validation rules, so a frontend should check nested properties before rendering. [2] This is implementation context, not evidence that every Figma feature came from the plugin or that this particular preview setup was used.
For a localized page, editors should be able to identify which language they are previewing and whether required fields, links, image descriptions, and calls to action are complete in that version. A proposed release checklist would assign content accuracy and translation completeness to the editorial team, with engineers responsible for the preview environment, rendering safeguards, and component behavior. A preview that looks correct in one language should not silently stand in for review of all language variants.
Acceptance task: build one launch page
A concrete follow-up is an acceptance exercise in which an editor assembles one launch page using only approved blocks, adds a product section and a form, then previews and checks the page in each supported language. The page passes when the editor can complete the task without code changes, required fields and calls to action are clear, the content has an accessible image treatment, and reviewers can distinguish draft content from published content. Any missing block, confusing field, or broken preview becomes a specific system improvement rather than an informal request for greater freedom.
This exercise would test the boundary between editorial control and unrestricted layout changes: can the team handle a realistic launch within the components provided, and can it identify when a new component is genuinely needed? The historical account establishes that block-based page building and related marketing capabilities were part of the described implementation. The acceptance task is proposed work that could make those capabilities easier to evaluate and maintain; it should not be read as a claim about measured outcomes.
Sources & useful references
Results are attributed to the original publisher. Proposed tests and creative recommendations are our analysis.
