EEM FAQ

EEM is a framework for AI-native product development. It consists of five stages—Input, Execute, Solution, Governance Gate, and Production—with four operating principles called Pillars.

Unlike traditional workflows that emphasize planning before making, EEM recognizes that AI tools make execution fast and cheap, so learning happens through making rather than planning.

The five stages are:

• Input: The catalyst—research, strategy, hunches, or requirements plus design system constraints
• Execute: The heart of EEM where AI agents build functional prototypes
• Solution: Multiple tested variants ready for judgment
• Governance Gate: Human judgment determines what advances
• Production: Deliberate commitment to ship

• Execution Absorbs Uncertainty: Learning happens through making, not planning
• Inputs Are Variable: Starting points can be research, strategy, or hunches
• Outputs Are Experiments: Solutions are testable candidates, not conclusions
• Production Is Deliberate: Shipping is a conscious choice, not a default outcome

Execute is where value is created. In traditional workflows, execution was expensive and risky, so teams planned extensively to reduce uncertainty before building. With AI, execution is fast and cheap—so it becomes the primary learning engine.

Instead of planning to learn, you make to learn. Multiple functional prototypes replace extensive planning documents.

EEM shares values with both—iteration, learning, reducing waste. The key difference is in execution assumptions:

Lean UX minimizes waste because execution is expensive. EEM maximizes learning because execution is cheap.

Agile works in sprints; EEM can produce multiple iterations per day.

No. Research remains valuable—it informs inputs and helps interpret what you learn from execution. What changes is that research doesn't have to provide certainty before you start building.

You can start with incomplete understanding and let execution reveal what matters. Research shifts from "answer everything before building" to "inform what we build and help us understand what we observe."

Because AI makes it cheap to explore. When execution was expensive, converging on a single solution early made sense. Now you can build 2-5 variants and let stakeholders compare real options.

This surfaces trade-offs that wouldn't be visible with a single solution. Governance becomes richer when comparing actual working software, not theoretical concepts.

The essentials are:

• Design system documentation: Components, tokens, and patterns that AI can reference
• Access to an Agent IDE: Cursor, Windsurf, Bolt, or similar
• Governance capability: People who can make go/no-go decisions
• Willingness to iterate: Comfort with working software over polished mockups

It depends on your starting point, but a typical timeline:

• Crawl (weeks 1-4): Learn tools, run one pilot project
• Walk (weeks 5-12): Apply to multiple projects, establish governance
• Run (months 4-12): EEM becomes the default workflow

Teams with mature design systems and AI-curious designers can move faster.

No. Start with a single pilot project—ideally an internal tool or low-stakes feature with forgiving stakeholders. Prove value, learn what works for your context, then expand gradually.

All-or-nothing transformations tend to fail. EEM adoption should be iterative, just like EEM itself.

You can still use EEM, but with more preparation work. Without a design system, AI agents have less to reference, which means:

• More time in traditional design tools (Figma, etc.) to establish patterns
• More iteration to achieve brand consistency
• Risk of inconsistent outputs across projects

Consider building a basic design system as part of your first EEM pilot. Document what you create so future projects can reference it.

• Skipping governance: Speed without review produces chaos
• Single solution mindset: Only building one option defeats the purpose
• Designers coding: They should direct and evaluate, not implement
• No design system: AI needs constraints to produce consistent results
• Isolating stakeholders: They should engage with working prototypes early

Key metrics to track:

• Velocity: Time from Input to Production
• Variants produced: Are teams creating multiple solutions?
• Stakeholder engagement: Are they reviewing working software?
• Governance efficiency: Clear decisions being made?
• Design system growth: Is the system evolving through use?

An Agent IDE is an AI-powered development environment where you direct AI agents to write code. Examples include Cursor, Windsurf, Bolt, Replit, and v0.

Instead of writing code yourself, you describe what you want, the AI generates it, and you evaluate the result. Think of it as having a fast, tireless junior developer who can produce code instantly but needs guidance on quality and direction.

It depends on your context:

• Cursor: Powerful for teams comfortable with VS Code, handles complex projects
• Windsurf: Similar to Cursor, designed for agentic workflows
• Bolt: Browser-based, good for quick prototypes without local setup
• Replit: Collaborative, good for teams new to coding environments
• v0: Specializes in UI components, excellent for rapid UI iteration

EEM is tool-agnostic. Use what fits your team and project.

It depends on your design system maturity:

• Mature system: You can often skip Figma and go directly to Agent IDE
• Immature system: Figma helps establish patterns that AI can then follow
• Complex interactions: Visual thinking in Figma may still be valuable

Figma isn't eliminated—its role shifts. It becomes a prep tool when needed, not the primary output artifact.

For best results, AI agents need access to:

• Component documentation: Props, states, variants (Storybook is ideal)
• Design tokens: Colors, spacing, typography values
• Usage patterns: How components combine, common layouts
• Brand guidelines: Voice, tone, visual principles

The more context you provide, the more on-brand the output will be.

Tokens should live in code as the source of truth. Common approaches:

• Style Dictionary: Platform-agnostic token management
• Figma Variables: For teams still using Figma heavily
• Tokens Studio: Figma plugin that syncs with code
• CSS custom properties: Simple, works everywhere

The key is that tokens are code-accessible so AI agents can use them correctly.

No. Designers need to be comfortable evaluating code output and directing AI agents, but they don't need to write code themselves.

Think of it like directing: you need to know when a scene works and how to ask for adjustments, but you don't need to operate the camera. Designers judge quality, prompt changes, and decide when something is ready.

Four key roles:

• Product Strategist: Defines inputs, ensures alignment with business goals
• Execution Designer: Directs AI agents, evaluates output quality
• Design System Steward: Maintains system integrity, documents patterns
• Production Engineer: Ensures solutions are production-ready

These roles may overlap on smaller teams. The key is that all functions are covered, not that each is a separate person.

Designers shift from makers to directors:

• Before: Create pixel-perfect mockups, hand off to developers
• After: Direct AI agents, evaluate working software, iterate rapidly

The skills that matter: articulating what's needed, recognizing quality, understanding component thinking, and design system fluency. Craft becomes direction.

Developers become more valuable, not less. Their role shifts toward:

• Architecture: Ensuring AI-generated code fits the system
• Production: Making prototypes production-ready
• Complex problems: Tackling what AI can't handle well
• Design system: Building and maintaining the component library

AI handles routine implementation; developers focus on harder, more valuable work.

Look for these traits:

• Designers: Comfort with code, rapid iteration mindset, strong judgment, design system thinking
• Developers: Architecture skills, production rigor, component thinking, mentoring ability
• Both: Curiosity about AI tools, comfort with ambiguity, collaborative nature

Portfolio reviews should include how candidates evaluate and iterate on work, not just final outputs.

Focus on:

• Agent IDE fluency: Hands-on practice with prompting and evaluation
• Component thinking: Understanding props, states, variants
• Rapid iteration: Getting comfortable with "good enough to test"
• Design system contribution: Documenting what they learn

Pair experienced EEM practitioners with learners. Show, don't tell. Let them experience the speed and iterate on real projects.

Governance typically includes:

• Product leadership: Strategic fit, business value
• Design leadership: Brand, UX quality, system coherence
• Engineering leadership: Technical feasibility, production readiness
• Stakeholders: Domain expertise, user advocacy

The specific composition depends on your organization. The key is clear decision authority and documented outcomes.