Firefly Creative Production

The problem

Enterprise creative teams weren't failing to adopt AI because they didn't want it. They were failing because they couldn't operationalize it.

Three signals converged at once: creative teams were too dependent on engineers to trigger AI jobs, marketing orgs couldn't connect Firefly to the content pipelines they already ran, and there was no mechanism to make repeatable AI-assisted creative tasks run at scale. Every new campaign still started from scratch. Every workflow lived in someone's head.

The market wasn't cleaner. In 2024, the landscape of models, APIs, and enterprise AI patterns was shifting fast enough that designing for any single future felt like a bet we'd likely lose.

My role

I led design for Firefly Creative Production as Director of Design within the Firefly Enterprise org, owning the full design arc from problem framing through production. My day-to-day spanned:

• Setting the design direction and interaction model for the core canvas experience
• Leading a multi-disciplinary pod through sustained ambiguity across product, engineering, and research
• Partnering closely with engineering on Spectrum component integration to ship dynamic UIs for non-technical personas
• Holding the team's focus and momentum through a period of significant internal misalignment at the leadership level

That last part matters. For a stretch of the project, strategic direction at the top was unresolved. Rather than wait for clarity to arrive, I made a deliberate choice: protect the team from the noise, maintain momentum on what we could control, and keep shipping. The work became the forcing function for alignment, not the other way around.

The design challenge

The surface-level challenge was making a node-based, technically complex interface legible to non-engineers: marketing coordinators, content ops leads, brand managers who had never thought in terms of pipelines or graphs.

The deeper challenge was designing something durable in a market that was rewriting its own rules every quarter.

The question wasn't "what does Firefly Creative Production do today?" It was "what does it need to stay true to as the underlying models change around it?"

My answer was to anchor design decisions to workflow jobs-to-be-done, not to specific AI capabilities. If a user's core job was "take a finished layout and generate 40 regional variants without touching Photoshop," that job was stable even if the model powering it changed. We designed the interaction model around the job, and treated the AI layer as configurable infrastructure beneath it.

Simultaneously, I staged design bets across multiple plausible futures, keeping the system extensible enough to absorb model changes without requiring a design rearchitecture each time.

The pivot

Midway through the project, the lack of top-down strategic alignment created a real inflection point. Decisions that should have been made at the leadership level weren't getting made, and the resulting ambiguity was starting to bleed into team morale and scope creep.

I made a deliberate call to scope the work to what we owned and could ship with integrity, rather than design for a strategy that hadn't yet committed to itself. That decision clarified the team's energy and ultimately produced a tighter, more defensible product. It also gave leadership something concrete to align around: a working product is harder to argue with than a roadmap deck.

Key design decisions

Dual-view toggle: Build Inputs / Build Nodes

One of the earliest and most debated decisions was the dual-view model. Non-technical users needed a clean, form-driven interface to configure workflows (inputs, parameters, outputs) without ever seeing a graph. Power users and technical admins needed the full node canvas to understand and modify the underlying logic.

The toggle between Build Inputs and Build Nodes views wasn't just a UI pattern; it was a position on who gets to own workflow configuration and at what level of abstraction. It let us serve both audiences without compromising either.

Spectrum component integration for dynamic UIs

Rather than build bespoke UI for each workflow type, we invested in a composable system using Adobe Spectrum components to generate dynamic configuration interfaces. This meant that as new AI capabilities were added to Firefly, the UI could adapt without design rework.

This decision had a secondary effect: it brought design and engineering into an unusually tight collaboration loop. We weren't handing off specs; we were making architectural decisions together about how components composed at runtime.

Outcome

Firefly Creative Production shipped as a live capability within Firefly Enterprise.

But the outcome I'm proudest of isn't a feature; it's what the team became in the process of building it.

Our pod didn't just design Firefly Creative Production. We pushed production code. Designers on my team were writing and merging commits, working directly in the codebase alongside engineers, and reducing the handoff gap to near zero. This wasn't a strategy I mandated; it emerged from a culture of ownership I tried to build from day one.

The result got noticed. I was invited to speak about our team's working model at Adobe's company-wide AI Day, not to present a product, but to present a way of working. The pod became an internal example of what design-engineering collaboration looks like when you remove the artificial boundaries between the two disciplines.

What I'd do differently

Navigating internal misalignment by protecting the team and shipping was the right call, but it also meant absorbing significant strategic uncertainty personally. In hindsight, I would have created more explicit, documented decision points earlier in the project to surface the misalignment and force resolution, rather than routing around it through execution.