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. According to one expert, design is about solving problems.

So, what if AI could help think through 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, it is possible to 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 the project context. And there is no need to use 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. Using Claude Code, a memory management system has been set up 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 that can be missed. Every design session starts with a manual reassembly of context. A memory bank was built from that. Then Claude Code was trained 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. The 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. It would be possible to connect this project to the design system code, but the setup seemed too time-consuming.

All project information is stored in markdown format. It is formatted consistently so that the AI can retrieve it more easily. Raw notes are acceptable at the input stage. Claude can help structure them. Anything confidential is obscured 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, another problem was noticed. The same workflows had to be re-explained constantly: "Read the ticket, check the research, give me three directions" every time. These steps were therefore automated with skills.

• explore: helps go through a complete design iteration. It is given a problem: a ticket, a brief, or a statement, and it launches an iteration, cross-referencing the 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 to the way one works. It is used to test a direction against one's own standards and the project's objectives.

It is strongly recommended to take 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 set up to extract information in real time from platforms like Slack, Figma, and Linear. Although the setup is complex, it keeps the workflow smooth and reduces interruptions.

As projects evolve, new context first emerges during meetings or in tools like Slack, Figma, or Linear. It is preferable to stay immersed in the problem. MCPs (Model Context Protocol) are used to extract information from these tools. The setup takes time with authentication and permissions. But once up and running, it stays discreet.

• Linear: When the problem lives in a ticket, /explore is pointed at it so that Claude can gather the context, read the most recent activity, and also help keep it up to date.

• 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 file, the better it works. Good results have been seen by giving Claude a well-defined, 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 up to date (and the user too).

All of these elements are optional. The project started without any of them. The aim was for it to work autonomously first. The MCPs came later, when patterns in the workflow were noticed that were worth automating. More connections mean more things that can break, so there is 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. It has been noticed that the clearer the instructions, the less back-and-forth there is with the AI.

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

The AI brings out directions that are used as starting points. These proposals are far from ready to be shared or shipped. It is therefore asked to surface relevant data points. But the user directs what it should build. They follow up with Figma mockups if necessary to help it.

A typical session. Some commands are skills, others are natural language. The user talks to the AI like a collaborator. No re-explanation. It knows the project.

Where does the project stand? What should the focus be 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]

The 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 point of view before bringing Claude back. This may even mean quick mockups in Figma.

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

Handoff

Once aligned on a prototype, Figma mockups are designed for the key moments in the flow. Then a specification is written describing the flow: the steps, with Figma frames for the 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 out 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 is also what keeps it from hallucinating, especially with complex flows.

What Has Changed

There is no longer any need to start from scratch. Each session picks up where the last one left off, with decisions, dead ends, all of that. It is possible to move from a well-defined problem to clickable prototypes quickly. Context switching has decreased. Focus on the problem is maintained.

Code prototypes have changed the feedback dynamic. Unlike static Figma mockups, they were not polished, yet that helped. People stopped focusing on visual details and started talking about user experience. That is the conversation that was wanted earlier. Bad ideas also die faster, before too much is invested.

Decisions are tracked by round in the design/ folder. No more digging through Figma comment threads to remember why a decision was made three weeks ago. Synchronizing stakeholders no longer feels like project management. Claude reads the Linear tickets, the Slack threads, and the latest research. There is no longer any need to summarize manually. It already knows.

Summary

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