How Do You Design a Site the Marketing Team Can Actually Edit?

How Do You Design a Site the Marketing Team Can Actually Edit?

By deciding, at design time, exactly which parts are editable and refusing to make the rest editable at all. A site that breaks when someone changes a headline was not designed badly. It was designed as though nobody would ever change a headline.

This is the part of a website project that gets the least design attention and causes the most damage over two years. The launch looks immaculate. Eighteen months later the same site looks tired, inconsistent and slightly broken, and nobody did anything wrong.

What happened is that a hundred small edits happened in a system with no guardrails. That is a design failure, and it is preventable.

Why Do Sites Degrade After Launch?

Because the design assumed content that no longer exists. Every layout carries hidden assumptions: that this heading is four words, that this image is landscape, that this section has exactly three cards, that this paragraph is short.

None of those assumptions are written down. They are baked into the visual result and invisible to the person making the edit. So the marketing manager writes a nine word heading because it is a better heading, and the layout that was designed around four words does something ugly.

Multiply that by two years of legitimate content decisions and you get a site that nobody chose. The fix is not to train people harder. It is to design a system where the ugly outcome is not available.

What Should Be Editable, and What Should Not?

Text and images, almost always. Structure, spacing, colour and type, almost never. That single rule prevents most of the damage.

The temptation runs the other way. Clients ask for flexibility, and giving an editor control over colours and spacing feels generous. In practice it hands someone a decision they have no criteria for making, at a moment when they are trying to publish a page before a meeting.

So we make the generous version narrow. You can change every word. You can swap any image. You can add, remove and reorder sections from a defined set. You cannot change the padding, pick a new accent colour, or set a font size, because those decisions were made once, deliberately, for the whole site.

Why Can't Editors Be Trusted With Colour?

Because colour has a legal and practical floor that is not obvious by eye. The W3C's WCAG success criterion 1.4.3 requires that "the visual presentation of text and images of text has a contrast ratio of at least 4.5:1," with large text allowed a lower ratio of "at least 3:1."

Large text is precisely defined too: "at least 18 point or 14 point bold," which WCAG notes is "equivalent to approximately 18.5px and 24px" in CSS pixels. There are exceptions for incidental text and for logotypes, but they do not cover the body copy someone is about to recolour.

Nobody eyeballs 4.5 to 1. A brand colour that looks fine on white can fail on the section background it lands on, and the person making the change has no way to know. Expose a small set of pre-tested colour pairings instead, and the failure mode disappears without anyone needing to learn a ratio.

What About Images, Which Editors Definitely Should Control?

Control the slot, not the file. An editor should be able to replace any image freely, and the design should make it impossible for the wrong image to break the page.

That means every image slot has a fixed aspect ratio and a defined crop behaviour, decided at design time. It also means dimensions are always declared, because undeclared dimensions are a measurable performance problem rather than an aesthetic one.

Google's guidance on Cumulative Layout Shift, which is "a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page," lists "images or videos with unknown dimensions" as a direct cause. The threshold matters: good is "0.1 or less" and poor is "greater than 0.25," measured at the "75th percentile of page loads."

So a site where editors upload images into unsized containers will fail a Core Web Vitals threshold gradually, as content accumulates, and the cause will look like nothing anyone did. We covered the mechanics of this in what actually causes layout shift.

How Do You Design a Component That Survives Real Content?

By testing it against the content that will actually arrive, not the content that would look best. This is the single highest value habit in this whole discipline.

For every component, we design three states before it ships: the short version, the long version, and the empty version. A card with a three word title and a card with a twelve word title. A section with one item and the same section with seven. A quote with no job title, because someone will forget the job title.

If any of those three states looks broken, the component is not finished. That is a low bar and almost no site clears it, which is why almost every site has a page somewhere with a heading wrapping onto a fourth line into a button.

Working from real copy from the start makes this natural rather than laborious, which is the argument for designing content first.

What Does This Look Like Technically?

A defined set of components with a defined set of editable properties. Modern platforms support exactly this, and the shape of the support tells you the intent.

Webflow's Data API, for instance, exposes component properties as a first class concept, with an endpoint to "get the default property values of a component definition." A component is not a loose arrangement of elements. It is a thing with named inputs and default values, and the designer decides what those inputs are.

That is the mental model to design towards regardless of platform. Ask, for each component, what are its inputs. If the answer is "anything," you have not finished designing it. If the answer is "a heading up to sixty characters, a body paragraph, one image at three by two, and an optional link," you have built something a person can use safely and a machine can validate.

How Many Components Should a Site Have?

Fewer than feels sufficient during design, and more than one for every page type. There is a bad equilibrium at both ends.

Too few, and editors start using components for jobs they were not designed for, which produces the same degradation as unrestricted styling. A three column feature grid being used to hold two logos and a paragraph is a symptom of a missing component.

Too many, and nobody can find the right one, so they pick whichever appears first and modify it. A library of forty sections with similar names is functionally the same as no library.

Our working target is a library small enough to fit on one screen, with names that describe purpose rather than appearance. "Customer proof" rather than "three column grey cards," because purpose survives a redesign and appearance does not. That naming discipline is the least glamorous part of a design system and the part that decides whether it gets used.

Who Should Decide What Is Editable?

The designer and the person who will actually edit it, in the same conversation, before the design is finished. Not the person who commissioned the project, and not the developer afterwards.

This conversation takes about thirty minutes and it is the most useful thirty minutes in the project. Ask what they publish most often, what they wish they could change without asking, and what they have broken on their current site. The answers reshape the component list every time.

The frequent request we push back on is a freeform rich text block that can hold anything. It is genuinely useful and it is also the trapdoor through which every constraint escapes. We usually provide one, on blog posts only, with a styled set of allowed elements and nothing else.

How Do You Know Whether It Worked?

Look at the site a year later and ask whether it still looks designed. That is the real measure, and it is not subtle when you check.

A more immediate test is to ask the editor to build a new page without help, while you watch and say nothing. Every hesitation is a design problem. Every moment they reach for a component and then change it is a missing component. Every question is documentation you owe them.

We do this before launch now, as a normal part of handover rather than as a favour. It is uncomfortable and it finds things no internal review finds, because the person clicking is the only one without the designer's assumptions in their head.

Is This Worth the Extra Design Time?

It is not extra time, it is time moved earlier. The work of deciding what an editor can change happens either at design time, deliberately, or over the following two years, accidentally, by whoever is publishing under deadline.

The second route is more expensive and produces a worse site. It also produces the conversation we have most often with prospective clients, which is that their site was fine at launch and they are not sure what happened to it.

Nothing happened to it. It was designed for a launch rather than for a life. If you are planning a new site and want to think properly about who will edit it and what they should be allowed to break, that is exactly the sort of conversation we enjoy, and you can find us at phoenix.studio.