Blog #1
Blog #1
08/10/2026
08/10/2026
|
10 min read
10 min read
|
AI + Product design
AI + Product design
MCP for Product Designers
MCP for Product Designers
TL;DR
TL;DR
The next interface designers may need to design is not only a screen. It is the boundary between an AI agent and the systems it is allowed to use.
That idea became real for me when I first came across Figma MCP on LinkedIn. The promise sounded simple: an AI assistant could read Figma files, understand design context, analyze screens, read comments, and even help with design critique.
My first thought was not “this will replace design.” It was: what if I could work with AI directly inside the design process?
I wanted a two-way interaction. I wanted AI to read my Figma files, understand the work I had already done, and help me move faster. But I also wanted it to write back to Figma: create variables, build design-system tokens, generate supporting screens, and handle the repetitive work that usually slows down a design workflow.
After experimenting with Figma MCP through Codex and exploring skills from different GitHub repositories, I learned something more useful than how to connect a new tool:
"AI does not remove the need for design foundations. It makes the quality of those foundations more visible."
The next interface designers may need to design is not only a screen. It is the boundary between an AI agent and the systems it is allowed to use.
That idea became real for me when I first came across Figma MCP on LinkedIn. The promise sounded simple: an AI assistant could read Figma files, understand design context, analyze screens, read comments, and even help with design critique.
My first thought was not “this will replace design.” It was: what if I could work with AI directly inside the design process?
I wanted a two-way interaction. I wanted AI to read my Figma files, understand the work I had already done, and help me move faster. But I also wanted it to write back to Figma: create variables, build design-system tokens, generate supporting screens, and handle the repetitive work that usually slows down a design workflow.
After experimenting with Figma MCP through Codex and exploring skills from different GitHub repositories, I learned something more useful than how to connect a new tool:
"AI does not remove the need for design foundations. It makes the quality of those foundations more visible."
What MCP is, in plain language
What MCP is, in plain language
The Model Context Protocol, or MCP, is an open standard that helps AI applications connect to external data and tools. The goal is to give AI systems a consistent way to discover context, access capabilities, and perform actions through connected systems.
The Model Context Protocol, or MCP, is an open standard that helps AI applications connect to external data and tools. The goal is to give AI systems a consistent way to discover context, access capabilities, and perform actions through connected systems.
The official architecture describes three main participants:
The official architecture describes three main participants:
The host is the AI application a person uses.
The client manages the connection between the host and an MCP server.
The server provides context or capabilities to the AI application.
The host is the AI application a person uses.
The client manages the connection between the host and an MCP server.
The server provides context or capabilities to the AI application.
An MCP server can expose different kinds of functionality. Tools are executable functions. Resources provide contextual data. Prompts are reusable interaction templates. The protocol standardizes the exchange between systems; it does not decide how the model should behave or how the final user experience should be designed. MCP architecture overview
A simple mental model is a USB-C connection for AI applications. Instead of building a completely different integration between every AI assistant and every external system, compatible clients and servers can communicate through a shared standard.
An MCP server can expose different kinds of functionality. Tools are executable functions. Resources provide contextual data. Prompts are reusable interaction templates. The protocol standardizes the exchange between systems; it does not decide how the model should behave or how the final user experience should be designed. MCP architecture overview
A simple mental model is a USB-C connection for AI applications. Instead of building a completely different integration between every AI assistant and every external system, compatible clients and servers can communicate through a shared standard.
Context before generation
Context before generation
In a design workflow, that might look like this:
In a design workflow, that might look like this:
Designer asks: “Review this checkout flow for edge cases.”
AI host
→ MCP client connects to Figma
→ Figma MCP returns design context, variables, and comments
→ AI analyzes the selected screens
AI Output
← Suggestions, critique, or new Figma content
Designer asks: “Review this checkout flow for edge cases.”
AI host
→ MCP client connects to Figma
→ Figma MCP returns design context, variables, and comments
→ AI analyzes the selected screens
AI Output
← Suggestions, critique, or new Figma content
The important part is not the diagram itself. It is the change in the relationship between the designer, the AI, and the design tool. The AI is no longer limited to describing what it would do. It can work with the actual design context and, depending on the tools and setup, make changes in the design environment.
The important part is not the diagram itself. It is the change in the relationship between the designer, the AI, and the design tool. The AI is no longer limited to describing what it would do. It can work with the actual design context and, depending on the tools and setup, make changes in the design environment.
Figma’s current documentation describes its MCP server as supporting design-context extraction, code-related workflows, and writing native Figma content back to the canvas. Figma also recommends using skills to make multi-step write workflows more reliable. Figma MCP documentation · Figma MCP skills
Figma’s current documentation describes its MCP server as supporting design-context extraction, code-related workflows, and writing native Figma content back to the canvas. Figma also recommends using skills to make multi-step write workflows more reliable. Figma MCP documentation · Figma MCP skills
Why I wanted to use it
Why I wanted to use it
I wanted to use AI in my Figma files to accelerate my design process. I was especially interested in a two-way workflow:
AI reads the existing file and understands the design context.
AI performs the repetitive or structural work.
The result comes back into Figma as something I can inspect, edit, and improve.
I wanted to use AI in my Figma files to accelerate my design process. I was especially interested in a two-way workflow:
AI reads the existing file and understands the design context.
AI performs the repetitive or structural work.
The result comes back into Figma as something I can inspect, edit, and improve.
This was more interesting to me than asking an AI assistant to generate a random interface from a blank prompt. A blank prompt can produce something that looks plausible. A real Figma file contains decisions, constraints, components, variables, layout rules, and unfinished thinking.
This was more interesting to me than asking an AI assistant to generate a random interface from a blank prompt. A blank prompt can produce something that looks plausible. A real Figma file contains decisions, constraints, components, variables, layout rules, and unfinished thinking.
"That context is what makes the output useful."
"That context is what makes the output useful."
I used Codex as my AI environment and explored different GitHub repositories and skills that improved the workflow. I was not only learning MCP as a protocol. I was learning how instructions, tools, design context, and existing systems combine to shape the result.
I used Codex as my AI environment and explored different GitHub repositories and skills that improved the workflow. I was not only learning MCP as a protocol. I was learning how instructions, tools, design context, and existing systems combine to shape the result.
What I actually used Figma MCP for
One of my first useful applications was building design-system tokens and variables. Creating variables manually is important work, but it can also be tedious: naming them, setting values, creating modes, connecting references, and repeating the same structure across a system.
With MCP, I could use AI to help with that repetitive setup. The value was not that AI suddenly understood design systems perfectly. The value was that it could help perform structured work when I gave it enough context and clear enough instructions.
I also used it to create edge-case and filler screens from the main screens I designed myself. This was useful because a polished primary flow is rarely the whole product. Real products need empty states, errors, loading states, incomplete data, long content, short content, permissions, edge conditions, and other screens that are easy to postpone.
AI helped me expand the system around the main screens faster.
Over time, the role of MCP in my process expanded beyond generation. I tried to replicate the structure and discipline of the IBM design system for one of my projects, then used that foundation as a reference for my own design system. Once the basic system was in place, I could ask MCP to help with the repetitive work of setting up tokens and variables, checking consistency, and extending the system into additional screens.
I now also use MCP as a design feedback and QA partner. I ask it to analyze the current work, check whether I am missing important states or patterns, and perform a final audit before I consider a design ready. Sometimes it catches useful gaps. Other times it gives broad advice such as “improve consistency” or “add more states” without enough specificity to act on.
That limitation is important. MCP can help me inspect the work, but it does not automatically know which issues matter most for the product. General feedback becomes useful only when I provide evaluation criteria: the user goal, the intended design language, the component rules, the accessibility expectations, and the edge cases I want checked.
That distinction matters. I was not asking AI to invent the entire product without direction. I was giving it a foundation and asking it to help explore the space around that foundation.
The failure mode: context without a foundation
The most important lesson came from what did not work.
When I used MCP without enough context about the screens or without an initial foundation in the Figma file, the output became random. It looked like the kind of generic AI output many people now call “AI slop.”
The problem was not necessarily that MCP failed. The problem was that I had not given the system enough design intent to work from.
Without a clear foundation, the AI had to guess:
What visual language should it follow?
Which components already exist?
What spacing and typography rules matter?
Which variables are semantic and which are local?
What does the product consider a normal state?
What should an edge case feel like in relation to the main flow?
When those decisions were missing, the output filled the gaps with generic patterns. It could create something visually complete without creating something that belonged to the product.
That was a useful failure because it changed how I think about AI-assisted design. The model was not replacing the design system. It was revealing whether a design system existed strongly enough to guide the work.
The workflow that works better for me
My current process is deliberately front-loaded. Before I start using MCP, I establish the foundation myself:
1
Define what the project is and what problem it is solving.
2
Define the users, goals, and important workflows.
3
Establish the design language the product should follow.
4
Create the basic design system: typography, color, spacing, variables, components, and states.
5
Make the important product and interaction decisions.
6
Ask it to perform repetitive work, expand edge cases, review the system, and run QA.
This process changed my understanding of what “AI-assisted design” means. The AI is most useful after the difficult ambiguity has been reduced. I do not ask it to invent the product direction and then spend the rest of the project correcting generic output. I make the foundational decisions first, then use MCP to increase the amount of work I can explore and verify.
The foundation acts like a quality filter. It gives the AI something specific to follow and gives me something specific to evaluate against.
What I actually used Figma MCP for
One of my first useful applications was building design-system tokens and variables. Creating variables manually is important work, but it can also be tedious: naming them, setting values, creating modes, connecting references, and repeating the same structure across a system.
With MCP, I could use AI to help with that repetitive setup. The value was not that AI suddenly understood design systems perfectly. The value was that it could help perform structured work when I gave it enough context and clear enough instructions.
I also used it to create edge-case and filler screens from the main screens I designed myself. This was useful because a polished primary flow is rarely the whole product. Real products need empty states, errors, loading states, incomplete data, long content, short content, permissions, edge conditions, and other screens that are easy to postpone.
AI helped me expand the system around the main screens faster.
Over time, the role of MCP in my process expanded beyond generation. I tried to study and adapt principles from IBM’s design system for one of my projects, then used that foundation as a reference for my own design system. Once the basic system was in place, I could ask MCP to help with the repetitive work of setting up tokens and variables, checking consistency, and extending the system into additional screens.
I now also use MCP as a design feedback and QA partner. I ask it to analyze the current work, check whether I am missing important states or patterns, and perform a final audit before I consider a design ready. Sometimes it catches useful gaps. Other times it gives broad advice such as “improve consistency” or “add more states” without enough specificity to act on.
That limitation is important. MCP can help me inspect the work, but it does not automatically know which issues matter most for the product. General feedback becomes useful only when I provide evaluation criteria: the user goal, the intended design language, the component rules, the accessibility expectations, and the edge cases I want checked.
That distinction matters. I was not asking AI to invent the entire product without direction. I was giving it a foundation and asking it to help explore the space around that foundation.
The failure mode: context without a foundation
The most important lesson came from what did not work.
When I used MCP without enough context about the screens or without an initial foundation in the Figma file, the output became random. It looked like the kind of generic AI output many people now call “AI slop.”
The problem was not necessarily that MCP failed. The problem was that I had not given the system enough design intent to work from.
Without a clear foundation, the AI had to guess:
What visual language should it follow?
Which components already exist?
What spacing and typography rules matter?
Which variables are semantic and which are local?
What does the product consider a normal state?
What should an edge case feel like in relation to the main flow?
When those decisions were missing, the output filled the gaps with generic patterns. It could create something visually complete without creating something that belonged to the product.
That was a useful failure because it changed how I think about AI-assisted design. The model was not replacing the design system. It was revealing whether a design system existed strongly enough to guide the work.
The workflow that works better for me
My current process is deliberately front-loaded. Before I start using MCP, I establish the foundation myself:
1
Define what the project is and what problem it is solving.
2
Define the users, goals, and important workflows.
3
Establish the design language the product should follow.
4
Create the basic design system: typography, color, spacing, variables, components, and states.
5
Make the important product and interaction decisions.
6
Ask it to perform repetitive work, expand edge cases, review the system, and run QA.
This process changed my understanding of what “AI-assisted design” means. The AI is most useful after the difficult ambiguity has been reduced. I do not ask it to invent the product direction and then spend the rest of the project correcting generic output. I make the foundational decisions first, then use MCP to increase the amount of work I can explore and verify.
The foundation acts like a quality filter. It gives the AI something specific to follow and gives me something specific to evaluate against.
