fidzu : web

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.

It was better than nothing. But it had two serious problems.

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.

This is a pattern that's common across organizations: the information that would most help editors do better work exists somewhere, but it's separated from the moment when they're actually ready to act on it. Updates get coordinated in chat threads. Content issues arrive by email. Broken link reports live in spreadsheets.

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.

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.

That makes login the ideal moment to surface what needs attention.

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.

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.

The dashboard gave us a place to show a simplified view of those imports: here's when faculty profiles last synced, here's the kinds of courses that are imported to this site. Just enough to answer the question and build confidence. Support requests about content imports dropped significantly after we added that.

Information alone doesn't change much. The problem usually isn't awareness. It's timing.

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:

Quarterly report → read → maybe remember → maybe act later

becomes

Login → see issue → click → fix

The feedback loop collapses from months to minutes. A broken link becomes a clickable item. A page stuck in draft becomes a quick decision. A list of accessibility errors becomes something an editor can start working through today.

One practical note from experience: some data sources introduce delays. Our broken link list comes from Siteimprove via API, which means that when an editor fixes a broken link, it won't disappear from the dashboard immediately. We didn't think about that until after we launched. It's not a dealbreaker, but it's worth designing around. At minimum, set expectations with editors so a fixed link that still appears on the list doesn't feel like a bug.

Dashboards aren't neutral. They're curated.

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.

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.

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:

• 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?

Those questions don't always have obvious answers. But asking them is how you build something useful rather than something that just looks like a dashboard.

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.

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.

The same information can be framed very differently. A list of pages with accessibility errors isn't a punishment; it's a prioritized to-do list. A reminder about draft content that was never published helps an editor finish work that might otherwise be abandoned. A note that a component has recently changed gives editors a heads-up to check their pages before finding out something looks broken.

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.

The goal isn't to catch mistakes. It's to help editors succeed.

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.

The platform itself has to take on more of that responsibility.

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.

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.

A well-designed dashboard becomes a quiet guide embedded in the platform, helping editors move forward without needing someone from the platform team to step in. At scale, that kind of built-in guidance isn't just helpful. It's essential.

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.

We'll walk through:

• 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

Whether you manage one site or one hundred, we hope you leave with something you can use.

If you're going to DrupalCon Chicago 2026, please make sure to attend the session with Dave Hansen-Lange and Albert Hughes.

Where: Hilton Chicago, 720 S Michigan Ave, Chicago, IL 60605, Williford B (3rd Floor)

When: Tuesday, March 24, 2026, 9:00-9:50am

For session details and tickets, click here.