The admin panel is the product

Nobody demos the admin panel. The CMS is often an afterthought. The user experience gets the redesign and the well-crafted launch note, and the screen where the work actually happens often only gets whatever is left. The editors and producers I worked with spent more hours in the CMS than any reader ever spent on the site, and the quality of everything downstream was set by what that system made easy (or hard). So this asymmetry is a smart thing to tackle.

What went wrong first

Using a default CMS meant many incoming requests got sentenced to the Jira backlog. They may come to fruition some day but not in time to satisfy the reason they were created. Further, well-meaning, enterprising producers taking matters into their own hands led to site styles and components getting sprawled out and redundant. Three ways to set a headline, four near-identical card treatments, spacing that drifted a little further from standards with every page built. This is the ordinary failure mode of any tool that lets people compose freely, that forces ambitious producers to hack together their own solutions, and it does not announce itself. It accumulates doggedly over time.

The knee-jerk reaction to avoid this is an approval gate. But a gate makes contribution expensive and laborious, and I had the feeling that the people contributing were not the problem: the system was.

Empower the system, free the composition

Three things helped reel this problem in. First, a design system: every new element had to be built from sanctioned McKinsey Design System and Editorial Design System assets, in other words, access to the right tools and building blocks. This access empowered producers to compose nearly whatever they wanted while minimizing drift. Second, a taxonomy, so the content library has a clear shape and components are findable. Third, regular checkpoints to prune any outliers along the way.

A core team of about 10-20 contributors ran those reviews themselves, from the beginning. That part is worth stating precisely, because the usual version of this story is a team that eventually reaches federated governance after starting with a gatekeeper. That is not what happened. It was community-run the whole time, and what improved was the workflow around it, refined until it worked.

Governance turned out to be mostly a design problem rather than a policing problem. Get the system right and there is very little left to police.

Three decisions

Publish status is a state machine, not a boolean. Published and visible are different questions. An article can be live and deliberately hidden from search, from the feeds, or from the news home page, independently, because those are three different audiences reaching it three different ways. Collapsing that into one toggle would have pushed the real decision into email.

The Stacks Manager, rather than a component catalogue. Editors, producers, and designers could all contribute new components and styles, and place them straight into the content they were building. A catalogue is something you go and consult. This put the block where the writing was happening. Letting non-designers contribute is the harder governance problem, and the custom library is what made it safe.

Automatic URL, with the override one click away. Slugs are generated by default, so the common case is consistent and nobody has to think about it. The manual override still exists, because sometimes it genuinely matters. Safe default, cheap escape hatch. The same argument as the design system, applied to a text field.

A second audience, and a much harder permission model

I got the chance to carry this same discipline into a global benefits product with its own admin panel, for an entirely different and more varied population: developer admins, global admins, country admins, and country coordinators. Four tiers, running from engineers at one end to non-technical coordinators at the other, all working in the same system. This product scoped permissions by country, across a firm operating in more than 60 of them.

Here, there were four domains to control for: which content a person could see, what they could edit, what they had authority to approve, and which eligibility data they could reach. That last one is the reason the model had to be real rather than tidy. Benefits differ by country because the law differs by country, so the permission model was carrying a regulatory boundary, not just an org chart. Getting it wrong does not just produce an inconsistent page. It bumps up against regulatory frameworks.

Two different admin surfaces, audiences who had never met, and in the second case a span of expertise inside one tool that most products get to split across several. What travelled between them was not the interface. It was the method: model the object, name the states, decide what the default protects, and put the escape hatch one step further away than the safe path.

It is the same idea as the design-system constraint, one level up. There, the primitives were tokens and the thing being protected was consistency. Here the primitives are capability and country, and the thing being protected is someone's private information. Constrain what can be composed and most of the enforcement problem stops existing.

What it produced

• 100+ editors, designers, and producers working in the platforms, across combined products in 60 countries.
• A flexible and dynamic production workflow that could grow with the team's ambitions without burdening engineers.
• A core team of about 10-20 contributing components and reviewing each other's work.
• Sprawl and redundancy reversed by a design system, a dynamic library, and regular checkpoints, without the need for another approval gate.
• Still in production today, running on the original design.

Tokens are a taxonomy. Constraining what people can build from is the same move as structuring a corpus so that a model can answer questions about it. Structure is what makes contribution and growth sustainable.