How do you keep clients from breaking the design in the CMS

You keep clients from breaking the design by putting layout in components and leaving the CMS only structured fields, constrained images, and copy that already has a home. Preview plus an Editor seat — never Designer — is the rest of the product. The person who logs in on Tuesday is trying to ship a date, a quote, or a still. If the admin can invent a new fold, they will, and it will not be malice. This spoke sits under Websites That Feel Like Films. Guardrails are how the film survives contact with a real editor.

The short answer

• Lock layout in components. Fields change headline, support, image, date, URL. They do not change spacing, type scale, motion, or which modules exist.
• Prefer structured fields. Required plain text, date, URL, and image-plus-alt. Reject layout enums, badge 1–8, and a blob “Pages” type.
• Constrain images. Pixel size and file weight in help text, alt required, no type in the pixels, crop or focal point if the stack has it.
• Ban raw HTML. Rich text only on a named long-form body that already has a typography system. Cards, heroes, and quotes are not magazines.
• Preview the real template, then publish from an Editor seat. Designer is a production tool. A courtesy Designer invite is how brand sites become junk drawers.

Lock	Door it closes
Components own folds	Layout enums, detachable symbols, “make this one different”
Structured fields	Blob “Pages” type, badge 1–8, per-item color
Image size + required alt	Phone dumps, type in pixels, empty holes
No raw HTML	Extra H1s, inline CSS, vendor embed soup
Editor seat + real preview	Designer invite, blind publish

What actually breaks when an editor “just updates copy”?

They are not trying to redesign you. They paste what they have: a Google Doc, a flyer export, a phone still, a “quick badge.” The CMS will render whatever you allowed. I have shipped hundreds of production sites; the wrecks that come back in month two are almost always field-shaped, not “the client has bad taste.”

What they meant	What the live page does	Guardrail
Paste the poster copy	Inline fonts, extra headings, a table that overflows on a phone	Plain-text fields; no HTML in the card
“Make the headline pop”	A second H1, a span, or type baked into the hero still	One H1 in the template; CMS title is a bound text field
Drop a phone photo	8MB file, wrong ratio, layout shift on load	Size and weight in help text; width/height on the img
Add “just one badge”	Visual noise; the card no longer matches the system	Delete the field. Badges are a design-system object, not a CMS hobby
Leave optional video empty	Broken player, collapsed hero, or a poster hole	Component collapses, or the field is required
“Can we also embed the playlist?”	Third-party iframe, extra tracking, fold that never settles	Embeds off unless a named human owns them

Do not invent a rate for this. There is no honest “X% of clients break H1s” number in this studio, and I will not mint one. The failure is mechanical: if the field can emit a heading, an image without dimensions, or markup, the template will obey.

Treat paste as hostile input. A Google Doc is not a layout system.

When copy arrives from Docs, Word, or a flyer PDF, run this before it touches the CMS:

1. Paste into a plain-text field, or into a notes app that strips formatting, then paste that.
2. If the line is a headline, support, quote, or CTA, it never goes in rich text.
3. If they sent a designed poster, keep the facts (date, city, URL) in fields and the poster as one still — not as HTML.
4. Preview at phone width. If the line wraps into the overlay or covers a face, shorten the field, do not detach the component.
5. Publish only after preview matches the template they already approved.

If you skip that, you are not “being flexible.” You are laundering a flyer into the design system.

How do you lock layout so fields cannot invent a fold?

Components own composition. The CMS owns slots. If an editor can detach a symbol, swap a section, or pick “layout B,” you did not ship a design system. You shipped a kit of parts with the safety off.

Build the lock in this order:

1. Design the page as named components (hero, proof row, date list, quote, CTA band) with slots for text and media.
2. Bind each slot to one field. No slot that “might be a video or a gallery or an embed.”
3. Put spacing, type, color, and motion in the component. Do not expose them as fields.
4. Define the empty state for every optional slot: collapse, placeholder, or hidden. Never a hole.
5. Delete any enum that changes structure (“card / banner / full-bleed”).
6. QA by logging in as the editor seat and trying to invent a fold. If you can, the lock failed.

