UX

How SGEN handles the experience of building, viewing, and interacting with your site

UX in SGEN is the set of surfaces that decide what your team sees while building, what your visitors see while reading, and how the gap between the two stays small. The platform ships visual building, responsive output, popup orchestration, theme presets, and consent surfaces — each one a real control in the admin, each one with a visible effect on the public site.

This page is the entry point: what each UX surface is for, when to reach for it, and where the deeper docs live. It also draws the line between UX work that lives in this section and adjacent work (Page Builder, Templates, Media Library, Tracking Consent) that has its own dedicated docs.

What is this for?

Use this page when the question involves how the site looks, how it responds across devices, what a visitor experiences when they land, and how editing decisions in the admin show up on the public side. It is the cross-cutting layer that ties the visual surfaces together.

The five UX surfaces this page covers are: the visual page builder (SG-Builder), theme and color-swatch presets, responsive behavior across breakpoints, popup orchestration, and the visitor-facing consent surface (Tracking Consent).

Good use cases

• Picking a color palette for the site without writing CSS.
• Switching the header or footer chrome variant for a seasonal change.
• Building a landing page with a visual editor instead of a code file.
• Confirming a new section renders cleanly on mobile before publishing.
• Adding a promo popup that fires on a specific page or after a specific event.
• Setting the consent surface a visitor sees before tracking fires on the public site.

What NOT to use this for

• Replacing structural design decisions with surface-level swatches. If the layout is wrong, repainting the swatch will not fix it.
• Treating the page builder as a one-off design tool. Anything that needs to live across many pages should be a template, not a per-page hand-build.
• Using popups as the primary navigation channel. Popups interrupt; navigation should not.

How this connects to other features

• Security — UX surfaces that touch visitor data (popups that capture email, consent banners) intersect with the security and disclosure layer.
• Page Builder — the visual editor where day-to-day building happens. UX-wide decisions cascade into Page Builder defaults.
• Templates — the surface where reusable structures live. A pattern repeated across pages belongs here.
• Performance & Reliability — the architectural sibling. Faster pages and consistent rendering are part of the perceived UX.

Before you start

You need an admin account on the site. Editor and Site Owner roles can both reach the page builder and the popup admin. Theme and color-swatch changes are scoped to Site Owner and Administrator because they affect the site-wide chrome.

If you are reading this on a fresh install, open Appearance → Themes once and confirm the default swatch is loaded. Everything below assumes you can preview a public page after a save and see the change reflected.

Where to find it

UX is spread across several admin surfaces. The shortcut paths are:

• Themes / Color Swatches: /sg-admin/appearance/themes
• Header / Footer / Mobile Menu chrome: /sg-admin/appearance/header, /sg-admin/appearance/footer, /sg-admin/appearance/mobile_menu
• Page Builder: opens from the page or post edit screen via the "Edit with SG-Builder" action
• Popups: /sg-admin/popups/
• Tracking Consent: the consent surface lives in Site Settings under the Tracking Consent panel

Steps

1. Pick a color swatch for the site

Open Appearance → Themes. The default tab is Color Swatches, which holds the site-wide palette presets. Each swatch card shows a preview of how the swatch lays out across the chrome. Click a swatch to select it. Click Save Changes. The swatch repaints every page that uses the site-wide CSS variables.

2. Switch a chrome template (header, footer, mobile menu)

In Appearance → Themes, click the relevant tab in the hero tab bar: Header, Footer, or Bottom Bar Sticky Mobile. Each tab holds the variant cards for that slot. Pick a card. Click Save Changes. The new chrome template renders on every page.

A reasonable rhythm is: pick the swatch first, then pick the chrome variants. Picking chrome before the swatch can mean re-picking once the colors change the visual weight of the chrome.

3. Open a page in the visual builder

From the page or post list, hover the row and click Edit with SG-Builder. The visual editor loads with the current page state. Drag components in from the left panel, edit text in place, swap images from the media library. Save the page from the SG-Builder save action — the editor's "Save" writes to the page record, and "Publish" pushes it live.

