How We Build Pages
The recommended workflow for moving a page from approved brief to published live — every step, in operator language.
Building a page in SGEN follows a recommended seven-step sequence: read the brief, choose template-vs-compose, set up the page record, compose in SG-Builder, review on staging, promote to live, and capture follow-ups. This page is the shared working sequence — the steps every page build assumes — so that operators do not invent the order each time.
The sequence is recommended, not mandatory. Experienced operators may compress steps for low-stakes pages or extend them for high-stakes ones. What does not change is the structural shape: brief drives template choice, template choice drives composition scope, composition happens in SG-Builder, review happens on staging, promotion brings the change to live.
What is this for?
Read this page when you want the recommended working sequence for building a SGEN page. Use it before starting a page build to confirm the order, during a build to know what step you are on, and after to confirm follow-ups have been captured. It is meant to be the single shared workflow doc that every operator on the team can reference so the build process stays predictable.
The page is a practical guide. It walks the workflow at the operator level — what to do at each step, what decisions live at each step, and where to escalate. It does not duplicate per-step procedural detail that lives in per-area Reference (template selection, SG-Builder composition specifics, publishing operations); instead it links to those at each step.
Good use cases
You are building your first SGEN page and want to know the recommended order.
You are building a high-stakes page (campaign landing, pricing, regulator-facing) and want to confirm the workflow before starting.
You are leading a team of page builders and want a single shared working sequence everyone can reference.
You are returning to page-building after time away and want the order before you click anything.
You are reviewing a teammate's build and want the sequence to confirm nothing was skipped.
What NOT to use this for
Step-by-step composition mechanics inside SG-Builder — open the SG-Builder Reference.
Per-template configuration — open the Templates Library.
Specific publishing operations (save, publish, promote) — open the Publishing Model and the per-record Guides.
Figma-import specific workflow — open the Figma to SGEN guide.
How this connects to other features
Figma to SGEN — the Figma-specific entry into the same workflow.
SG-Builder Overview — the editor surface used in step 4.
SG-Admin Pages — the per-site Page record administration.
Templates Library — the reusable structures referenced in step 2.
Environments and Site States — the staging-to-live model the workflow runs over.
Publishing Model — the operations used in steps 5 and 6.
Step 01 — Read the brief
The brief is the approved document that defines what the page is for. It names the audience, the goal, the must-have content, the visual style if relevant, and the deadline. Reading the brief is non-negotiable; building from a half-read brief produces pages that get rebuilt.
What to extract from the brief:
- Audience — who is the page for, and what do they already know.
- Goal — what action or outcome the page is designed to drive.
- Must-have content — copy, images, links, components that must be present.
- Constraints — visual style, brand voice, regulatory or legal requirements.
- Deadline — when the page needs to be live.
- Stakeholders — who is reviewing and who is approving.
If the brief is missing any of these, capture the gap and resolve it with the requester before starting Step 02. Building forward on an incomplete brief almost always means a rebuild later.
Step 02 — Choose template vs compose
The second step is the most consequential one, because it sets the scope of every step that follows. Two paths:
- Template path. A page in the Templates Library matches the brief well enough that template-with-content-fill is the right approach. Use the template, fill in the content, adjust per-page tweaks. Faster, more consistent, easier to maintain.
- Compose path. No template matches well. Compose the page in SG-Builder using the available components. Slower, more flexible, requires more per-page review.
The rule is template-first. If a template covers 80% of the brief, use the template and customize the remaining 20%. Composing from scratch when a template would have worked produces pages that drift from the design system over time and create maintenance debt.
Step 03 — Set up the Page record
Open SG-Admin → Pages → New Page on the site. Set the slug, the title, the SEO fields, the parent (if hierarchical), and any per-page tags or category. The Page record is what holds the page's identity, configuration, and state — composition happens inside SG-Builder once the record exists.
Save (do not publish yet). Saving creates the record in draft on staging state. The Page is now visible in the Pages list but not at any public URL.
Step 04 — Compose in SG-Builder
Open the new Page record in SG-Builder. If you are on the template path, the chosen template is the starting point — fill the content slots, adjust per-page tweaks. If you are on the compose path, drag in the components needed and arrange them.
Save frequently. Saves do not affect public visibility (still draft on staging) but they persist your composition so a browser crash does not lose work. Use the device-switcher to confirm the layout works at desktop, tablet, and mobile breakpoints; SGEN's responsive cascade means desktop styling cascades to mobile by default, so mobile-specific overrides need to be added explicitly where the design requires them.
Step 05 — Review on staging
Publish the Page on staging. The record transitions from draft on staging to published on staging. Open the staging URL and confirm the page renders correctly, the content reads correctly, the links work, the forms submit, and the analytics tags fire. Walk the page on desktop, tablet, and mobile.
Send the staging URL to the reviewer. The reviewer's review happens at the staging URL, not in SG-Builder — the staging URL is what they would have seen if the page were live, so it is the right surface for an end-user-perspective review.
If the reviewer requests changes, return to Step 04 (compose), make the changes, save, re-publish on staging, and re-share the staging URL. Iterate until the reviewer signs off.
Step 06 — Promote to live
Once the reviewer has signed off and the checklist is clean, promote the Page from staging to live. The platform handles the promotion as a governed operation — it transitions the record to published on live, preserves the prior live version (if any) for recovery, and writes the audit signature.
Open the live URL after promotion to confirm the change is in front of end users. Walk the page once more at desktop, tablet, and mobile to confirm the live render matches the staging render.
If the live render diverges from staging, that is a structural finding — open the per-area Reference for the affected component and capture what behaved differently. Do not patch around the divergence on live; either roll back to the prior live version through the recovery surface or let the team know there is a staging-vs-live behavior gap.
| Step | Low-stakes page | High-stakes page |
|---|---|---|
| 01 Read brief | 10–15 min | 30–60 min · with stakeholder confirm |
| 02 Choose path | 5 min | 15–30 min · with template-fit review |
| 03 Set up record | 5–10 min | 15–30 min · including SEO + tags |
| 04 Compose | 30–60 min | 2–6 hours · multi-breakpoint passes |
| 05 Review | 15–30 min | 1–3 days · multi-stakeholder rounds |
| 06 Promote | 5 min | 15–30 min · with confirmation walks |
| 07 Follow-up | 10 min | 30–60 min · multiple proposals |
Step 07 — Capture follow-ups
After the page is live, capture follow-ups before closing the build. Common follow-ups:
- Documentation deltas — if the build surfaced a SG-Builder behavior you did not expect, note it for the team.
- Template promotions — if the per-page tweaks you made would benefit other pages, propose them as additions to the template (or as a new template entirely).
- Content gaps — if the brief's must-have content was missing or incomplete, log the gap with the requester.
- Reviewer feedback patterns — if the reviewer flagged the same kind of issue that a previous reviewer flagged, propose a workflow adjustment to catch it earlier.
Without follow-up capture, the team rebuilds the same lessons each build. With it, the workflow improves over time.
Constraints and boundaries
Some properties of the page-build workflow are structural and worth naming explicitly so operators do not assume otherwise.
- Template path is the default. Compose path is allowed but should not be the default for pages that a template covers.
- Saves do not change visibility. Save freely during composition; visibility only changes at publish.
- Staging review is non-negotiable. Skipping staging review and promoting straight to live undermines the workflow's purpose.
- Promote is per-record. A single promote operation moves one Page from staging to live. Bulk promote exists for multi-page work; per-page promote is the default.
- Follow-ups are part of the build. A page is not "done" until the follow-up capture step has been completed.
Definition
The page-build workflow in SGEN is the recommended seven-step working sequence for moving a page from approved brief to published live: read brief → choose path → set up record → compose → review → promote → follow-up.
The workflow is operator-tier — it lives in this practical guide, not as platform automation. SGEN's platform owns the publish + promote operations the workflow uses; the workflow itself is the human discipline operators apply on top of those operations.
Purpose
The purpose of this guide is to give every page-builder on a team the same shared working sequence so that page builds stay predictable, lessons accumulate over time (via follow-up capture), and high-stakes pages do not skip steps that low-stakes pages also need.
Scope
This page covers the workflow at the practical-guide level — the working sequence rather than the platform mechanics.
The page covers:
- The seven recommended steps and what each one decides.
- The template-vs-compose decision in Step 02.
- The staging review discipline in Step 05.
- The promote-and-confirm posture in Step 06.
- The follow-up capture discipline in Step 07.
The page does not cover:
- SG-Builder composition mechanics — open the SG-Builder Reference.
- Per-template configuration — open the Templates Library.
- Save / publish / promote at the platform level — open the Publishing Model.
- Figma-specific import — open the Figma to SGEN guide.
Examples
Example 1 — Building a campaign landing from a template
A campaign landing brief lands on the team. The page-builder reads the brief, identifies a Landing Page template that covers 90% of it, fills the content slots in the template (hero copy, CTA, supporting sections, footer block), tweaks the colors slightly to match the campaign brand, saves, publishes on staging, sends the staging URL for review, makes one round of edits after feedback, re-publishes on staging, gets sign-off, promotes to live, confirms at the live URL, captures one follow-up (the campaign brand color choice could be added as a Templates Library option). Total elapsed: under two hours.
Example 2 — Composing a one-off pricing page
A new pricing page is needed and no Templates Library entry covers it. The page-builder confirms with the team that compose path is correct, reads the brief, sets up the Page record in SG-Admin, composes in SG-Builder using available components, saves frequently during composition, walks all three breakpoints (desktop, tablet, mobile) and adds mobile-specific overrides where the design requires them, publishes on staging, sends to legal + finance for review, iterates twice, promotes to live, confirms at live URL, captures the per-page tweaks as a proposal for a Pricing Page template entry. Total elapsed: about a day.
Example 3 — Skipping a step and learning the cost
A page-builder skips Step 05 (staging review) on a low-stakes blog landing because it "looks fine on staging." After promotion to live, an end user reports that the form is not submitting. The page-builder rolls back through the recovery surface, fixes the form configuration, and re-promotes. They capture the lesson — staging review must include form-submit confirmation, not just visual review — and update the team's review checklist.
Example 4 — A high-stakes regulator-facing page
A regulator-facing page is needed and the brief is dense. The page-builder spends extra time on Step 01 (read brief), confirms with legal that the must-have content is captured correctly, picks template path with substantial customization, composes carefully with multiple device-breakpoint passes in Step 04, runs Step 05 review with both legal and a content lead, iterates three times before sign-off, promotes to live, walks the live URL twice (once immediately, once an hour later) to confirm caching has settled, and captures three follow-ups. Total elapsed: three days. The build was slow but right.
Example 5 — Using bulk promote at the end of a content sprint
An editorial team finishes a sprint with twelve blog posts and three landing pages all sitting at published-on-staging. Rather than promoting them one at a time, the operator runs Step 06 as a bulk promote. The audit trail records the bulk operation as a single event with the affected record list. End users see all fifteen new pieces simultaneously.
Example 6 — A reviewer-driven rebuild after a strike
A reviewer flags the same page wrong twice. The team's discipline is: at strike-2, do not patch — rebuild from the brief and the source HTML structure. The page-builder returns to Step 02, re-evaluates template vs compose, re-composes in Step 04 with the structural learnings from the failed first attempt, re-runs the review, and promotes a clean rebuild rather than a fragile patch chain.
Documentation guidance
This page is the workflow guide. Use it before starting a build, during the build to confirm step order, and after to confirm follow-up capture. For per-step depth, follow the linked references at each step.
For the Figma-import-specific entry into the same workflow, open Figma to SGEN. For SG-Builder composition mechanics, open the SG-Builder Reference. For the Page record administration, open the SG-Admin Pages Reference.
Reading order
If you are new to building SGEN pages, read this page after the Start Here pillar and the Shared Concepts pillar. Those give you the operating model; this page gives you the working sequence on top.
Related reading
Figma to SGEN — Figma-import variant of the workflow.
SG-Builder Overview — the editor used in Step 04.
SG-Admin Pages — Page record administration.
Templates Library — reusable structures referenced in Step 02.
Environments and Site States — staging-vs-live model.
Publishing Model — the platform operations the workflow uses.
Vocabulary cross-reference
- Brief — the approved document defining what the page is for; required input to Step 01.
- Template path — Step 02 decision to use a Templates Library entry.
- Compose path — Step 02 decision to compose from components in SG-Builder.
- Page record — the SG-Admin record holding the page's identity and configuration.
- Composition — the Step 04 work in SG-Builder of arranging components and content.
- Staging review — the Step 05 discipline of reviewing the page at the staging URL before promotion.
- Promotion — the governed platform operation that moves the page from staging to live; Step 06.
- Follow-up capture — Step 07 discipline of recording lessons before closing the build.
- Device breakpoints — desktop / tablet / mobile · checked during composition and review.
- Strike-2 rebuild — the discipline of rebuilding from source rather than patching when a reviewer flags the same page wrong twice.
- Bulk promote — promoting multiple records at once as a single audit event; alternative for end-of-sprint promotion.
- High-stakes page — a page where the cost of a mistake is high (regulator-facing, pricing, hero campaign); justifies extending steps.
- Low-stakes page — a page where compressed steps are acceptable; still subject to staging review.
- Workflow drift — when the team starts skipping steps and the build process degrades; periodic re-read of this page is the antidote.
- Reviewer sign-off — explicit approval at the end of Step 05; required before Step 06.
- Per-page tweak — a small adjustment made to a template-based page after content fill; common, but flagged for follow-up if it could become a template option.
- Design-system drift — what happens when compose path is overused; the team's pages diverge from a coherent design over time.
- Confirmation walk — the post-promote act of opening the live URL at all three breakpoints to confirm the live render matches staging.
- Recovery surface — the platform's operator-tier entry point for restoring a prior live version of a Page after a divergent or unwanted change.
- Template owner — the operator responsible for the Templates Library entry; sign-off needed for immediate template updates from a build's follow-up capture.
- Brief stakeholder — the person who approved the brief and is accountable for the page's outcome; usually the requester.
- Sprint promote — bulk promote of multiple records at the end of an editorial sprint; recorded as a single audit event.