Surface	Locked	Still editable
Homepage hero	Crop, overlay, type size, CTA style	Headline, one support line, one still + alt, one CTA label + URL
Work / project card	Ratio, hover, title style	Title, year, one still + alt, one-line constraint
Tour row	Column order, date formatting	Date/time, city, venue, ticket URL
Press quote	Quote style, logo size	Outlet, sentence, link
Blog / notes body	Heading scale, list, quote	The body itself, inside that scale

Webflow earns this when you actually use components and a content-editor seat: that role cannot change design, component structure, page slugs, custom code, or CMS settings. Framer is the same idea on a designer-led canvas — collections with helper text and required flags, still not a reason to hand over the canvas. Headless stacks lock this in the template, not in hope.

Component QA as the editor, not as yourself:

• You cannot detach the hero or a card
• You cannot add a section the sitemap did not already name
• You cannot change type size, overlay, or gap
• You can change the bound fields only
• A too-long headline wraps inside the component
• A missing optional still does not leave a hole
• Duplicate page is not the workflow; duplicate collection item is

If any box fails, you are training people to work around the system. They will.

A handshake is not a component API.

Why structured fields beat a blob page type?

A blob “Pages” collection with twenty optional switches is how a homepage becomes a junk drawer. Each job gets a collection. Each field has one job. If the template does not bind a field, delete the field. Editors fill holes. They will not leave a “for later” slot empty for long.

Job	Field type that holds	Field type that breaks the film
Hero line	Plain text, help text with a character band	Rich text, Markdown, or HTML
Support line	Plain text, ~70–90 characters in help text	A second rich-text “intro”
Date	Date/time	Freeform “Saturday-ish”
Ticket or CTA	URL field	A linked word inside a paragraph
Quote	Plain text + outlet + link	HTML for a single sentence
Featured still	Image + required alt	An <img> pasted into body copy
Long-form case body	One named rich-text body	Custom HTML, extra embeds, a second “optional body”
File (rider, menu)	File + title + updated date	A PDF buried in rich text

Model it as a procedure, not a vibe:

1. List the jobs for the first ninety days (dates, work, press, services, team).
2. For each job, list the fields the template actually paints.
3. Mark required anything whose absence leaves a hole.
4. Mark optional only what the component already collapses.
5. Write help text that states size, length, and what happens if they skip it.
6. Reject any field whose only purpose is “flexibility.”

Webflow collection fields let you mark required and attach help text when you add the field. Framer’s collection field editor does the same: rename, helper text, required toggle. Sanity Studio validation can go further: field rules and document rules that block publish when a featured item is missing proof. Use the teeth you have. Help text that says “Enter the title” taught nobody.

Character bands I actually write into help text (the stack may not enforce a max — the preview QA must):

Field	Band I put in help text	What breaks if you ignore it
Hero headline	~40–70 characters	Three-line wrap into the still, or type so small it dies on a phone
Support line	~70–90 characters	Paragraph in a slot that was a sentence
Card title	~40–60 characters	Ragged grid, titles that wrap unevenly
Quote	One sentence	A manifesto in a pull-quote
Alt	One clause that describes the photo	“image”, the filename, or a keyword dump
CTA label	Two to four words	A sentence on a button

If a field exists “for later,” it will be filled with junk now.

What image constraints survive a phone dump?

Images are the fastest way to kill a composition. Phone dumps are huge, wrongly cropped, and often have the headline baked into the pixels. That still cannot be edited, translated, or read by a screen reader. It also fights Lighthouse without killing the design: a mystery-weight hero is how LCP and CLS show up as “the CMS” six weeks after launch.

WCAG 2.2 Success Criterion 1.1.1 requires a text alternative for non-text content presented to the user. An optional alt field that stays empty is not a CMS feature. It is an accessibility defect you scheduled. Require alt on every content image.

