Seddon Digital · for HR Gurus
What's under the bonnet, in plain English — and why it lets your team drive it without breaking it.
The short version
The style rulebook
Automatic.css
Holds your brand — colours, fonts, spacing — in one place, so the whole site changes when one setting does.
The builder
Etch
Where pages and templates are made and edited, inside WordPress.
The naming system
BEM
Gives every part of every page a predictable name, so nothing is a mystery and nothing bleeds into anything else.
The workshop
Backstage
The connection that lets Claude work on your site, and the place your house rules live so every page is built the same way.
Together they mean one thing: the design lives in the system, not in the pages. Pages just fill in the blanks.
The problem being solved
Worth naming, because the fix only makes sense once you can see the cause.
Your current site is built on the Avada theme, with a visual CSS-override tool layered on top and hand-written CSS layered on top of that. None of those three is bad on its own. The problem is that the same decision can be made in several places — a heading colour might come from the theme options, or the override tool, or a snippet, or styling typed straight into the page by whoever last edited it.
Four years later, nobody knows which one is winning. You change a setting and nothing happens. "Change it everywhere" means hunting down every page it was set on. Two pages that should match drift apart. A new page gets built by copying an old one and inherits all its oddities. Eventually the only safe move is not to touch it.
That isn't caused by bad taste or bad plugins. It's caused by not having one obvious place for each decision — and every part of the new build exists to give each decision exactly one home.
Automatic.css · the style rulebook
Instead of a colour being typed into a page as #13B0AB, it's referred to by its job. Every button on the site says "use the button colour for this background". Not one of them says "use #13B0AB".
What that buys you: change the turquoise once and it changes on every page, button, icon and template — including pages that don't exist yet. Same for fonts, spacing, and how rounded the corners are.
Fonts work the same way. The site uses three — Poppins for headings, DM Sans for everything you read, and Caveat for the odd handwritten line — and each is set in one place. No page ever names a font, so changing one is a single setting, not a page-by-page job.
Spacing works the same way. Rather than someone typing "40px" on one page and "45px" on another, there's a ladder of sizes and everything picks a rung. It's why the pages line up with each other, and why they'll still line up in two years.
Etch · the builder
Etch is the tool you'll use to build and edit pages, living inside WordPress admin. The important thing isn't what it's like to use — it's what it produces. Older page builders wrap your content in layers of their own scaffolding and store it in a format only that builder can read. That's why moving off one is a rebuild rather than a migration. Etch writes plain, standard web code. Your content stays your content.
Three things it gives you that matter day to day:
Templates, not copies. A template is a page design with the content left out. Your service pages all use one. Change the template and all of them change — the opposite of "copy the last one and edit it", which is how sites drift.
Components. A reusable piece: your team card, your problem card, your call-to-action band, your FAQ block. Build it once, drop it in anywhere. Fix it once, fixed everywhere.
Proper content types. Team members aren't pages with photos glued on — they're their own thing, with their own fields:
Team member ├─ Name ├─ Role ├─ Headshot ├─ Flip photo the second photo in the crossfade └─ Quote their one-liner
You fill in five boxes. The design is handled. Nobody can accidentally make the sixth team member look different from the first five — the fields don't allow it.
The same pattern sits behind your HR Advice section. And it's how you'd add anything new later: case studies, events, downloadable guides, podcast episodes.
BEM · the naming system
Read left to right: brand, then component, then the piece inside it, then the variation. Always in that order.
You'll rarely see one of these, so here's why it's worth caring about.
On a typical WordPress site, styles are named things like .btn, .title, .fusion-button-1 or .text-block-7. Two problems follow. Nobody can tell what .text-block-7 is without hunting for it. And generic names collide — a rule written for a button on the homepage quietly applies to a button in the footer, and now there's a bug three pages away from where you were working.
With BEM names, a style written for hrg-team-card__quote can only ever affect the quote on a team card. It is structurally incapable of touching anything else. Changes stay local. That's the single biggest reason this site will still be editable in three years.
It matters for the AI side too. When you point Claude at a page and say "make the card headings a bit bigger", it can find exactly the right thing to change, because the name says what it is. On a site full of .text-block-7, it's guessing — and guessing is how sites break.
Backstage · the workshop
Backstage is what you'll see in your WordPress admin, sitting alongside Posts, Pages and Media. It does two jobs — but first, a small bit of vocabulary, because it makes the rest easier to talk about.
| Term | What it means |
|---|---|
| Backstage | The tool itself, in your WordPress admin |
| The green room | The staging site — where work happens before anybody sees it |
| Front of house | The live site, what your visitors see |
| The promptbook | Your design-system rules, installed on the site. A promptbook is the stage manager's master document for a production — everything about how this show runs. |
Three or four words doing real work. Everything else stays plain: it's "Backstage → Create landing page", nothing more theatrical than that.
Job one: it's the way work gets in. It's how a design becomes a real page on your site without anyone hand-building it. You'll see this in your first drive session in September: supply or describe a design, and it's built in the green room as a real page, using your real components and your real brand settings. When you're happy with it, it goes front of house.
Job two: it holds the promptbook — on the site, not on someone's laptop. The build standards for HR Gurus (the naming rules, the "use Primary, never a hex code" rule, the component library, the accessibility requirements) live on your site. Anyone who connects to it works from the same promptbook.
Which means:
There's also a gate. Work that doesn't meet the standard is rejected before it's saved — a page that hardcodes a colour, invents a stray name, or drops a form in as raw code doesn't get published. It's sent back with the reason.
That's not us being precious. It's the mechanism that makes "no Frankenstein" a property of the system, rather than something everyone has to remember to be careful about.
How the four fit together
| Your website | Its HR equivalent |
|---|---|
| Automatic.css — one place for every brand decision | The policy handbook — one source of truth, not six versions in six inboxes |
| Etch templates — one design per page type | Templated letters and contracts — consistent, correct, quick |
| BEM naming — everything named the same way | Consistent file naming and record-keeping — anyone can find anything |
| Backstage — the promptbook and the gate | Induction and sign-off — new people do it the right way from day one, and work is checked before it's final |
You already know why a business with all four runs better than one where everyone improvises. Same reasoning, applied to a website.
Day to day
| You want to… | Who does it | How |
|---|---|---|
| Publish a blog post | You | WordPress editor, as now |
| Add or update a team member | You | Fill in five fields |
| Add an HR Advice piece | You | Fill in the fields, the template does the rest |
| Build a landing page for a campaign | You | Pick the landing template, add your sections |
| Add a new service page | You | Service template |
| Change a page's words or images | You | Edit the page |
| Change your turquoise, or any brand colour | You or us | One setting |
| Change how every service page is laid out | Us | Edit the template once, green room first |
| Add a page type that doesn't exist yet | You + us | You design it, we template it — four spares already included |
| Add a new content type (case studies, events) | Us | New content type and template, then it's yours to fill |
Content and pages are yours. Templates and site-wide styles come through us, through the green room first.
Not because you can't be trusted with them — because a template change touches every page that uses it, and those are worth a second pair of eyes before they go live. That one rule is what stops Frankenstein round two.
The long run
A dozen page types, all templated. Your team publishing pages, posts, HR Advice and team profiles without touching design.
You'll want things nobody has designed yet — a campaign page shape, a case study format, a resource library. Some are new pages from templates you already have: immediate, no cost. Some need a new template — there are four already paid for. Design it, we template it in the green room, it joins the permanent set, and from then on it's yours to reuse.
New service line, a brand tweak, a navigation restructure. Because the design lives in the system, these are system changes rather than page-by-page rework. Adding a colour is a settings change. Restructuring navigation doesn't touch page content at all.
The two things that usually kill a website are: nobody can safely change it, and the content is trapped inside a builder. Neither applies here. Content sits in WordPress in standard formats, styles sit in one settings screen, and the rules sit on the site itself. If you ever move on from us, everything you'd need to hand over is documented and portable — and we'd rather build it that way and keep you because you want to stay.
Governance
The tools make the right way the easy way. They don't make the wrong way impossible — nothing does. So, four rules:
One way in. Pages get built through the templates and the Claude workflow. Not by pasting in raw code, not by installing another page builder.
Templates and site-wide styles go through us. Green room first, then front of house. Everything else is yours.
No new page-building plugins. Every one added is another place a decision can hide — which is exactly how the last site got the way it is.
Image descriptions and heading order stay human. The templates handle the rest of accessibility automatically. These two depend on what you're writing about, so they're covered in your training.
What we need from you
Nothing technical — the system is our job. What we need is the design direction: page designs and copy, so the templates are built around what you actually want to say rather than our best guess. That's the Friday 29 August list.
And an hour in the week of 15 September for training, so the whole thing stops being a description and starts being something you use.
Questions about any of this are welcome at the weekly catch-up. There's no such thing as a silly one, and it's easier to ask now than to work around a misunderstanding for a year.