Designing the AI layer, not just using it.
Most teams add AI tools to an existing process. This project, an internal exploratory initiative within IKEA's digital experience design team, asked a different question: what does it look like to architect AI into a design workflow from first principles, with explicit checkpoints, structured agent roles, and a human decision layer that genuinely controls the output?
The wrong question was everywhere
The dominant question in design teams exploring AI was "which tool should we use?" The answer was almost always a product recommendation: a specific assistant, a specific plugin, a specific integration. Teams would adopt it, use it for a few weeks, and find that the outputs were inconsistent, the process was murkier than before, and nobody could explain why a particular output was good or bad.
The tool was rarely the actual problem. AI had been dropped into a process that had never been built to hold it: no defined phases, no agent roles, no checkpoints, no plan for what context needed to carry forward. Left like that, AI-assisted work doesn't fail loudly; it drifts away from the original intent while still looking plausible, and that's worse, because nobody catches it in time.
Treat AI like any other part of the system
What actually made this project work was refusing to treat AI as special. I gave it the same treatment I'd give any other design-systems problem: pin down the inputs, the outputs, the handoffs, and who's deciding what at each step.
Instead of asking what AI could do, I started asking where it actually belonged in the process and how we'd know if it was doing that job well. Harder question, more useful answer, and one that plays to a systems thinker's strengths, since it means understanding the whole flow before touching any single part of it.
Three tiers. Five phases. Human gates throughout.
The framework organises AI-assisted design work into a three-tier agent hierarchy operating across five defined phases. Each tier has explicit scope, defined inputs and outputs, and clear escalation paths to human decision-makers.
Two threads from the same structure
The framework wasn't built in the abstract. It emerged from two parallel workstreams inside an enterprise design team, both of which exposed the same underlying problem: AI without process produces work nobody can own.
Shape Up facilitation
Shape Up shaping sessions are cognitively intensive: multiple stakeholders, ambiguous scope, competing constraints. I designed facilitation workflows that use AI to support the shaping process: structuring the problem before the session begins, surfacing edge cases before pitches are written, and synthesising multi-participant outputs into pitch-ready documentation. The AI handles structure; the facilitator handles judgment.
Multi-agent orchestration for complex features
For features involving product, engineering, content, and business stakeholders simultaneously, a single-agent approach produces generic outputs that satisfy nobody. The multi-agent approach distributes the shaping task: one agent decomposes the problem, another maps constraints, another evaluates solution directions. Outputs are structured to flow into existing documentation formats, so the AI layer and the process layer are the same system.
Working this way asks more of a designer, not less
Most people assume AI-augmented workflows make a designer's job easier. In practice the job just moves: less time producing, more time directing, checking, and stitching pieces together. None of that is taught in a design programme, so the framework builds it in explicitly. Five habits carry most of the weight: reading a prompt like a brief instead of a spec, judging AI output fast without losing rigor, deciding what context survives from one phase to the next, catching when an agent has drifted off the original intent without anyone flagging it, and knowing which outputs need a second look versus a full re-check.
Design leads and systems thinkers tend to pick this up quickly, mostly because they're already reading process the same way; they just have to point that habit at a new kind of collaborator.
A framework that separates process from tooling
The most durable result of this work is a process architecture that is independent of any specific AI tool or platform. Because the framework defines phases, agent roles, checkpoints, and context management protocols at the process level, not the implementation level, it survives tool migrations, platform changes, and team turnover.
That separation also makes it teachable. The framework is now being shared through an active AI literacy programme for senior design professionals, with a focus on workflow design rather than tool use. The target audience is designers and design leads who already think in systems and are ready to apply that thinking to how AI fits into the process, not just what AI can do.
The framework itself is written up separately, in more depth than fits here, so another team can pick it up and adapt it rather than start from a blank page. It's built from the actual failure modes I ran into on this engagement, not a theoretical version of them.
Read the full framework (18 min) →
Your hardest problem
is a good place to start.
Open to senior product design roles and selective consulting engagements, in English or Spanish.