Chrome’s unsized-images audit exists because images without width and height shift the page as they load. CLS is a Core Web Vitals field metric. Your template must emit dimensions. The editor’s upload is not a substitute for that.

Upload they will try	What it does to the fold	Constraint
12MP phone still, no resize	Slow LCP; CLS if the img has no dimensions	Pixels + weight in help text; template emits width/height
Square IG export in a 16:9 hero	Faces cropped, empty sidebars	Named crop or focal point; not one file for every slot
Headline baked into the still	Cannot wrap, cannot localize, alt becomes a lie	Type lives in a text field
Empty optional slots 3–5	Mismatched stills or empty frames	One required still, or a real gallery collection
PNG screenshot of a flyer	Unreadable type, huge file	Flyer as one image; facts still in fields
Missing alt	WCAG 1.1.1 miss	Required alt, not “image” or the filename

Image QA before you call the model done:

• Required image on every template that shows one
• Help text states pixels and a file-weight target
• Alt is required and the cheat sheet shows a good example
• Decorative marks in the design system are not editor-uploadable
• The img in the template has width and height (or an equivalent that reserves space)
• Empty optional media collapses; it does not show a broken player
• A phone-width preview is part of the editor path, not a designer-only canvas

Campaign stills and site stills are different jobs. A square for Instagram is not a 16:9 hero. A story crop is not a card. If the editor uploads the same file everywhere, one of those templates will lie.

Surface	What the crop must protect	Do not use
Homepage hero	Face / product / venue name in the safe area	A story screenshot with UI chrome
Work card	One subject, consistent ratio	A collage of four stills in one file
Tour poster slot	The flyer as an image, facts still in fields	HTML of the flyer
Press logo	Transparent / simple mark	A screenshot of the article
OG / social share	Separate asset if the hero type will not read at small size	The 4000px hero dumped into OG

A still with the tour name in the pixels is a poster. Posters belong in print. The website still has to crop.

Why ban raw HTML and unbounded rich text?

Raw HTML is how a locked component becomes a poster of fonts, extra H1s, and embeds. Rich text is a magazine tool. It is a weapon inside a three-line card.

Webflow’s rich-text field can take headings, images, video, embeds, and code. That is correct for a case-study body. It is incorrect for a hero, a card, a quote, or a date row. Webflow’s content-editor role cannot add custom code at the site level. That restriction is the product. Do not reopen the door with an HTML embed field “in case they need it.”

WordPress is the other door. Default roles already separate Editor from Administrator. Administrator can install plugins, switch themes, and delete the site. The unfiltered_html capability is documented as posting HTML markup or even JavaScript in pages, posts, comments, and widgets — and on Multisite it is held by Super Admins. On many single-site installs the HTML door is wider than people assume. Gutenberg’s Custom HTML block is sitting there. If you use WordPress for a brand site, lock templates, restrict who can add HTML blocks, and never hand Administrator to someone who only changes dates.

Rules that hold:

1. Headline, support, date, URL, quote: never rich text.
2. One rich-text field per collection, maximum, unless the template has two named bodies (example: case summary + case body).
3. Character min/max when the stack allows it. If it does not, put the band in help text and fail it in preview QA.
4. A style-guide page that shows H2 / H3 / list / quote — and nothing else.
5. Embeds off unless a named human owns them and you accepted the third-party cost.
6. No Custom HTML field, widget, or block on the editor seat.

Input	What it smuggles	What you accept instead
Google Docs / Word paste	Spans, font-size, extra headings	Plain text; retype the line
“Can I drop the flyer HTML?”	Inline CSS, broken mobile	Image of the flyer as a still, plus structured fields for the facts
Embed code from a vendor	Extra JS, extra cookies, CLS	Official component you built, or nothing
Markdown in a card	Accidental headings	Plain text
SVG paste “for sharpness”	Scriptable markup in the wrong place	A file field you control, or a design-system icon

Paste is hostile. The model should assume paste is hostile.

What must preview prove before publish?

