AI and Claude Code Transform Modern Design

AI in Service of Design: A New Working Method

In the field of design, managing a constant flow of information is a major challenge. Between research synthesis, product metrics, and stakeholder feedback, tracking everything quickly becomes complex. Traditionally, AI tools have focused on visual generation, but a more thoughtful approach is possible.

Working on a complex design problem means having to manage a lot of information. Research synthesis, product metrics, a Slack thread with stakeholder feedback, Figma comments, decisions made during the last iteration. Multiply that by the number of iterations, and it becomes difficult to keep track.

Most AI tools focus on visual generation. Faster user interfaces, attractive mockups, ambiance-based prototypes. It's quick and aesthetically pleasing. But it neglects the hard part. I've always believed that design is about solving problems.

So, what if AI could help me think about the problem instead? Retaining all the project context and surfacing the right information at the right time. Something that accumulates context throughout the life of a project. Like a memory palace?

Once set up, I can move from a well-defined problem to a few data-informed code prototypes quickly. Not an ambiance-based user interface. Concepts grounded in the real problem and project context. And I'm not using a classic AI chat or Projects.

A Centralized Context for Better Reflection

The idea is to allow AI to retain the project context, making it easier to access relevant information at the right time. By using Claude Code, a memory management system has been established to centralize all project data, from initial research to functional HTML prototypes.

The project context is scattered across different documents, tools, and people. Research is in one place, product metrics in another, stakeholder feedback in Slack threads I've missed. Every design session starts with a manual reassembly of context. So, I built a memory bank from that. Then, I taught Claude Code how to use it.

• my-project/
  • .claude/ : project-specific skills
  • data/ : research synthesis and metrics
  • design/ : explorations and feedback by iteration
  • project-context/ : fixed project details
  • handoffs/ : technical specifications
  • prototypes/ : functional prototypes
  • design-system/ : tokens and components
  • CLAUDE.md : custom instructions
  • MEMORY.md : evolving context index

CLAUDE.md customizes Claude Code for this project. MEMORY.md is the ongoing index of all context, data, and decisions. Think of it as a constantly evolving table of contents. When Claude needs information, this file tells it where to look.

design-system/ allows prototypes to resemble the actual product. My setup is simple: design tokens (spacing, color, typography) as CSS variables. The goal at this stage is to validate flows and user experience, not visual accuracy. I could connect this project to my design system code, but the setup seemed too time-consuming.

I store all project information in markdown format. They are consistently formatted so that AI can retrieve them more easily. Raw notes are acceptable at the input stage. Claude can help structure them. Anything confidential, I obscure first.

Automation and Customization of Processes

Automating repetitive processes has been another area of improvement. Skills such as explore, brainstorm, synthesize, and prototyping have been developed to facilitate design iterations. These tools allow moving from a defined problem to code prototypes while integrating feedback and testing directions according to project standards.

Once the project had all its context, I noticed another problem. I had to constantly re-explain the same workflows: "Read the ticket, check the research, give me three directions" every time. So, I automated these steps with skills.

• explore: helps go through a complete design iteration. I give it a problem: a ticket, a brief, or a statement, and it launches an iteration, cross-referencing available data and generating code prototypes for each.

• brainstorm: to determine which directions are worth exploring.

• synthesize: takes new raw data and integrates it correctly into the project. It also helps connect new discoveries to existing data.

• prototyping: builds autonomous code prototypes grounded in the design system.

• design-partner: highly customized according to my working style. I use it to test a direction against my own standards and the project's objectives.

I highly recommend taking the time to adjust these skills to your working style, especially design-partner.

Real-Time Connection to Work Tools

To stay updated, model context protocols (MCPs) have been established to extract information in real-time from platforms like Slack, Figma, and Linear. Although the setup is complex, it allows for a smooth workflow and reduces interruptions.

As projects evolve, new contexts first emerge during meetings or from tools like Slack, Figma, or Linear. I prefer to stay immersed in the problem. So, I use MCPs (Model Context Protocol) to extract information from these tools. The setup takes time with authentication and permissions. But once up and running, it remains discreet.

• Linear: When the problem is in a ticket, I point /explore at it so Claude can gather context, read the most recent activity, and also help keep it updated.

• Figma: Claude references the mockups to generate accurate prototypes. The Figma MCP also writes on the canvas, which is useful. The more structured the Figma, the better it works. I've found good results by giving Claude a well-defined and bounded section of mockups rather than the link to the entire file.

• Slack: Stakeholder feedback, new decisions, and schedule changes come through Slack before reaching a ticket. Teaching Claude where to look keeps it updated (and me too).

All these elements are optional. My project started without any of them. I wanted it to function autonomously first. The MCPs came later when I noticed patterns in my workflow that were worth automating. More connections mean more things can break, so there's a balance to find.

A New Collaboration Dynamic

The AI-centered approach has transformed how prototypes are perceived. Unlike static mockups, code prototypes encourage a discussion focused on user experience rather than visual details. This allows for quickly identifying ineffective ideas and improving collaboration with stakeholders.

An execution of /explore is the beginning, not the end. Most problems require multiple iterations. I've noticed that the clearer I am, the less back-and-forth I have with the AI.

/explore chains brainstorming, synthesizing, and prototyping skills into a single command. A prompt triggers a complete iteration.

AI brings forth directions that I use as starting points. These proposals are far from ready to be shared or shipped. So, I ask it to surface relevant data points. But I direct what it should build. I follow up with Figma mockups if necessary to assist it.

A typical session. Some commands are skills, others are natural language. I talk to it like a collaborator. No re-explanation. It knows the project.

Where am I with this project? What should I focus on next?

• /explore the loading states problem
• /design-partner evaluate the latest loading state solutions
• /synthesize stakeholder feedback for revision 2: [raw copy of feedback pasted]

My last iteration for the loading states is complete. Publish an update. (this will send a Slack message and a Linear comment if the MCP works)

Between commands, there is the real design work. Sketches, reasoning, specification documents, forming a viewpoint before bringing Claude back. This may even mean quick mockups in Figma.

/design-partner tests my thoughts against the problem. Once I lock in directions, Claude builds them into code prototypes. Raw by choice. The goal is to align on direction, not polish. Before anything is sent to the team, I validate it against the original problem statement (/design-partner can help).

Handoff

Once aligned on a prototype, I design Figma mockups for key moments in the flow. Then, I write a specification describing the flow: the steps, with Figma frames for key moments.

Once the specification is written, Claude has an anchor to generate different outcomes from it: high-fidelity prototype, journey map, or implementation plan.

Writing the solution is also context for the AI. It becomes the anchor for everything else. Claude can use it to build a high-fidelity prototype, write a journey map, generate an implementation plan for the code. It also prevents it from hallucinating, especially with complex flows.

What Has Changed

I've stopped starting from scratch. Each session picks up where the last one left off with decisions, deadlocks, all of that. I could move from a well-defined problem to clickable prototypes quickly. Context switching has decreased. I could stay focused on the problem.

Code prototypes have changed the feedback dynamic. Unlike static Figma mockups, they weren't polished, yet that helped. People stopped focusing on visual details and started talking about user experience. That's the conversation I want earlier. Bad ideas die faster too, before I invest too much.

I track decisions by round in the design/ folder. No more digging through Figma comment threads to remember why we made a decision three weeks ago. Synchronizing stakeholders no longer felt like project management. Claude reads Linear tickets, Slack threads, and the latest research. I no longer summarize manually. It already knows.

Summary

The project duration has increased, more information has been accumulated, and collaboration has become smoother.