Beyond Static Mockups: How AI Agents Are Changing My Design Workflow

By Mārtiņš Zemlickis

Most designers are still handing off static PNG files and hoping developers interpret their intentions correctly. Meanwhile, product owners struggle to understand complex features from flat mockups, and user testing requires elaborate setups that take weeks to prepare.

After months of experimenting with AI agents in my workflow, I've developed a process that generates interactive prototypes using our existing design system components. It's not perfect, and it's definitely not magic—but it's changed how I collaborate with product teams and conduct user research. Learn more about my experience.

The Traditional Handoff Problem

The standard design process looks familiar: product meetings, wireframes in Figma, lengthy specification documents, developer handoffs, and eventually something that might resemble your original vision. Each step introduces interpretation gaps, and by the time you're testing with users, you're often validating something quite different from what you designed—or what you test is light years ahead of what actually reaches production.

Enterprise environments make this worse. Complex business logic, legacy system constraints, and distributed teams mean the gap between design intent and final implementation can be enormous. I've seen designers spend more time explaining their designs than actually designing. For more on managing responsibilities in these handoffs, check the Nielsen Norman Group guidelines.

Enter the AI Agent Workflow

Here's how my process works now, step by step:

Step 1: Design Meetings and Component Wireframing

After product team meetings, I create interface wireframes using our existing Figma components. Nothing revolutionary here—this is standard practice. The key difference is I'm now thinking in terms of component combinations and interactions from the start, not just visual layouts.

Step 2: AI Agent Component Development

This is where things get interesting. I take my Figma wireframes to an IDE agent and work out what new components need to be created or modified. The agent helps translate design requirements into interactive Storybook components that work within our existing design system.

Specifically, I use Cursor with Claude 4.0 agent, configured with custom rules and MCP servers that restrict the agent to our design library. This setup prevents the agent from randomly building components from other design systems—something that happened frequently before implementing these constraints. The rules ensure consistency with our established patterns and prevent the agent from inventing new approaches when existing solutions already work.

The agent doesn't magically create perfect components—it's more like pair programming with someone who never gets tired of iteration. I provide design context, business logic, and interaction patterns, while the agent handles the technical implementation details.

The Nested Component Strategy

Here's where my approach differs from typical component development: I always use a nested approach, starting with the smallest atomic pieces and building upward, following principles from Atomic Design. When prompting the AI agent, I reference specific component links from our existing library that I want to incorporate or build upon.

For example, if I'm creating a complex data table, I start with individual cell components, then row components, then header components, before assembling the complete table. Each level references the components below it through direct links in my prompts. This keeps everything connected and maintainable.

The real power comes from the cascade effect: when I need to adjust spacing or styling in the smallest atomic component, the change automatically propagates through the entire nested system in Storybook. Instead of hunting down every instance where that component is used, I update once at the source and everything else follows.

Example: Referencing Components in Prompts

Here's how I structure prompts to maintain consistency with our design system:

// Reference existing button component
Use this base button component: /components/Button/Button.tsx
- Extend with new 'variant="outline"' prop
- Maintain existing size variants (sm, md, lg)
- Follow current spacing tokens: --spacing-small, --spacing-medium
- Use design system colors: --color-primary, --color-secondary

// Nest within existing card component
Compose this within: /components/Card/Card.tsx
- Use Card.Header for title section
- Apply Card.Body for content area
- Reference Card spacing patterns

// Mock data requirements
Generate realistic data with:
- 15-20 entries minimum
- Variable text lengths (5-100 characters)
- Include edge cases: empty states, long content, special characters

Step 3: Data Preparation and Layout Planning

Before diving into Storybook development, significant effort goes into data preparation. The business side often has sensitive data they can't share for prototyping, which means I'm constantly creating mock data either by hand or with AI assistance. This isn't just filling in placeholder text—it's crafting realistic data sets that properly stress-test components with edge cases, varying content lengths, and different data types.

Layout work requires careful pre-planning of rows and columns. I've learned to map out grid systems and responsive breakpoints before starting component development. People tend to forget this foundational step and jump straight into building, but without proper layout planning, you end up refactoring everything when real content doesn't fit your assumptions.