If editors cannot see the page before publish, they will either fear publishing or publish blind. Blind publish is how a 4000px still, a wrapping headline, and a missing alt all go live together. Staging, Webflow preview, or a configured preview URL is not a luxury. It is how you keep brand trust.

Headless stacks do not get a pass because the schema is pretty. Contentful’s content preview is a configured URL per content type — slug tokens, environment, locale — so the editor opens the real page, not a JSON blob. Sanity list previews are a different surface: title, subtitle, media in the desk so editors can find “March 22 Atlanta” instead of drafts.tour-14. A desk of twenty “Untitled” rows is how the wrong item goes live.

Webflow’s content-editor docs are blunt about collision: last edit wins. Coordinate, or you will overwrite. Preview does not fix that. A rule does.

Preview must prove this before you call the build done:

• Draft is the default for new items
• Preview URL matches the live template, including phone width
• Empty optional fields do not explode the layout in preview
• A too-long headline wraps inside the component; it does not break the fold
• The uploaded still crops the way the art direction intended
• Publish is a named action with a confirm, not a hidden toggle
• Unpublish / revert is possible without a developer
• Two people editing the same item have a written rule

Put CMS editor QA on the launch checklist for brand sites the same way you tick forms and OG: named owner, named rollback, no “we will train them after the campaign.” A site that launched with Designer seats and no preview is already in debt.

Legal-approval shops need draft → review → live, not a Slack “look ok?” thread. If the CMS cannot hold that state change, you chose wrong for this client — even if the visual editor looked nicer in the demo.

Preview that counts	Preview that lies
The live template, same breakpoints	A form with thumbnails
Phone width in the same session	Designer canvas only
Empty optional fields shown	Happy-path with every slot filled
Too-long headline shown	Lorem that fits
The editor’s seat	Your Admin seat

If they only preview as you, they have not previewed.

Which CMS roles cannot invent a homepage?

Not everyone needs Designer or Admin. Editors edit. Publishers publish. Someone owns the structure. “We trust them” is not a permission model.

Webflow’s content-editor role is built for this: copy, assets, CMS items, comments, and publish if you toggle it. Content editors cannot change design, component structure, page slugs, custom code, or CMS settings, and they cannot create new collections. That restriction is the guardrail. Webflow’s legacy Editor vs content editing docs covered the 2026 cutover off the live-site Editor. If a 2024 handoff PDF still says “open the Editor from the live site,” rewrite the cheat sheet. The seat name in the product is the source of truth.

WordPress: Editor can manage posts and pages. Administrator can install plugins, switch themes, and delete the site. Handing a marketing coordinator Administrator because “they might need it” is how brand sites grow a plugin graveyard.

Contentful custom roles (Premium plans) can allow or deny by content type and environment — read-only in master, edit in a sandbox. Use that when the weekly editor should never see schema.

Human	Seat	Must not have
Weekly editor	Content editor / Editor / custom “can edit”	Designer, Admin, plugin install, Custom HTML
Publisher (if separate)	Same plus publish	Schema, locales they do not own
Studio / engineer	Designer or Admin	A shared password with the editor
Intern “just looking”	Comment or view	Publish
Former employee	Nothing	A lingering seat from last year

Seat rules I write into handoff:

1. One named weekly editor, their own login, 2FA on.
2. Publish permission is a choice, not a default. Split editor vs publisher if legal cares.
3. Studio keeps Designer/Admin until transfer, then documents who holds it.
4. Review seats quarterly. People leave. Seats linger.
5. If they can see Designer, stop the session and fix the invite before you train anything else.

Trust is not a permission model. Shared logins are how you lose the audit trail and keep a former intern’s session alive.

• No studio+client@ shared inbox login for the weekly editor
• 2FA on every seat that can publish
• Offboarding in the same week someone leaves, not at renewal
• Studio Designer/Admin is named, not tribal knowledge

What fails first when you skip the lock?

Failure mode: you ship a cinema-grade site, invite the intern as Designer “so they can nudge copy,” and thirty days later a component is detached, a homepage module is unique, and every future edit is a one-off. The cost is not a training Loom. The cost is a rebuild of the system you already sold.

