Datadog Campaigns

Datadog’s IDP Scorecards helps platform teams define engineering standards and evaluate whether services, repositories, and other entities meet them.

But platform, security, and reliability teams also run time-bound initiatives that require coordination across multiple teams, such as upgrading Kubernetes, fixing dependency issues, reducing cloud costs, or addressing security findings.

Scorecards could show whether teams met ongoing standards, but it wasn’t designed to manage these initiatives. Teams needed a way to define who was responsible, which services and teams were involved, when the work was due, and how much progress had been made.

Through customer calls and feedback from internal users, I identified recurring challenges teams faced when coordinating time-bound initiatives across multiple teams. Ownership, progress updates, and follow-up actions were often scattered across tools like Jira, Slack, and team docs.

This made it difficult to see who was responsible, how much progress had been made, and what needed to happen next. Teams lacked a single place to understand the status of an initiative and take action on the work that remained.

Our goal was to help teams create and run time-bound initiatives with clear ownership, visibility into progress, and a clear path to completing the work on time.



Rather than starting from scratch, we built on the Scorecard rules users already had. By adding scope, participating teams, ownership, and a timeline around those rules, we could turn ongoing standards into actionable initiatives with clear goals and accountability.

This led us to create a new product called Campaigns. It gives teams a shared place to define an initiative, identify the teams and services involved, assign ownership, and track progress toward a deadline.

By building on the data and workflows already in Datadog, Campaigns reduces the need to coordinate work across spreadsheets and other tools. The goal was to turn an initiative into clear, actionable work that teams could understand, own, and complete together.

Campaigns has two main user groups. Platform engineers need to create and manage campaigns. Developers need to know which of their services are included and what work they have to do.

These needs led us to focus on three core areas: creating, running, and managing campaigns.

The creation flow would let users define a campaign’s purpose, scope, rules, ownership, and deadline. Once a campaign was running, users needed a place to understand the initiative, take action, and track progress. They also needed a way to manage campaigns over time, including viewing active campaigns, updating their status, and archiving completed work.

started with campaign creation, which would primarily be handled by platform teams. They needed to define the campaign’s purpose, choose the relevant Scorecard rules, set ownership and a timeline, determine which teams and services were in scope, and provide clear guidance on what participating teams needed to do.

I organized the creation flow into three parts: defining the campaign and its purpose, setting ownership and a timeline, and defining the scope with a preview of the teams and services involved.

I translated this flow into an initial wireframe. The form on the left guided users through defining the campaign, while the preview on the right showed which entities and teams were in scope, along with their evaluation results.As the design evolved, I added a dedicated step for guidance and consolidated the earlier steps to keep the overall flow to three steps.

I initially explored structured action items, but each initiative required different types of guidance. We chose a Markdown editor instead, giving campaign owners the flexibility to provide instructions, images, and links without being limited to a fixed format.

I then focused on making the preview more useful. I explored different ways to show the campaign scope, participating teams, selected rules, and current evaluation results, along with contextual setup guidance.

Rather than simply repeating what users entered in the form, the preview showed what those choices meant in practice. This helped owners understand the campaign’s impact and catch unexpected entities or evaluation results before launching it.

The campaign detail page was the center of the experience. It needed to give everyone a shared view of the campaign while helping each person focus on what mattered to their role.



Campaign owners needed to see overall progress, team status, ownership, and deadlines, with ways to follow up when needed. Developers needed to quickly find their own entities, see which rules they still needed to meet, and understand what actions to take.

I organized the page from a high-level summary down to more detailed information.

The header showed the campaign name, owner, timeline, description, and key actions.

Below that was an overview of the campaign’s progress, followed by individual entities where users could see how much of the required work had been completed.

This hierarchy was designed around the needs of different users. Shared campaign information came first, while the more detailed entity-level information that developers would use more often came below.

As I moved into high-fidelity design, I explored different ways to organize the information. I focused on what to prioritize, how much information to show at once, and how to make important details easy to find.

---

 
The management page gave users a place to step back and see multiple campaigns in one place.

Platform engineers needed to track status, timelines, and completion rates, and make changes when needed. Leaders needed a broader view of progress across teams and initiatives.

For the wireframe, I created a list of all campaigns, with navigation and filters to help users focus on what was relevant to them.

Each campaign showed key information such as its name, status, scope, timeline, and overall score.

This made it easier to review progress, spot campaigns that needed attention, and take the next step, whether that was viewing details, editing a campaign, or updating its status.

As I moved into high-fidelity design, I explored several layouts, including tables, standard cards, and horizontal cards. I compared how well each option helped users scan key campaign information and compare progress across multiple campaigns.

I also considered how the layout could give Campaigns its own visual identity while clearly distinguishing it from the existing Scorecards experience.

Now, users can create rules and define their evaluation logic directly in Datadog. They can choose an evaluation method, write and test the logic, and preview results on real entities before applying the rule.

Once a rule is created, its source, evaluation method, logic, and results are clearly visible, making it easier to understand how the rule works and investigate issues. Users can also see key differences at a glance when managing multiple rules.

This makes the overall experience more transparent and reduces the need to build and maintain evaluation logic in external systems.

In the first three months, 46 organizations created 89 campaigns, showing early adoption of the new experience.

Customer feedback also reinforced the value of bringing this work into Datadog. One customer used Campaigns to track security initiatives that had previously been managed in spreadsheets. Another expected it to save significant time compared with their existing process. A third used it to coordinate upgrades and retire outdated functionality across the organization while maintaining service maturity standards.

These early signals showed that Campaigns was addressing a real need and helping teams manage cross-team initiatives with greater visibility and less manual coordination.

---

Building Campaigns also gave me a few lessons that shaped how I approach product design. Here are three that stood out.