4. Verify a page renders correctly across breakpoints

Inside SG-Builder, the breakpoint switcher across the top of the canvas swaps the editor view between widths: 1920, 1199, 991, 767, 575, 480 pixels. Click each width and walk the page top to bottom. If a section breaks at a specific width, edit that section's responsive behavior at the same breakpoint where the issue appeared.

After saving, load the public page on a real phone. The browser-on-device test catches the small set of issues the in-editor preview misses (font rendering at the OS level, tap target spacing, scroll inertia).

5. Add a promo popup

Open Popups → Add New. Fill in the popup title, the body content, and the trigger (page-load, after-N-seconds, on-scroll, on-element-click). Save. The popup appears in the Popups list with a status of Draft. When you are ready, change the status to Publish from the row's status control.

To wire the popup to a specific button, copy the popup's hashcode from the list (it reads as #sgp_) and paste it into the link or button on the page that should trigger the popup. The link element handles the open call; the popup handles the rest.

6. Set the consent surface visitors see

Open Site Settings → Tracking Consent. The panel holds the visible text, the categories of tracking the visitor can opt in or out of, and the placement (banner / modal). Save. The next visitor sees the configured surface before any tracking fires.

What success looks like

A site with healthy UX in SGEN reads like this:

• The color swatch and chrome variants match the brand without any hand-CSS overrides.
• Every page in the site list opens cleanly in SG-Builder and renders at all six breakpoints without visible breakage.
• Popups fire on the trigger they are wired to and dismiss cleanly when the visitor closes them.
• The consent surface appears on the first visit and respects the visitor's choice on subsequent visits.
• The public site at a desktop width and the public site at a phone width feel like the same site, not two different ones.

What to do if it does not work

Symptom: A swatch change does not show on the public site.
Confirm the swatch was saved (the swatch card should carry a check icon after Save Changes). Reload the public page with cache disabled. If the change still does not appear, the page may carry a hand-CSS override that pins the colors — open the page in SG-Builder and check the page-level Custom CSS panel.

Symptom: A page renders fine in SG-Builder but breaks on the public site.
The editor canvas reflects most styles but not all of them, and some browser behaviors (visited link colors, autoplay restrictions, OS-level font rendering) only appear on the real public side. Reload the public page with cache disabled. If the break is at a specific width, open the page in SG-Builder and switch the breakpoint switcher to that width — the editor's responsive view will surface the issue.

Symptom: A popup does not fire.
Confirm the popup status is Publish, not Draft. Confirm the trigger is configured (an empty trigger means the popup never fires). If the popup is wired to a button via hashcode, confirm the button's link target is the exact hashcode (#sgp_) and not a typo.

Symptom: A header or footer change does not appear on every page.
The header and footer chrome are site-wide by default. If the change appears on most pages but not one specific page, that page may have a per-page chrome override — open the page in the page edit screen and check the chrome settings panel.

Symptom: The consent banner appears every visit, even after the visitor accepted.
The visitor's consent is stored in their browser. If the banner reappears, the storage was cleared (incognito, manual cookie clear, browser policy). The banner reappearing after a real clear is the intended behavior. If the banner reappears in the same browser session, open Tracking Consent and confirm the placement and storage settings are correct.

Examples

Example 1: Switching to a seasonal palette.

A team running a product site wants to swap to a warmer palette for the autumn season. The Site Owner opens Appearance → Themes, clicks the burgundy-gold swatch, and clicks Save Changes. The next page load shows the new palette across the chrome, the buttons, the link colors, and the section backgrounds. No CSS files were touched. The change rolls back in one click by re-selecting the prior swatch.

Example 2: Building a landing page in the visual editor.

A marketing lead needs a landing page for a campaign. They create a new page from the Pages list, open it in SG-Builder, and assemble the page from the component library: hero section, three feature cards, a pricing block, an FAQ accordion, a contact form. Each component's text edits in place. The page saves once at the end. The breakpoint switcher confirms the page renders at desktop, tablet, and phone widths before publish.

Example 3: Wiring a popup to a "Get the guide" button.