This is the path I see when teams skip guardrails:

1. Designer invite because Editor “felt limited.”
2. Someone detaches a component to “fix a line break.”
3. A second page is duplicated from the now-unique page.
4. Image dumps land in the detached hero with no help text.
5. Motion or a third-party embed is added on one page only.
6. The next campaign cannot reuse the system. You are in snowflake debt.

Symptom	Likely cause	Fix
They asked for Designer in week one	The model cannot do the job, or they want to tweak	Fix the job in fields. Do not grant Designer
Headline wraps into three lines on a phone	No character band, or the component assumed one line	Cap the field; fix the empty/long state
Fold jumps when the still loads	Unsized image, or a huge file	Dimensions in the template; weight in help text
Extra H1s in the card	Rich text where plain text belonged	Change the field type; migrate the items
They email you every change anyway	Fear, or the seat is wrong	Preview path + two supervised publishes, or you operate it
Site drifted for a year	No monthly pass, Designer lingering	Paid cleanup, then lock the seats

Do not treat this as a personality problem. If an intern can invent a fold, the model failed. If they cannot complete a date update in ten minutes, the model also failed — that is the complementary problem of a CMS nobody will use. This page is the other failure: they did log in, and they used every door you left open.

Bravery is not a restore strategy. Unpublish and a component library are.

If a page already went snowflake, restore in this order — do not “nudge it back” in Designer with the intern watching:

1. Unpublish or revert the item if the stack can. Screenshot the wreck first so you know what you are undoing.
2. Re-attach or replace the detached component from the library. Do not keep the unique page as a secret master.
3. Move any still-good copy into the structured fields. Throw away the inline styles.
4. Delete the HTML / extra rich-text field that made this possible.
5. Remove Designer from the person who did it. Train the Editor path on that same item.
6. Add the failure to the cheat sheet (“if you can see Designer, stop”).

If you skip step 5, you will restore this again next month.

How does this affect conversion?

Broken CMS edits do not show up as a neat “conversion dropped N%” in a studio case study I can cite, and I will not invent one. What they do is mechanical, and you can watch it on a phone.

Breakage	What a visitor hits	What you lose
Second H1 / heading soup from rich text	Hierarchy collapses; the page shouts everywhere	The one action you wanted
Type baked into the hero still	Unreadable on a small screen, cannot wrap, cannot localize	The promise above the fold
Unsized or huge still	CLS, slow LCP, a fold that jumps under a thumb	Trust in the first seconds; Core Web Vitals you already paid for
Extra CTA in a “badge” field	Two competing buttons	Clicks that do not match the campaign
Bad crop on mobile	Face, product, or venue name missing	Recognition — the whole point of the still
Fear of publishing	Stale dates, stale proof, last year’s tour	The film looks abandoned

Conversion here is not a mysterious brand aura. It is whether the next action is obvious and whether the page still looks like the brand they followed here. A film-grade homepage that an intern can restyle into a flyer is worse than a quieter template that still matches the campaign stills.

If you run ads at a campaign URL, the CMS on that template needs the same lock. A pre-save or landing page with a Custom HTML dump is how spend hits a page that no longer matches the creative.

I will not claim a percentage lift from “adding field limits.” I will claim this: every optional layout switch is a future A/B test you did not mean to run, on production, with no control group.

What should you ask a designer about this?

If you are hiring, do not ask whether the site will “be easy to update.” Everyone says yes. Ask how the admin is forbidden from becoming a second design tool.

• Which seat will our weekly editor have on day one — and can they see Designer?
• Which collections exist, and which fields are required vs optional?
• Where is help text for image size, alt, and headline length?
• Is there a raw HTML or Custom HTML path on that seat?
• Which fields are rich text, and which templates consume them?
• What does preview open — the real page at phone width, or a form?
• What happens if an optional image or video is empty?
• Who can publish, and is there a draft → review state if legal needs it?
• What does training include — two live edits on our content, or a Loom of Designer?
• Who owns the workspace, seats, and export when you leave?

