Four Kitchens: When the people who run the platform aren’t the people who run the content

We’ll walk through:
Whether you manage one site or one hundred, we hope you leave with something you can use.
Dave Hansen-Lange
Editors don’t log into a CMS at random. They arrive with a purpose: fixing a typo, publishing a new story, or checking whether a content import ran correctly. Whatever the task, they’re already in the right mindset. They’re thinking about the website and are ready to make changes.
On our dashboard, we highlight the pages with the most accessibility errors. We show a list of broken links. We surface draft content that never got published. These aren’t things editors have to go hunting for. They appear right when editors are ready to do something about them.

One thing that helped clarify our thinking: on the back end, your audience is actually more focused than it might seem. On the front end of a university website, you’re trying to serve prospective students, current students, faculty, staff, donors, and more. But in the CMS, your primary audience is your content editors. There might be a few other users (stakeholders who log in occasionally to get a lay of the land, or interns assigned to clean up a single page), but by and large, you’re designing for a pretty clear group.
And don’t let perfect be the enemy of good. Our first dashboard was basic: simple tables, in a single column, nothing animated or interactive. If you get a dozen useful things on a dashboard, the organization as a whole is going to be better for it. Start there, then build up.
Dave has been crafting websites since 2003 and has been active with Drupal communities around the world, sharing a passion for improving effectiveness, editorial experience, and long-term success.
Editors are expected to carry all of that context across multiple tools and respond when something surfaces. For people whose primary job isn’t web publishing, that’s a lot to ask.
A dashboard brings that context back into the CMS, the place where the work actually happens.
First, people were unlikely to act on it. A PDF that arrives by email, detached from the website itself, is easy to file away and forget. Second, even the editors who did read it had no way of knowing whether they were improving until the next quarter’s report showed up. The feedback loop was three months long.

Before we built our dashboard, someone on our platform team was manually generating reports for each of the 130 sites every quarter. Accessibility problems. Broken links. Duplicate content. All compiled, formatted, and sent out as a PDF.
The conversations that happen while building a dashboard are often more valuable than the dashboard itself. When you ask your team what should appear on it, you surface competing priorities that usually haven’t been written down anywhere:
We help manage a Drupal platform that supports 500 editors across 130 sites. Getting a dashboard right for that kind of scale required us to ask some uncomfortable questions about what we actually valued, and what we’d been ignoring.
Quarterly report → read → maybe remember → maybe act later
For us, that meant focusing our first version on the editors who log in regularly and need to take action. We can add more guidance for infrequent users in later iterations. Starting with the core use case meant we shipped something useful without trying to solve everything at once.
Information alone doesn’t change much. The problem usually isn’t awareness. It’s timing.
becomes

Every item that appears is there because someone, explicitly or quietly, decided it mattered. Looking at our current dashboard, I can tell you what it says about our priorities: we value accessible content (pages with the most accessibility errors are one of the most prominent blocks), and we value simplicity and iteration over comprehensiveness.
That’s worth thinking carefully about, because most dashboards aren’t designed that way. They’re assembled. A few shortcuts here, some default widgets there. The result is a starting screen that reflects what was easy to build rather than what editors actually need.

We also use the dashboard to answer questions editors commonly ask us. One recurring one: how does content get into the site from other university systems? Faculty profiles, events, and course data. All of it comes in through automated imports. Drupal has robust tools for this, but its default interface exposes every option and setting, which is overwhelming for a content editor. So we’d never exposed it to them at all. Editors had no visibility into something that was working fine. They just didn’t know it.
In our session, “A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need,” we’ll share the story behind a dashboard built for 500 editors across 130 sites — the decisions we made, the things we got wrong, and how we figured out what actually belongs on a dashboard and what doesn’t.

• What are editors most commonly asking us for help with?
• What do we wish editors were doing that they aren’t?
• What should be the first thing someone sees when they log in?
• What action should be easiest to take?

There’s a real risk that a dashboard drifts into feeling like a compliance tool, a place that exists primarily to point out what’s wrong. If the only things editors see when they log in are warnings and error counts, the dashboard starts to feel like surveillance.
That last one is something we’ve gotten real value from. Our platform has 130 sites, which means making a breaking change to a component has a wide impact. Before we had the dashboard, that kind of communication was difficult. We still do targeted communications about breaking changes. But now we also use a simple announcements block (it pulls from a Google spreadsheet where each row is an announcement) to reach editors right where they’re working. It’s low-tech, but it means we can flag an upcoming change and tell editors exactly what to check. That’s made us more comfortable shipping improvements we might otherwise have sat on.

Dashboards aren’t neutral. They’re curated.
The goal isn’t to catch mistakes. It’s to help editors succeed.
The platform itself has to take on more of that responsibility.
What’s not on the dashboard is equally revealing. We don’t have traffic metrics or analytics. For this particular higher ed institution, that’s a deliberate choice. The focus is on content quality and editor success, not marketing outcomes. For other clients we work with, traffic data would need to be front and center. The dashboard has to reflect what that organization actually cares about.

Login → see issue → click → fix
When a broken link shows up in a quarterly report, the path from seeing it to fixing it is long and uncertain. Someone reads the report, makes a mental note, hopes they remember. Most of the time, they don’t. By integrating that same information into the dashboard, the cycle changes:
A dashboard isn’t just a summary page. It’s a statement of priorities. Every item that appears, and everything that doesn’t, tells editors what the organization believes actually matters.
Director of Technical Strategy
It was better than nothing. But it had two serious problems.

March 17, 2026
When you subscribe to our newsletter!

• How we identified what editors needed versus what they asked for
• How we balanced editorial priorities with technical realities
• What we’d do differently if we were starting over

When your platform supports hundreds of editors across dozens of sites, traditional support breaks down fast. You can’t train everyone personally. You can’t answer every Slack message. And the editors who log in only a few times a year don’t have the context that frequent users build up over time.