Modern Skill Stack — real stories on how product professionals keep up with a constantly changing skills landscape. Hosted by Gene Kamenez, CEO of Uxcel.
Watch on YouTube.
Somewhere right now, a founder is asking Claude to design a new feature, and the output will look fine. It just won’t look anything like their product.
That gap is where Carmen Rincon works. She’s spent 10 years in product design across very different rooms: a big PR firm designing for AT&T and Nissan, the energy industry with all its regulatory weirdness, then founding designer at an AI startup in San Francisco. Now she’s co-founder of Yummy Design Studio & Labs, where she helps scale-ups move faster when design becomes the constraint, and runs Yummy Labs, an accelerator where early-career designers solve real startup challenges in live two-week sprints.
Here’s the part I didn’t expect: her clients aren’t hiring her to protect them from AI. They’re hiring her to clean up after it. And the system she built in response, connecting Figma, MD files, Claude, and Storybook, is one of the most complete AI design workflows I’ve seen. She walked me through the whole thing, live.
This episode is brought to you by Uxcel.
Uxcel is a learning platform used by 500,000+ product professionals and 200+ organizations to build cross-functional skills across UX design, product management, and AI. Learn through short, gamified courses that fit into a working day, earn certifications, and build a portfolio with real-world project briefs.
Start learning at uxcel.com
You’ll learn:
Why startups now bring designers in after AI, not before, and what that fragmentation pattern looks like
The “first-week hire” mental model that changes the quality of everything AI gives you
How to build design tokens Claude can actually use (it reads semantics, not pixels)
Why a design-system MD file beats calling the Figma MCP every time: tokens, crashes, speed
Carmen’s full client pipeline: Figma → Claude project → Storybook → an npm package devs update with one line in the terminal
Where to start tomorrow without overcomplicating it
My biggest takeaways
AI is the bottleneck now, not the designers
Carmen’s newest clients share a profile: they built their entire product with Claude, no design system or designer involved, straight to code. One of them is a travel app for audio guides that started getting real traction with cultural organizations across Europe. Then the patterns showed up: screens that don’t quite match, flows that feel stitched together, and users starting to notice.
Here’s how Carmen describes the change:
“Our clients right now are coming to us because AI is the bottleneck, not the designers. They’re starting to get users or traction, and they’re seeing that their experience is very fragmented. That’s where designers come in. We can take all of that context, talk to the users, understand the industry, understand the competition, and connect all of those dots that AI is not able to.”
I found this reassuring, and I told her so. The fear narrative says AI replaces designers at the start of the process. What’s actually happening in her client base is the reverse: AI gets teams to traction fast, then the fragmentation bill comes due, and someone has to connect the dots. Design was never about producing a single artifact. The teams learning that the hard way are now paying for it.
Treat AI like a hire in their first week
This was the analogy that reframed the whole episode for me. When someone joins your team, you don’t point at a desk and say “figure it out.” You brief them, give them context, introduce the product, and check their early work. Skip that and you don’t get a bad employee, you get your own bad management reflected back.
In Carmen’s words:
“If you can think of AI, whatever tool you’re using, as onboarding a new person on your team, and what you need to do to make that person successful in the first week, that’s when the mind shift happens. Without that, you’re never going to get a good output. Even if you have proven prompts. You need to do quite a lot of groundwork to even start getting those results.”
The action step: before blaming the model, audit what you handed it. Would a human designer produce good work from that brief? If a new hire couldn’t succeed with the context you gave, neither will Claude.
Generic output is a diagnosis, not a verdict
This one is editorial, but it builds directly on what Carmen kept returning to. When your AI output looks generic, the instinct is to blame the tool or the prompt. Carmen’s read is more uncomfortable: the output is showing you what your team never wrote down.
“One good thing AI is doing is exposing the gaps within teams and within products, the misalignment between teams. If you’re letting AI make those decisions for you, that’s when you get these kinds of outputs. It’s a time for teams to come together and ask: what do we actually have as a team, as a product, as an experience? Maybe their design system isn’t set up the right way. Devs haven’t complained yet, but it’s not really usable.”
Every team I know has some version of this: decisions that live in one person’s head, a design system that works only if you already know it. AI didn’t create those gaps. It just made them visible on every generated screen. That makes generic output weirdly useful, as a diagnostic. It’s pointing at the exact alignment work your team skipped.
Build a design system Claude can read, not look at
Now the practical core. When Carmen sets up a design system for Claude, the work isn’t visual, it’s semantic. Claude never sees your tokens the way you do.
This is how Carmen describes it:
“People have to know that when they’re building tokens, Claude is not visualizing these tokens. It’s reading the semantic values. It’s reading the code behind that. So it is so important to be hyper, hyper specific on what you’re building, the semantics, all the use cases, so Claude can really start to understand what to use when.”
Her setup for the travel-app client: foundational tokens with painfully specific semantic naming, then component descriptions and usage rules written into Figma’s dev mode. She had Claude write those descriptions itself via the Figma MCP, which she says is exactly the kind of groundwork worth delegating: “a really important part of setting up the right design system for Claude are descriptions, which a lot of people don’t do. And that’s something that Claude always grasps first.” Once the decisions are made, Claude even creates the variables in the right structure. The designer decides; the model does the grunt work.
Put the system in Claude’s memory, not in MCP calls
Here’s the counterintuitive part of her stack: she barely uses the Figma MCP for design work. She’s blunt about it: “I did not use the MCP to design internally inside of Figma. First of all, because it uses a lot, a lot, a lot of tokens. And second is because it’s just not good enough yet. It takes more time for me to edit things than it would take for me to just do it from the beginning.”
Her alternative:
“If you ask Claude to use MCP every single time to get context of your design system, you’re going to be out of tokens very quickly. You get errors, Claude sometimes crashes, especially as your design system grows. What I find useful is to create markdown files, project files, and skills files, so Claude can access this much quicker than by reading entire Figma files.”
So the design system lives as an MD file inside a Claude project, alongside founder context and app screenshots. After a full setup session, she’d used 4% of the project’s capacity. Claude generates layouts and documentation as HTML artifacts she pastes straight into Figma, then she rebuilds the components herself, the part where taste actually matters. The whole foundation took a week and a half. “Normally that just doesn’t happen.”
The handoff is the closer: components and tokens move into Storybook, translated to the client’s Gluestack codebase by Claude Code, wrapped in an npm package. When Carmen updates something in Figma, she pushes to the package and the devs update with one line in the terminal. Their engineers have been using it for weeks without finding anything strange.
Do the thinking yourself first
I asked Carmen where someone should start if they want this without overcomplicating it. Her answer wasn’t a tool. It was a warning about outsourcing judgment:
“If you have nothing in mind and you just go to Claude, it’s just giving you an opinion that you’re going to believe, because it’s the easiest path forward. I started thinking about this from a real product designer perspective, understanding the product, building small things in Figma myself, then going to Claude and saying: these are the primary colors I want to use, are there secondary colors we can work with? You go back and forth and see if it gives you good outputs. Using Claude as a sparring partner, I would say.”
Start small. Capture the minimal context that makes your product your product. Then use Claude to iterate inside those constraints, step by step. The order matters: your thinking first, then the model. Reverse it and you’re back to generic output, believing the first confident answer you get.
Episode timestamps
All timestamps generated from the transcript.
00:38 · What this episode covers
01:56 · The skill Carmen is focused on now (knowing when not to use AI)
03:58 · Career path: PR firm, energy industry, founding designer
08:30 · Why she started building AI design workflows
14:39 · Why AI prototypes look generic
19:01 · Live demo: design system for a Claude-built travel app
28:26 · Claude projects and the design-system MD file
32:27 · Prototyping micro-interactions without Figma’s prototype feature
36:45 · Where to start tomorrow
Resources mentioned
Tools
Claude and Claude Code (claude.com) · projects, artifacts, MD/skills files
Figma (figma.com) · dev mode, variables, component descriptions, Figma MCP
Storybook (storybook.js.org) · component library and dev documentation
Gluestack · the client’s UI library
npm · package handoff between design and dev
Communities & programs
Yummy Design Studio & Labs · https://www.yummy-labs.com/
Yummy Labs accelerator · two-week live sprints for early-career designers · https://www.linkedin.com/company/yummy-labs/
Where to find Carmen
Yummy Design Studio & Labs: https://www.yummy-labs.com/
One question before you go: if you handed your product’s design context to a brand-new hire tomorrow, exactly as it exists today, could they do good work with it? If the honest answer is no, that’s your AI problem too. Tell me what’s missing from your team’s groundwork in the comments.