A blog editor wants every visitor who clicks the Get the guide button on a long-form post to see an email-capture popup. They open Popups, create a new popup with the form embedded in the body, save it, and copy the hashcode (#sgp_42). They open the post in the page builder, find the Get the guide button, and set its link target to #sgp_42. Save. The next visitor who clicks the button sees the popup.

Notes on responsive behavior

Responsive behavior in SGEN is controlled at six breakpoints: 1920, 1199, 991, 767, 575, 480. Each breakpoint is a switch in the SG-Builder canvas that previews the page at that width. Styles set at a wider breakpoint cascade down to narrower ones unless the narrower breakpoint sets its own override.

This cascade is a pattern, not an accident. The fastest way to author a section that renders correctly across all widths is:

1. Set the desktop styles at 1920 first.
2. Switch to 991 and set tablet overrides only where the desktop layout breaks.
3. Switch to 575 and set phone overrides only where the tablet layout breaks.

Skipping the middle breakpoints and only checking desktop and phone is a common cause of layout issues — the cascade may produce an awkward in-between state on actual tablet widths.

Notes on accessibility

SGEN ships components with default semantic structure (heading levels, button vs link tags, form-label associations) and supports the standard keyboard interactions for popups and modals (Esc to close, focus trap inside an open modal). The default color swatches ship with reasonable contrast between text and background, but a custom swatch or a hand-CSS override can break that contrast — verify with a contrast checker if the brand palette pushes against the readable range.

The platform does not publish a specific compliance certification for accessibility. The intent is reasonable defaults plus surfaces a builder can use to author accessibly; the formal accessibility audit for any specific site is a project the site owner runs against their published pages.

Visitor-side perceived performance

Two UX surfaces are perceived-performance levers more than they are visual ones:

• The consent banner placement and timing. A banner that fires before the page renders feels heavier than a banner that appears once the page is interactive. The Tracking Consent panel exposes the placement choice; pick the variant that matches the site's read pattern.
• The popup trigger. A popup that fires on page load competes with the page content for attention. A popup that fires after a few seconds of scroll feels less interruptive. The trigger choice is per-popup; pick deliberately.

Both surfaces have a real effect on the bounce rate. They are UX choices first and tracking choices second.

Related reading

• Security — admin-side and visitor-side trust surfaces.
• Page Builder — full SG-Builder walkthrough.
• Templates — reusable structures that scale across pages.
• Popups — popup orchestration in detail.
• Performance & Reliability — the architectural layer that supports perceived UX.

---

From Actual Feature Content Corpus (2026-04-27 export, page #18)

Group: UX
Route seed: /ux
Audience visibility: Client-facing default. Internal builder-side specifics live in the page-builder runbooks, not here.

This section preserves the original landing-page framing. It records the documentation boundary for UX material on the public docs site.

Documentation boundary

The UX section documents the user-experience surface of SGEN, including interaction quality, responsive behavior, layout control, accessibility-facing behavior, and the practical experience of using and viewing SGEN-managed sites. In SGEN Docs, UX is not reduced to visual preference. It covers the behavior of the interface and the viewing experience of the site as encountered by editors, operators, and visitors.

When to reach for this section

Use this section when the question involves interaction, responsiveness, perceived quality, builder output, or user-facing experience. Continue into Page Builder, Templates, Media Library, or SEO and Performance when the question becomes more specific.

What this page covers

• Visual building surface (SG-Builder), theme presets, and responsive behavior.
• Popup orchestration and consent placement.
• Cross-cutting UX decisions that intersect with security, performance, and content surfaces.

What this page does not claim

• It does not promise specific accessibility certifications or audit attestations.
• It does not promise a specific Core Web Vitals or Lighthouse score for any given site.
• It does not promise a fixed set of breakpoints beyond the six the visual editor exposes today.
• It does not name any internal infrastructure component, vendor, or service.

Validation notes

The behaviors documented above are evidenced from the live admin on the QA staging site. Surface names (Color Swatches, Themes hero tab bar, popup hashcode pattern #sgp_, breakpoint switcher widths 1920/1199/991/767/575/480) match the surfaces live in the SGEN admin as of the 2026-04-21 surveyor pass. Specific Lighthouse benchmarks and customer Core Web Vitals data are intentionally absent — only quotable when sourced and attached to a real measurement.

Related surfaces in the SGEN admin

Appearance (Themes, Header, Footer, Mobile Menu, Styles & Layouts), Pages, Posts, Popups, Site Settings (Tracking Consent panel), Templates, Media Library.

A short tour of the visual building loop

A clean working loop inside SG-Builder reads like this:

1. Open the page from the page list with the Edit with SG-Builder action.
2. Pick a section template from the left panel that matches the structure you want.
3. Drop it on the canvas. Edit the text in place. Swap the image from the media library.
4. Switch the breakpoint switcher to 991, then 575. Confirm the section holds at each width.
5. Save inside the editor.
6. Load the public page in a separate browser tab. Confirm the change appears.

Steps four and six are the loop most teams skip. Skipping them is how a section that looked correct in the editor ships broken on a phone.

Why responsive overrides cascade

The cascade pattern in SG-Builder mirrors the way CSS itself cascades from wider to narrower media queries. The editor's six breakpoints are:

• 1920 — wide desktop
• 1199 — standard desktop
• 991 — large tablet
• 767 — small tablet
• 575 — large phone
• 480 — small phone

A style set at 1920 applies at every narrower width unless a narrower breakpoint sets its own override. This is why the recommended authoring order is wide to narrow, not narrow to wide. Authoring in reverse forces the editor to override at every width upward, and the resulting style stack is hard to reason about a month later.

When a popup is the wrong tool

The popup surface is a real lever but it is overused. Three patterns are popups doing work that another surface would do better:

• Important navigation in a popup. If a visitor needs to reach a page, the navigation should reach it directly. A popup adds a step and a dismiss action.
• Critical legal text in a popup. If text is legally required, the page should carry the text in body content where it is crawlable, not in a popup that may be dismissed before it is read.
• First-time-visitor onboarding crammed into one popup. Onboarding that needs more than three sentences belongs on a real page, not stacked into a single popup body.

Use popups for the work they do well: time-bound promos, email-capture asks tied to a specific action, contextual help on a specific element. Anything else, reach for a page or a section.

Cross-device parity check

The shortest cross-device parity check a builder can run before publish:

1. Load the page on a real desktop browser. Read it top to bottom.
2. Load the page on a real phone (not the editor preview). Read it top to bottom.
3. Compare the two reads. If a section feels different in pacing, image weight, or call-to-action prominence, the responsive overrides are doing too much or too little.

Five minutes per page. The check catches roughly 80% of the issues a real visitor would hit before the visitor hits them.

One paragraph on theme rollback

Theme presets are deliberately designed to be reversible. A swatch that did not land the way the team expected can be reverted by re-selecting the prior swatch and clicking Save Changes. The chrome variants behave the same way. There is no one-way door in the theme picker. This matters because it lets a team experiment with the look in production without committing to it — pick a swatch, walk the public site for ten minutes, decide. The reversibility is the point.

When to bring in a designer

Most UX work in SGEN is recoverable inside the visual building loop. Three signals are worth bringing in a designer rather than continuing alone:

• The brand needs a custom color palette that does not match any shipped swatch and the team does not want to maintain hand-CSS overrides.
• A page needs a layout pattern that does not fit any existing component or template.
• The site is being redesigned end to end as part of a larger brand refresh.

In each case the designer's output lands in SGEN as a custom theme, a custom template, or a set of custom Page Builder components — surfaces the team can then operate without designer involvement on the day-to-day.

The day-to-day after the design lands belongs back in this section.

Related reading

Topic
Security
Page Builder
What this covers
---
What is this for?
Good use cases
What NOT to use this for
How this connects to other features
Before you start
Where to find it
Steps
What success looks like
What to do if it does not work
Examples
Property	Value
---	---
title	UX
audience	public
classification	PUBLIC
audit_at	2026-05-14