Most designers use AI as a glorified search engine. I use it as a system with 8 arms. The difference is not the tool — it's the process. And that process is what survives when the tools change.
There is a photo of me that captures something I have been trying to articulate for months. I am standing in the middle, and behind me there are eight arms reaching out in every direction — each one holding a different tool. A phone. A laptop. A pencil. Blueprints. A paintbrush. It looks like the Doctor Strange scene where he summons multiple versions of himself to fight simultaneously.
That is exactly what working with Claude Code feels like when you set it up properly.
Not faster. Not more convenient. Genuinely different in kind — operating across multiple dimensions of a project at the same time, with memory, with context, with real connections to the tools I actually use. Eight arms, not one at a time.
But I need to be precise about something before I go further: the power is not in Claude Code. The power is in the process you build around it. That distinction is the entire point of this article, and it is why most designers who are 'using AI' are leaving most of the value on the table.
Most professionals use AI as a glorified search engine. They ask. They copy. They paste. Each session starts from zero. There is no memory, no structure, no accumulated intelligence. Just faster Googling.
— Roy Villasana
The Problem With How Most People Use AI
I want to describe a pattern I see constantly. A designer or product manager opens ChatGPT or Claude. They type a question. They get an answer. They copy it into their document or Figma file. They close the tab. The next day, they open a new session and start from scratch. The AI has no idea who they are, what they are building, what decisions were made last week, or what constraints matter.
This is using a Formula 1 car to drive to the supermarket. Technically it works. You are definitely using the technology. But you are not accessing what makes it different.
What makes Claude Code different — when used fully — is that it does not have to operate this way. It can know who you are. It can remember the project context. It can connect directly to your tools and execute actions inside them, not just suggest actions you then have to perform manually. It can run processes you defined once, repeatedly, without you reconstructing them from memory each time.
That is a fundamentally different working relationship with the tool. And it produces fundamentally different results.
The Four Layers That Change Everything
Skills — Your Expertise, Encoded Once
A skill in Claude Code is a reusable prompt template. But that description undersells what it actually is in practice. It is your expertise, encoded once, callable forever.
When I built the Figma-to-AI Prompter skill, I encoded a specific way of extracting and formatting design information for AI prototyping tools. Every time I need to generate a prompt from a Figma file, I call that skill. I do not reconstruct the logic. I do not remember which fields matter for which platform. I do not rewrite the template. I call the skill, provide the input, and get a consistent output.
This is the difference between having a process and describing a process. A skill is an executable process. The expertise lives in the skill, not in my short-term memory each time I sit down to work.
Think about what this means across a year of work. Every repeatable task in your workflow — writing design briefs, structuring user research, generating component documentation, creating stakeholder summaries — can be encoded as a skill. You stop reconstructing from scratch. You start executing from a foundation.
MCP Connectors — Real Tools, Real Actions
MCP (Model Context Protocol) connectors are where Claude Code moves from language model to actual work system. They are integrations that let Claude operate directly inside your tools — not suggest things you then do manually, but actually do them.
In my current setup: Claude reads and writes to my Supabase database. It reads Figma file structures through the Figma API. It accesses my filesystem, reads my codebase, runs terminal commands. When I ask it to update a blog post, it writes the SQL and executes it. When I ask it to check the current state of a component, it reads the actual file.
The practical consequence is that the friction between deciding something and implementing it nearly disappears. The gap that existed between 'Claude tells me what to do' and 'the thing is done' collapses into a single step.
This changes what kinds of tasks are worth doing. Tasks I would have previously deprioritized because the implementation overhead was too high — cleaning up database content, auditing component usage across a codebase, updating structured data across multiple files — become fast enough to actually do.
Persistent Context — Intelligence That Compounds
One of the most undervalued capabilities in a properly configured Claude Code setup is context persistence. The ability for the system to know, across sessions and over time, what you are building, what decisions you have made, and what constraints are in play.
In practical terms: Claude knows I am Roy Villasana, a Senior Product Designer based in Madrid. It knows my portfolio is a Vite SPA connected to Supabase. It knows my blog posts are stored as JSONB content blocks with a specific structure. It knows my writing voice and the formatting conventions I use. It knows which migrations have been applied and what the current state of the database looks like.
None of this has to be re-explained each session. It is part of the working context.
The compounding effect matters here. The longer you work with a properly configured system, the more context it carries, and the less reconstruction you do at the start of each session. Early on, you spend time establishing context. Later, you start at a higher altitude immediately.
Desktop and IDE Integration — Working In Your Environment
The final layer is integration with the actual environment where work happens. Not a separate tab. Not a parallel window you switch to when you need to ask a question. Claude Code operating inside your development environment — reading the current state of your files, understanding the open editor context, making changes in the same place you are working.
The practical difference is hard to describe until you have experienced it, but it feels like the difference between having a collaborator in the room versus texting someone in another building. The latency collapses. The context is shared automatically. You stop translating between what you are looking at and what you need to describe.
The Tool-Agnostic Insight
Here is the part that matters most, and the reason I wanted to write this article rather than just post a thread about Claude Code features.
Everything I just described — skills, connectors, persistent context, environmental integration — these are not Claude Code inventions. They are patterns. And patterns are portable.
Skills are just structured, reusable prompts. Any sufficiently capable AI system will support them in some form. MCP connectors are just API integrations — the specific protocol is Claude's, but the concept of AI-to-tool connections is universal and spreading fast. Persistent context is just well-maintained documentation that the AI can access. Environmental integration is an architecture decision about where the AI sits in your workflow.
None of it is Claude-specific. All of it is process-specific.
When Claude gets replaced by something better — and it will, that is how this industry works — I keep my process. My skills get migrated or rebuilt, because the underlying logic is documented. My context transfers, because it is structured information. My integrations point at the same APIs through a new protocol. The work I did to build the system is not wasted. It is the foundation for the next system.
The designers who built their 'AI workflow' by getting good at prompt phrasing in ChatGPT are going to start over every eighteen months. The designers who built a structured process — documented, modular, integration-rich — are going to port that process to whatever comes next and accelerate.
What This Looks Like In Practice
A typical morning in my current workflow: I open Claude Code in my IDE. The project context loads automatically — what I am working on, the state of the codebase, the open tasks. I do not explain who I am or what I am building. I start where I left off.
If I need to add a blog post, I describe the topic. Claude generates the SQL migration in the exact format my database expects, with the content block structure my renderer uses, with the writing voice and tone that matches my existing articles. I review it, approve it, and it executes the migration directly against my Supabase instance.
If I need to update the site's structured data, Claude reads the current HTML, identifies every location where the relevant information appears, and makes consistent changes across all of them in a single operation.
If I need to prototype a new feature, I call the Figma-to-AI Prompter skill with a Figma link, get a structured prompt, and run it against whichever AI prototyping tool I am using that day.
The common thread is not speed, though it is fast. It is that the system has absorbed the structural knowledge of how things work — the formats, the conventions, the integrations — so I can operate at the level of decisions rather than implementation details.
That is what eight arms feels like. Not doing things faster. Doing things at a different level of abstraction.
The Question Worth Asking Yourself
If you use AI tools regularly, here is the honest question: are you using them as tools, or as a system?
A tool is something you pick up, use for a specific task, and put down. It does not accumulate knowledge about your work. It does not get better at serving you over time. It does not connect to the other tools in your stack. Every session is the same as the first.
A system is something that compounds. It knows your context. It executes inside your environment. It carries reusable processes. It gets more useful the more you use it.
The gap between these two approaches is going to widen significantly over the next few years. The practitioners who figure out how to build systems — not just use tools — are going to operate at a different level of output than those who do not. And the practitioners who figure out how to make those systems tool-agnostic are going to be the ones still operating at that level when the specific tools they use today no longer exist.
I am not there yet. I am building toward it, learning what works, and documenting what I find. This article is part of that documentation — not a finished answer, but a current state of thinking from someone doing the work in real time.
Keywords
Claude Code workflow, MCP connectors design, AI skills prompt engineering, tool-agnostic AI workflow, Claude Code for designers, AI productivity system, persistent context AI, Claude Code MCP Figma, AI process design, senior product designer AI tools, Claude Code desktop integration