Adobe Brand Intelligence

The problem

Enterprise brand teams had spent decades building the rules: color systems, typography hierarchies, tone-of-voice guidelines, logo usage standards. Most of it lived in PDFs. None of it was machine-readable. None of it could talk to an AI model.

When those same teams started using Firefly to generate content at scale, the results were technically impressive and brand-agnostic. Firefly didn't know what "on-brand" meant for Nike, or Coca-Cola, or any other enterprise customer. Brand guidelines existed in one world; AI generation existed in another. The gap between them was costing teams hours of manual correction on every campaign.

The problem wasn't adoption. It was governance, and governance at scale is a design problem as much as an ML one.

The first attempt, and why it wasn't enough

The initial instinct was the same one most of the industry landed on: take existing brand guidelines, inject them into a prompt, add some engineering around it, and let the LLM do the rest.

It worked, sometimes. On clean, structured guidelines with simple visual rules, results were promising. But enterprise brands aren't clean or simple. Their guidelines are dense, contradictory, and written for human judgment. The more nuanced the brand, the less reliably the model could interpret and enforce it. At scale, "works sometimes" isn't a product. It's a liability.

We went back to the drawing board. The question shifted from how do we get an LLM to follow brand rules to something more fundamental: what does it actually mean for a machine to understand a brand?

The ML foundation: a different kind of solution

The answer the ML engineering and leadership team arrived at, after a period of focused experimentation, was that you can't prompt your way to brand fidelity. You have to build toward it.

The approach that emerged centered on three core ideas:

Custom ontologies. Rather than describing brand in natural language and hoping a general-purpose model could interpret it, we developed structured representations of brand identity: formal vocabularies that encode visual, tonal, and compositional attributes in a form the system can reason over precisely.

Knowledge graphs. Those ontologies feed into brand-specific knowledge graphs that model how a brand's elements relate to each other. It's not just "this brand uses this color"; it's the logic of when, how, and in relation to what. The graph captures brand reasoning, not just brand data.

A series of fine-tuned models. Built on top of that structured representation, a family of purpose-built models powers the core capabilities: validation (does this asset comply?), generation (produce something that does), and synthetic audience modeling (will this resonate with the intended audience?). Each model is trained against the brand's actual assets and guidelines, not against a prompt approximation of them.

The result is a system with genuine IP at its core. Not prompt engineering dressed up as intelligence, but a defensible, scalable ML architecture for brand understanding.

The shift wasn't incremental. It was architectural. Moving from "LLM plus guidelines" to "custom ontologies plus fine-tuned models" changed what the system could reliably do, and how far it could scale.

My role

Adobe Brand Intelligence was an ML engineering and leadership-led initiative at its foundation. I led design with a small, focused team: two designers working across a cross-functional group that included ML researchers, PMs, and Field Design Engineers (FDEs) who would ultimately be responsible for implementation with enterprise customers.

My role spanned three distinct modes:

• Problem excavation: Working with ML to understand what was actually possible, what wasn't, and what we didn't yet know
• Design direction: Shaping an experience that made brand governance feel like a creative tool, not a compliance checklist
• ML collaboration: Using design as a pressure-testing instrument against an evolving technical foundation

That last mode was the most unusual, and the most consequential.

The design challenge

We weren't designing for a stable product. We were designing in parallel with an ML team that was still discovering what was achievable.

What was possible in April might not be possible in May. What seemed out of reach in Q1 was sometimes unlocked by Q3. The interaction model had to be both specific enough to be useful and modular enough to absorb capability changes without requiring a full redesign every time the ML team hit a wall, or broke through one.

The pivots were real and frequent, driven by a combination of new customer insight from pilot brand teams, shifts in what the ML could reliably produce, and quality thresholds that kept moving as the models improved. Designing through that required a particular kind of discipline: know when to commit, know when to hold, and never let the team mistake motion for direction.

The 140+ element taxonomy

The most consequential design contribution on this project wasn't a screen. It was a framework.

Early in the process, it became clear that neither the design team nor the ML team had a shared language for what "brand" actually meant at the level of a generative model. Brand guidelines are written for humans; they describe intent, not parameters. The knowledge graph and ontology work needed something more precise on the design side too.

I went deep on this problem and built out a taxonomy of 140+ discrete design elements that a brand-aware AI system would need to understand and respect, spanning visual identity, typographic behavior, color application logic, compositional rules, imagery tone, iconography style, and more.

This not only gave the ML team a structured problem surface to experiment against but it also helped expose gaps in what the models could reliably handle versus what brand teams actually needed. Pressure-testing ML capability through a design lens, and doing it systematically, is how we caught issues early rather than late, and how we helped steer the ML roadmap toward what mattered most to customers.

Key design decisions

Modular UX against a moving ML foundation

Rather than design monolithic flows locked to specific ML capabilities, we built the experience in composable modules, each mapping to a discrete brand dimension. When an ML capability wasn't ready, that module could be deprioritized without breaking the overall experience. When a new capability came online, it could be surfaced without a redesign.

This modularity wasn't just a technical hedge. It reflected a genuine belief that brand identity is layered, and the UI should reflect that structure, not flatten it. It also mirrored the architecture: discrete models for discrete capabilities, orchestrated into a coherent system.

FDE-first implementation path

Field Design Engineers are the implementation layer between Adobe's product and enterprise customers. If they couldn't configure and deploy Brand Intelligence confidently, the product didn't reach the people it was built for.

Working closely with FDEs throughout the process, treating them as a primary audience alongside brand managers, shaped the configuration model, the error states, and the documentation strategy in ways that wouldn't have emerged from user research alone. They also surfaced the real-world messiness of enterprise brand assets: inconsistent file formats, legacy guidelines, competing brand sub-architectures across business units. The system had to handle that complexity gracefully.

Outcome

Adobe Brand Intelligence shipped as a live capability within Firefly Enterprise, a product that didn't exist in any form two years ago. Enterprise brand teams can now upload their guidelines and have Firefly respect them in generation, with a degree of comprehensiveness and fidelity that defines a new category of brand-aware AI.

The key word is fidelity. Not "usually on-brand." Not "needs a human review pass." Fidelity that's repeatable, scalable, and grounded in a genuine ML architecture, not a prompt that holds up until it doesn't.

The outcome I'm most proud of isn't the product, though. It's the team.

Two designers navigating ML ambiguity, shifting capability constraints, and a cross-functional group that spanned research, engineering, and field implementation, and doing it without losing momentum or craft standards. The ability to stay steady, stay curious, and keep making good decisions under conditions of genuine uncertainty is a hard thing to build in a team. We built it.

What I'd do differently

The 140+ element taxonomy was the right instinct, but I'd formalize it as a shared artifact much earlier and get explicit ML sign-off on it as a north star document. In practice, it evolved organically and required constant re-socialization. A more structured alignment moment around it at the start, one that explicitly connected design dimensions to ontology structure, would have saved cycles mid-project.

When you're designing with an ML team building novel architecture, the most valuable thing design can do is make the problem legible. Next time, I'd do that early, do it formally, and make sure everyone knows it's the map, not just a design deliverable.