Fostering Collaboration in a Post-Cookie World

As privacy regulations tightened and third-party cookies declined, first-party data became the foundation of modern advertising. But sharing that data compliantly was slow, expensive, and stitched together across vendors.

With partial infrastructure already in place and a strong network of data partnerships, Oracle was well-positioned to build a solution that made data collaboration feel straightforward while addressing longstanding challenges across the advertising industry.

1. Design an interoperable system that lets customers curate solutions across our products and their own ecosystems.

2. Shift from a services-heavy model to a self-service experience without introducing new operational risk.

Our audience spanned brands, agencies, publishers, platforms, and data providers. They needed to understand and reach their customers more effectively, and deliver ads in high-quality environments. The product had to support that without overwhelming them.

This project involved significant information complexity. To get grounded in the system architecture, we started with stakeholder interviews to define the new business objects required for the platform. At the same time, we evaluated the existing products being folded into DCP, identifying opportunities to align or merge overlapping structures.

Working from documented use cases, user goals, and subject-matter expertise, we mapped the relationships between those objects and their associated actions to understand how they interacted and depended on one another.

We ran an open card-sorting exercise with key stakeholders, which surfaced common organizational patterns and mental models, ensuring the system could support both existing capabilities and future needs.

Several challenges emerged. The systems we sought to unify shared similar or redundant capabilities and terminology. For example, multiple products supported ways to bring data in or send it out, but served different use cases. The new platform had to accommodate those variations without adding unnecessary complexity.

Terminology was its own challenge. The advertising industry lacks a shared vocabulary, so the same concept is often described differently across organizations. The card-sorting exercise was especially useful here. By letting stakeholders group objects and assign their own labels, we could identify the language that felt most natural to them.

The patterns that emerged confirmed that an object-based navigation model provided the clearest structure.

To keep stakeholders informed and the work adaptable, we maintained a living site map: a visual representation of the product's current content structure and hierarchy. As requirements, user needs, and technical constraints evolved, so did the docs.

One issue that kept surfacing during the pilot was the absence of a shared vocabulary. Terms that felt precise to one user landed differently with others. This wasn't a significant problem at the top level of navigation, but it created friction deeper in the experience where content became more specific. We addressed it by defining product terminology clearly and making those definitions easy to access, both in context and in support documentation.

As the project grew in scope, we needed an efficient way to build alignment and buy-in from stakeholders and prospective customers. Working with my product partners, we defined a set of core use cases to anchor the work and demonstrate the platform's potential.

From there, I built a prototype in Figma for each one. I called them vignettes. Each told the story of a specific persona trying to accomplish a goal, playing out a scenario end-to-end: ingesting data, building and activating an audience, monitoring performance, and more.

Anyone in the organization could use the vignettes as a presentation tool to demonstrate product value and show how different parts of the system fit together.

With our GTM team's help, we recruited six customers to join a pilot program and participate in periodic user tests and feedback sessions during the critical MVP phase.

These customers helped us understand:

• Whether the product would meaningfully improve their existing workflows.
• The different ways they needed to manipulate their own data.
• Whether they could complete multi-step self-service tasks independently.
• Whether they could derive actionable insights from the platform.
• Whether our terminology matched their expectations.

Users don't arrive as blank slates. They bring habits and expectations shaped by every product they've used before. Something as seemingly small as a label can have an outsized impact on the overall experience.

If I were starting over, I'd invest more time upfront mapping those mental models before committing to navigation and terminology.