AI isn't the shift. What we design is.

AI is shifting product design from defining what a product does to defining how it makes decisions. As execution becomes easier, the constraint moves upstream, from production to definition, and from individual outputs to alignment across the teams shaping how products behave.

‍

The teams that win this shift will not be the ones using the best tools. They will be the ones aligned on what the product should do, why it matters, and how it behaves over time.

‍

Over the past year, I’ve been working closely with product teams navigating this shift. Across those teams, the pattern is consistent. Designers, product managers, engineers, and data teams are generating artifacts, testing workflows, and integrating these capabilities into daily practice. Concepts that once took days now take minutes. Interfaces are easier to produce. Code is easier to scaffold.

‍

But that acceleration has not removed the work. It has moved it upstream. The constraint is no longer production. It is definition.

‍

‍

Learn by doing

‍

Most organizations are still working through what AI means in practice. Teams are learning by doing, experimenting with new workflows, testing what is possible, and figuring out how these capabilities fit into their environment.

‍

Across the organizations and industries I’m working with right now, this is the pattern that keeps showing up. A small number of teams move fast, building momentum and pushing what’s possible. The rest of the organization is working through tooling decisions, token budgets, governance, security reviews, and how these workflows fit into existing delivery models.

‍

I see the same dynamic inside my own teams. Output accelerates quickly, but alignment doesn’t keep up at the same pace. It’s the natural shape of adoption when capability moves faster than the structures required to support it.

‍

‍

The paradigm shift

‍

The shift becomes clear when teams recognize that the problem is no longer production. For years, design focused on defining what a product does, screens, flows, and interactions were the primary way value was expressed. That model assumed predictable responses to user input.

‍

That assumption no longer holds. AI products interpret signals, respond over time, and make decisions that shape outcomes. The experience is shaped by behavior, not just interaction. You are no longer designing screens. You are designing decisions.

‍

‍If you're not defining how the product makes decisions, you're not designing the product.

‍

‍

Designing the intelligent layer

‍

Once the work is understood as decision-making, the structure becomes clearer. In the work we’re doing, products tend to break down along the same fault lines, not in execution, but in how behavior is defined.

‍

AI products operate across three connected layers. The Experience layer defines what should happen. The Intelligent Layer defines how decisions get made. The Interface layer defines how those decisions are expressed to the user.

‍

The challenge is alignment. Product defines intent. Data defines signals. Engineering implements constraints. Design shapes the experience. Without a shared decision model, those pieces don’t come together in a consistent way.

‍

This is where the distinction between generative and deterministic approaches becomes real. The goal is not variation. It is consistency. Decisions need to be predictable, traceable, and grounded in defined signals and rules. Generative capability expands what is possible, but without structure it introduces variability where alignment is required.

‍

‍

Faster output, deeper questions

‍

As output becomes easier, the work moves upstream and the questions change. Instead of asking how to build, teams have to decide what to define. What signals should the product pay attention to? How should it determine priority? When should it act, and when should it defer?

‍

These questions define behavior, yet they are often the least specified. I see this consistently across teams. Decisions are made incrementally, with different groups contributing pieces without a shared model.

‍

Over time, this produces inconsistency. The product behaves differently in different contexts, not by design, but because it was defined in parts.

‍

Hallucinations are often framed as model issues. In practice, they are definition issues. When decision logic is unclear, outputs become unpredictable. A model is not malfunctioning when it produces an unexpected answer to a poorly defined question. It is doing exactly what an undefined product does.

‍

The new normal

‍

This way of working is becoming the baseline. Design systems are evolving beyond component libraries into frameworks that encode logic and adaptability. Interfaces become one expression of behavior, not its source.

‍

This also makes ideas like “human in the loop” concrete. Where does the product act independently? Where does it defer? Where does it escalate? These are defined decision points, not abstract principles.

‍

In regulated environments, where we’re doing work across finance and healthcare, this becomes even more explicit. Consistency, traceability, and control are required by audit, not preference. Behavior cannot be inferred from training data. It has to be defined.

‍

Designing for value over time

‍

Most teams are doing the right thing. They are exploring, experimenting, and learning how to work with these capabilities. I see this across clients and within my own teams. That work matters because it reveals where the gaps are. But it is only the starting point.

‍

The most common mistake I see is optimizing for capability before alignment. Organizations invest in tools and outputs without defining how the product should behave as a whole. The work ahead is aligning around that definition and carrying it consistently across the product.

‍

Tools will continue to evolve. What matters is how clearly decisions are defined and how consistently they are applied. Because these products do not decide what matters.

‍

People do.

‍

And the next question is whether your design system is built to support them.