Answer you want	Answer that is a tell
“Content editor only; Designer stays with us”	“We’ll add you as Designer so you have options”
“Tour is date, city, venue, URL — that’s it”	“You can build any layout you need”
“Preview is the live template”	“You’ll see it when you publish”
“Alt is required”	“Alt is in the SEO tab if you want it”
“Rich text on the case-study body only”	“Rich text on everything so you’re not limited”

A designer who cannot answer the seat question is not ready to ship a brand CMS. A designer who wants to give you Designer so you “aren’t blocked” is selling future snowflake debt.

When is a custom site worth it for CMS lock-in?

A custom front end is worth it when the visual CMS cannot express the jobs without layout switches, or when you need validation the builder will not enforce. It is not worth it because “custom” sounds premium.

Stay on a visual CMS (often Webflow, sometimes Framer) when:

• The weekly editor is non-technical
• Jobs map to collections the builder already models well (work, dates, press, team)
• Components can lock the fold without a layout enum
• Preview exists in the product you are actually using
• You can keep Designer off the client

Move to custom (Astro/Next + Sanity, Contentful, or kin) when:

• You need document-level rules that block publish (featured item missing proof, headline over band, missing alt)
• Multi-channel content, or engineering already owns the front end
• The visual builder’s rich text cannot be constrained enough for the templates you need
• You are escaping a WordPress page-builder collage and will not survive another plugin
• Performance and motion budgets are first-class and the CMS must not be allowed to blow them

Situation	Direction
Marketing team, structured jobs, locked components	Webflow, ruthless fields, content-editor seat
Designer-owned, few collections	Framer, honest CMS depth, still no canvas for the intern
Engineering-owned, multi-year, validation you can put in git	Headless + preview you actually configured
Writers already in WordPress and you can lock templates	WordPress, Editor only, HTML blocks off
Studio publishes, client never logs in	Git or a thin admin you operate — no fake “their CMS”

Custom is worth it for this problem when you will spend the money on schema, preview, and roles — not on a unique homepage that still has a rich-text hero. If you cannot staff the admin, custom is a pretty form. Invoice content ops instead.

What should you skip if you only have a week?

You cannot rebuild the design system in five days. You can close the doors that invent folds. Do this in order and stop when the week ends.

1. Seats. Remove Designer / Admin from anyone who only edits content. Confirm they land in Editor / content-editor. If you cannot, you do not have a week-one win.
2. HTML doors. Delete Custom HTML fields, embed fields you do not own, and rich text on cards, heroes, and quotes. Migrate those values to plain text.
3. Image help text. Required still, required alt, pixels and weight in help text, one example in the cheat sheet.
4. Preview. Bookmark the preview URL. Run one phone-width pass on the highest-cadence collection.
5. One collection only. Dates, or work, or press — whichever they actually publish. Do not “clean up” seven schemas.
6. Cheat sheet. One page: login, seat, those fields, preview, publish, what to do if they published the wrong thing.

Skip in a one-week pass:

• A new vendor
• A full design-system rewrite
• Training on Designer
• Optional badge fields “for later”
• A blog migration
• Localization
• A second environment you will not look at

If the week is a launch week, pair this with the launch checklist — DNS and forms still matter more than a pretty CMS desk. If the site is already live and drifting, seats and HTML doors first. Pretty help text on a Designer seat is theater.

One-week object	Do	Skip
Seats	Editor only	A workspace migration
Fields	Kill HTML and card rich text	A new collection “for the blog later”
Images	Help text + required alt	A DAM / asset-library project
Training	Two live edits on one collection	A 50-minute Designer tour
Docs	One-page cheat sheet	A Notion wiki nobody will open

How do you measure whether the guardrails hold?

Do not measure “they said training was clear.” Measure whether the admin can still invent a fold, and whether the jobs they actually run stay inside the template.

Run this pass at two weeks, then monthly:

