From Figma to Working Product

This week at UX Tree, we hosted a live webinar with Kevin Zamora Saenz about something we have been hearing more and more from designers:
“How can we use AI to move from a design in Figma to something that actually works?”

The session brought together designers, product managers, founders and people already working with AI products, and the questions were much more practical than theoretical. People wanted to understand how AI could fit into their existing workflow, how to keep their design system under control, what happens to the code once a prototype has been created, and whether learning all of this means they now have to become developers.

Kevin led the session and took us through a real workflow, starting with the product problem and ending with an interactive prototype running in a browser. What made the session particularly useful was that we did not start by talking about AI tools. We started with the product itself, because knowing how to use a tool is not much use if you do not understand what you are trying to build and why.

Start with the problem, not the interface

One of the examples Kevin used was a fictional healthcare product where the business was losing revenue because patients were dropping out when faced with long waiting times. We looked at the problem from the patient’s perspective and considered what they actually needed rather than immediately jumping into the interface.

For example, imagine a patient who has had an MRI and is unsure what happens next. They may receive a long email or a PDF with information, but what they really need could be a simple set of steps showing what has happened, what they need to do next and when they can expect their results.

This is where product strategy becomes important. Good UX is not simply about creating a better experience. It is about understanding the relationship between the business goal, the user problem, the behaviour you want to change and the product intervention that could make that happen.

A simple way to think about it is:

Business goal → User problem → Behaviour → Product solution → Measurable outcome

When you can explain that connection, your work becomes much easier for stakeholders to understand and much harder to dismiss as “just design”.

This is where we used the UX KPI Tree to connect the two sides of the problem. We started with the business goal, looked at the user problem underneath it, identified the behaviour we wanted to influence and then considered what product change could help us get there. That connection is important because it gives the designer a much stronger reason for making a particular design decision and makes it easier to explain the value of the work to stakeholders.

Then we brought AI into the process

Once we understood the problem and had a direction for the experience, Kevin showed how AI could help us turn the design into something interactive. The workflow used Figma, Claude Code and a simple MarkDown (.md) file containing information about the design system and the product.

The Markdown file might sound like a small detail, but it was one of the most useful parts of the session. Instead of giving an AI tool a screenshot and expecting it to understand everything about your product, you can give it written context about your design principles, colour tokens, rules and other decisions that should guide the work. This gives the AI something much more useful than a collection of pixels to work from.

It also means you do not have to explain the same things over and over again. Once you have created the file, it can be used across different tools and shared with developers when the work moves further into production. During the Q&A, Kevin explained that spending a few minutes creating this context at the beginning can save much more time later, particularly when AI misses an important guideline and you have to start correcting the work.

 

What does this mean for designers?

This was probably one of the biggest questions behind the whole webinar.

If AI can generate front-end code, does a designer now need to become a developer?

Kevin’s answer was no. His view of UX engineering is much more practical: designers should be able to guide AI, understand what it produces and make sure the final experience still reflects the product decisions, interaction quality and user needs they started with. You do not need to replace your developers or become an expert in back-end engineering, but having enough technical understanding to work with code gives you much more freedom to explore ideas yourself.

Instead of stopping at, “Here are the screens I designed,” you can get to, “Here is the problem we are solving, here is the experience I believe will solve it, and here is a working prototype that we can actually test.”

That is a significant increase in your ability to influence the product.

 

From Figma to something you can actually use

This was the part of the webinar where the idea became much easier to understand. Kevin connected the design file and the supporting context, worked through a few questions from Claude Code and generated a local version of the product that could be opened in a browser.

The result was not a finished product, and nobody was pretending it was. It was an early prototype that allowed us to move through the healthcare journey, see the steps a patient might take and test the basic interactions, discover problems and make changes before asking engineering to build the final product.

The point is not that every designer suddenly needs to ship production software.
The point is that the gap between having an idea and being able to test that idea is becoming much smaller.

That distinction is important because the value of AI is not simply that it can make something faster. It means a designer can get to the point where an idea can be explored much earlier, before a large amount of engineering time has been committed to building it:

• if the idea does not work, you can find that out earlier
• if something is confusing, you can change it
• if stakeholders do not understand the concept from the Figma screens, you can show them what you mean.

 

The designer’s role is getting broader

One of the things we took away from the session is that this is less about learning another set of tools and more about becoming comfortable with a broader part of the product process. Designers have always been expected to understand users, but the strongest designers also understand the business problem behind the work and can explain why a particular solution is worth building.

Now there is an opportunity to take that one step further by understanding enough technology to turn those ideas into something that can be explored and tested. You do not need to know every programming language or understand how to build a complete production system. You need to understand enough to work effectively with AI and developers, make sensible decisions and know when the output needs to be challenged.

That combination is becoming increasingly useful because companies do not need more screens simply for the sake of having more screens.

Companies need people who can help them make better product decisions and get to a useful solution without wasting months building the wrong thing.

 

Want to learn how to do this yourself?

If the webinar made you think, “I want to actually try this,” we have two 6-week programmes at UX Tree that can help you do exactly that. We run both courses every month, and we keep each cohort to just 5 people so there is enough time for questions, feedback and hands-on support throughout the programme.

If you want to understand the bigger product picture, our AI Product Strategy & Engineering course takes you through product strategy, defining problems, connecting UX to business outcomes, using metrics, getting stakeholder buy-in and using AI as part of your product workflow. It is designed to help you become much more confident making and explaining product decisions, rather than simply learning another set of AI tools.

If what you really want is to take a design and turn it into a real product, UX AI Engineering goes further into the build. Over 6 weeks, you learn how to work with tools including Claude Code, Figma, GitHub, Supabase, Cloudflare and MCPs, and you build your own product from design through development and deployment. By the end of the programme, you have a working product that you can actually show, rather than another course project sitting in a folder.
You do not need a traditional coding background to join.

Both programmes are practical and both are limited to five people per cohort, and because we run them every month, you do not have to wait months for the next opportunity to join.

If you are not sure which one is right for you, get in touch and we can help you choose based on where you are in your career and what you want to be able to do after the six weeks.