Notes on how AI changed our design process

There are a lot of articles about designing faster with AI. Design quicker, design better, ship in a day. What people talk about less often is what actually changes in your process, and what it costs you along the way.

So these are my notes.

Some context first. I work on a B2B and B2C platform for corporate meeting, event planning and travel management. At one point the product entered its startup phase, and our company's OKR became Time to Market for AI features, to outrun competitors. We had to speed up. That is where AI came into play, and where we ran into challenges we were not ready for.

Everyone became a designer overnight

The first challenge had nothing to do with tools. With so many easy-to-use AI products around, every product owner, stakeholder, and even client suddenly had their own prototype and their own opinion on how the design should look.

Suddenly I was no longer just presenting my designs, I was advocating for them against everyone's so-called design concept. People became very opinionated about their own version, and I had to prove my expertise every single time I presented. So instead of spending time on research, on thinking through the flows, on the actual craft, we were spending it on defending why our version was the one to build. Which leads directly to the next problem.

When you lean too much on AI, you lose your ownership

It became harder for designers to advocate for their solutions. You cannot really explain why the flow is split into these steps, cause you did not design it that way, AI did.

There is an idea that AI does the designer's job instead of the designer. And to some extent that is true, it really can. But then ownership, one of the most important parts of our job, quietly slips away. And that is not what any of us want.

So, even with AI, you have to stay in charge of what you deliver. Validate and challenge everything AI gives you, and bring your own reasoning to it.

The rushed transition to Claude Code

Then came the tooling shift. We moved from Figma to Claude Code, and it happened fast, under pressure to cut delivery time. A lot of questions piled up immediately.

• Do we keep Figma updated? We had built a lot of prototypes, components, and flows there. But in startup mode things changed so quickly that Figma would be outdated within a week or two. And what if we wanted to come back to it later?
• What happens when we run into something technical we cannot fix ourselves? Designing in parallel and pushing to GitHub nearly cost us a full day of work a few times. And even with the design system connected, we would still spot raw values instead of the actual components. In our case it was not critical, but imagine you need to support multiple modes or theming. That is where you lose the control Figma gives you through variables and components.
• AI also has bad days. Sometimes you ask it to nudge something 20px to the right and it designs you a completely new cards UI. Thankfully it was rare, but it tends to happen exactly when you need a quick fix right before a demo.
• The last thing is the loss of freedom. Without the Figma canvas, some things simply disappear. You cannot mark a screen as done, in progress, or not started. You cannot lay out every screen and edge case in one place, and on top of that you have to figure out how to embed those edge cases into the prototype itself, which is not always possible. There is no easy way to show developers what is final and what is not, and in startup mode approval and development run at the same time. In Figma you would just label a frame "approved" or "in progress" and everyone sees the status at a glance.

None of this is a dealbreaker. All of these problems have solutions, and you will figure most of them out. But it is worth knowing about them upfront, because working around them takes time.

What actually got better

AI genuinely sped us up, but the biggest change was not just how quickly we could produce a screen. It changed what we were able to explore and validate during the design process.

We stopped delivering static screens and started building fully functional prototypes that could be tested with product owners much earlier. Instead of explaining how an interaction should work, we could actually build it, see how it felt, and iterate on it. This made it easier to explore more sophisticated interactions and think about responsiveness and real product behaviour from the start.

It also changed the level of detail we could explore. We were no longer limited to what was practical to prototype in Figma within the available time. We could build different states, interactions, and edge cases and use them to have more concrete conversations with the team.

And because much of what we built was handed to developers as code, the gap between design and implementation became smaller. What we designed and what got built were much closer to the same thing, which also made the handoff and iteration process faster.

So AI didn't just help us design faster. It gave us a way to move from describing ideas to actually building and validating them much earlier in the process.

Before you rush into AI

AI can be a powerful addition to the design process. But moving to an AI-first workflow is not simply about choosing a faster tool. It changes how you work, how you collaborate, and how much control you have over the design process.

Before making the shift, it is worth looking at what you might gain and what you might give up. How important are Figma-based workflows to your team? How much control do you need over design systems, variables, and components? How will you handle approvals, edge cases, and collaboration between design and development? And, most importantly, how will you make sure designers still own the decisions rather than simply validating what AI produces?

AI can absolutely make the design process faster and more capable. The important part is not rushing towards it, but understanding the trade-offs before you do.