• Count of client Designer / Admin seats (target: zero for weekly editors)
• Can you, logged in as their seat, detach a component or add a section? If yes, the lock failed
• New items this month: any extra H1s, Custom HTML, or embeds the template did not expect
• New stills: any file over the weight you wrote, any missing alt, any type-in-image
• Time for the editor to complete one real job (date, quote, project) without Slack
• Rollbacks this month: wrong publish, overwrite, or “put it back”
• Preview used before publish (ask them to show you; do not take a vibe)
• Empty optional fields still collapse on a phone-width preview

Signal	Guardrails holding	Guardrails failing
Seat list	Editor only	Designer “just in case”
New work item	Title, year, one still, one constraint	Layout tweaks, extra badges, a unique module
Tour update	Under ten minutes, preview, publish	Slack thread + a Designer tweak
Homepage	Same components as launch	Detached hero, extra embed, new type size
Performance	New stills inside the weight band	LCP/CLS tickets after every campaign

Two weeks is enough to see whether they can complete a job without opening Designer. A month is enough to see whether seats drifted. A quarter is enough to see whether the collection is alive or abandoned. If nobody published, you do not have a design-breakage problem yet. You have an unused-login problem — and the honest move may be that you operate content, or you delete the unused collections.

The scoreboard is not “the client is happy.” The scoreboard is: the film still matches the system, and Tuesday still ships.

First Tuesday after a lock, sit with them on their machine and try to break it:

1. Confirm the seat. If Designer is visible, the measurement already failed.
2. Attempt to add a section, detach a component, or paste HTML. You should be blocked.
3. Paste a too-long headline and a phone still. Preview at phone width.
4. Leave optional media empty. Confirm no hole.
5. Publish. Check the live page: one H1 in the template, still cropped, no inline-style soup.
6. Count Designer seats before you leave. Zero for weekly editors.

If they can invent a fold in step 2, stop training and fix the lock. Training on a door you left open is theater.

FAQ

How do you keep clients from breaking the design in the CMS?

Lock layout in components, cap the CMS to structured fields, constrain images (size, weight, required alt), ban raw HTML and unbounded rich text in cards, require preview of the real template, and give Editor or content-editor seats — not Designer. If an intern can invent a fold, the model failed. Training without those locks is a Loom of a trap.

How do I measure whether CMS design guardrails are working?

Count Designer seats on the client, then try to invent a fold while logged in as their seat. Check new items for extra headings, HTML, oversized stills, and missing alt, and time one real job from login to publish. If preview is skipped and Slack is the real CMS, the guardrails are not working. Two weeks shows the job; a month shows whether seats drifted.

What usually fails first when teams try this?

Designer access for someone who only needed Editor, then a detached component “to fix a line break.” Rich text on a card and a phone-photo dump are the next two. Fix the seat and the field types before you write a longer cheat sheet. A PDF cannot outrun a permission you should not have granted.

How long does this take to show results?

Seat and HTML-door changes show up the next time someone logs in — same day if you sit with them. Field migrations and image help text show up on the next real publish, usually the first campaign or date change. A monthly pass is how you catch drift; do not wait for a year-later redesign quote. If nothing publishes, you are measuring usage, not breakage.

What should I skip if I only have a week?

Do not switch vendors or rebuild the design system. Remove Designer from weekly editors, kill Custom HTML and rich text on cards, write image size and alt into help text, and train one collection with preview. Skip blog migrations, localization, and optional badge fields. A week that only produces a Loom of Designer is a wasted week.

When is this not worth doing yet?

If nobody will log in, skip the CMS and invoice content changes — an unused login cannot break the design, and it also cannot keep proof current. If the offer is still changing every month, do not invest in a seven-collection model. If you need a URL this week for validation, a locked builder page beats an unlocked “flexible” CMS. Guardrails are for sites that must stay a film while someone else publishes.

CTA

If the next intern should add a date without inventing a homepage, that is a sprint constraint. Start on Websites or book it at contact.