The atomic design principle becomes critical here. Too many designers skip the referencing step and try to build complex components from scratch. My process forces you to build from atoms to molecules, always nesting and always referencing existing components. It's more work upfront, but it prevents the chaos of disconnected components that don't play well together.

Step 4: Isolated Development and Testing

Using Storybook's isolated environment, I can build and test components without affecting the main application. This means I can experiment with complex interactions, edge cases, and different data states without breaking anything or waiting for development cycles.

Step 5: Cloud Sync and Team Collaboration

Once components are working, they go to our cloud environment where other designers can access and sync them. No more "it works on my machine" problems or version control nightmares with design files.

Creating a special space for designers within our Storybook environment has been crucial. This allows the entire design team to follow and improve upon both developer-created components and our own designer-generated components. Instead of working in silos, designers can see what developers have built, understand technical constraints, and contribute their own components that complement the existing system. This shared space bridges the traditional gap between design and development workflows.

Step 6: Direct Stakeholder Access

Here's the game-changer: I can share direct links to interactive mockups with business analysts, product owners, developers, and designers across teams. They're not looking at static images—they're interacting with functional prototypes that behave like the real product.

Step 7: Advanced User Testing

For user research, I set up complex Storybook component configurations that simulate real user flows. Participants interact with actual interface elements, not clickable hotspots in a prototype tool. The data and insights are significantly more valuable.

What This Actually Solves

The workflow addresses several persistent problems in enterprise design:

  • Interpretation Gaps: When stakeholders interact with functional prototypes, there's less room for misinterpretation. Complex business logic and edge cases become immediately apparent instead of emerging during development.
  • Development Alignment: Developers receive components that already work within our technical constraints. Instead of interpreting design specifications, they're integrating proven components into the larger application.
  • Research Quality: User testing with interactive prototypes provides more realistic feedback. Participants behave more naturally when interfaces respond like real products, not like fancy slideshow presentations.
  • Cross-Team Collaboration: Designers in other teams can access and build upon components immediately. No more waiting for "the Figma file to be updated" or wondering if components have been implemented yet. See my related projects.

The Reality Check

Before you get too excited, let me be clear about the limitations:

  • Setup Complexity: This workflow requires significant initial setup. You need a mature design system, Storybook infrastructure, cloud deployment processes, and AI agents that understand your technical stack. It's not something you implement over a weekend.
  • Learning Curve: Working effectively with AI agents requires understanding both design principles and technical constraints. You're not just designing interfaces—you're architecting component systems. This demands a broader skill set than traditional UX roles.
  • Organizational Buy-in: The approach only works if your organization supports it. You need infrastructure, tools access, and leadership that understands the value of interactive prototypes over traditional deliverables.
  • Quality Control: AI agents make mistakes, sometimes spectacular ones. You need robust testing and review processes. The speed gains come with increased responsibility for quality assurance.

When It Makes Sense

This workflow isn't appropriate for every organization or project:

Good fit: Mature design systems, complex enterprise products, distributed teams, organizations with strong technical infrastructure, projects requiring extensive user testing.

Poor fit: Early-stage startups, simple products, teams without technical resources, organizations resistant to new tools, projects with tight deadlines and no time for process iteration.

The Bigger Picture

AI agents in design workflows aren't about replacing designers—they're about expanding what's possible within existing organizational constraints. Instead of spending time on mechanical tasks like creating specifications or explaining interaction behaviors, I can focus on user problems, business logic, and design strategy. Back to my main portfolio for more on my design approach.

The workflow also changes the designer's role in product teams. Instead of being the person who creates beautiful but static representations of ideas, you become someone who can rapidly prototype and validate functional solutions. It's a different skill set and a different value proposition.

Getting Started

If you're interested in experimenting with similar workflows, start small:

  1. Audit your current design system components and identify gaps
  2. Set up basic Storybook infrastructure if you don't have it
  3. Experiment with AI agents on simple component modifications
  4. Document what works and what doesn't in your specific context
  5. Gradually expand to more complex interactions and workflows

The goal isn't to implement my exact workflow—it's to find approaches that solve real problems in your specific environment. Every organization has different constraints, tools, and team dynamics.

The future of design isn't about whether AI will replace designers. It's about whether designers will adapt their workflows to leverage AI effectively while solving increasingly complex user and business problems. Static mockups were never the point—they were just the best we could do with the tools available.