From AEM Complexity to Operational Visibility

For years I supported the shopping-banner and airport gate-display systems that power parts of Delta's digital and physical customer experience, and the content infrastructure underneath them is genuinely complicated. A single shopping banner depends on multiple interconnected AEM configurations, rules, and assets spread across environments, and the shopping experience has numerous placements, each with its own conditions governing what appears and when. The airport gate information display screens pile on another layer, with content configurations spanning multiple airports, placements, date ranges, and display conditions. All of that information existed somewhere. What didn't exist was a simple way to see it.

The Problem

One of the most common questions from stakeholders sounded easy: "What banners are live on the site right now?" Answering it could mean manually digging through configuration files and AEM locations, cross-referencing content against its rules and conditions, and keeping the interactions between all those pieces straight in your head. The configurations could even lie to you. Content might sit in a config file without ever reaching a customer because its conditions weren't active, and the reverse happened too, where the system treated content as "live" when its display dates had already passed.

So there was a real difference between "Is this content active in AEM?" and "Is this content actually showing to the customer?", and no report answered the second question. The gate screens had the same problem. Marketing and airport-experience stakeholders needed to know what was running on screens at different airports, and there was no practical way to inspect the whole system at a glance. The information was there. The visibility wasn't.

The Opportunity

The AEM configuration data already held enough to reconstruct the actual state of these systems. The hard part was turning that raw material into something a person could use. Working with Kiro, I built dashboards that pull the relevant configurations together and interpret the relationships between them, so instead of asking a stakeholder or a content teammate to navigate AEM and understand its architecture, the dashboard just shows them a visual operating picture. Work that used to demand specialized knowledge and a lot of manual digging now reads at a glance.

Shopping Banners Dashboard

The Shopping Banners Dashboard gives a consolidated view of the banners currently configured across the shopping experience. It pulls together information about:

• Active banners
• Placements
• Rules and conditions
• Images
• Date ranges
• Available and occupied slots
• Production and staging environments

Each banner shows up as a visual card, so you see the actual creative next to the configuration that controls it, and the card links straight back to the relevant AEM location. That last part matters more than it sounds. The dashboard doesn't just say "here's a problem." It tells the content team, "here's the problem, and here's exactly where to go to fix it."

Comparing Production and Staging

One of the most useful things the dashboard does is compare environments. Production and staging are supposed to stay in sync, but small differences creep in over time as someone changes a configuration in one place and never mirrors it in the other. The comparison view surfaces those discrepancies and links directly to the AEM content that needs correcting, which turns an investigation that used to mean opening file after file into a visual diagnosis. Find the difference, trace the source, click through to the fix.

Airport Display Viewer

I took the same approach to the airport gate screens. What shows on a given screen depends on conditions like time of day, flight status, and airport location, with multiple configurations, placements, and display rules interacting to decide what appears at any moment. You can't understand what's configured without understanding how those pieces fit together, so the Airport Display Viewer reconstructs all of it into a single visual picture of the system. Stakeholders can see:

• Which content placements are active
• Which placements are available
• What creative is being displayed
• Which airport or location it applies to
• What rules and conditions govern it
• Relevant date ranges
• Production versus staging differences

For the people responsible for marketing and airport experience, this was visibility they'd never had. They could finally see the state of an environment they couldn't realistically inspect themselves. Someone in Atlanta can't walk over to a gate in Seattle to check what a screen is showing, and the dashboard is the next best thing: a reliable view of what the system is configured to display.

Designing for More Than Experts

As the dashboards grew, so did their capabilities. Filtering, sorting, comparison, exporting, reference material, and more got added over time, and that created a new problem. Complexity itself becomes a usability problem. A tool built for the content team can easily intimidate someone who just needs to answer one simple question. So I built contextual help right into the dashboards: numbered interface explanations, tooltips, reference information, and links to process documentation. I folded in the existing process guides too, which turned the tools into more than a place to look at information. They became a place to do the work. A content author can learn how a part of the system behaves, check its current state, spot something that needs to change, and jump straight to the right AEM location. The point was to make the expertise buried in the system available to people who don't live inside it every day.

From Dashboard to Operational Hub

That evolution is the part of the project I like most. The dashboards started as a way to answer questions that were painful to answer by hand, and they turned into something more useful than that: a shared operating interface for a complicated content ecosystem. They give stakeholders self-service visibility and content teams a way to diagnose problems, they draw a direct line from information to action, and they carry the documentation you need to make sense of the systems in the first place. The result is one place where people can see, understand, investigate, and act.

Impact at a Glance

The Result

The dashboards changed what the content team and its stakeholders could see. Questions that used to eat hours of manual investigation get answered immediately. The content team can spot a difference between production and staging and go straight to its source. Stakeholders can check what content is configured across the website, app, and airport screens on their own, without someone translating the AEM structure for them.

Leadership noticed, which matters most of all. After these dashboards came together, leadership asked me to look at applying the same approach to a broader Messaging Dashboard that would gather campaign activity across channels, including airport displays, the website, the app, and homepage experiences. That work is still in progress, but the request itself is the real outcome. The dashboards proved this kind of operational visibility was worth building into a wider organizational capability.

What This Demonstrates

Operational Visibility

Turning complex, distributed system data into an understandable view of what is actually happening.

Information Architecture

Designing an interface that makes relationships between content, rules, placements, environments, and conditions understandable.

Self-Service Enablement

Giving stakeholders the ability to answer questions independently rather than relying on specialized team members.

Process & Knowledge Management

Embedding process documentation, reference material, and contextual guidance directly into the tools people use to perform their work.

AI-Assisted Development

Using Kiro to rapidly transform raw JSON data into increasingly sophisticated operational functionality, iterating on the tools as new needs emerged.

Operational Excellence

Connecting visibility directly to action — so that identifying a problem also provides a path toward resolving it.

The Bigger Lesson

A complex system doesn't have to get simpler on the inside to get easier to use. Sometimes the better move is to lay a good layer of visibility over the complexity that's already there. The AEM infrastructure behind these experiences is still intricate, and the rules, relationships, environments, playlists, and configurations haven't gone anywhere. What changed is the team's ability to see them. By turning raw system data into an interface people can actually read, the dashboards took an environment that used to require specialized knowledge and endless manual digging and made it something you can explore, understand, and act on. The information was always there. The dashboard made it visible.

Tools & Technologies