Every stage before UI execution has a clear handoff. Research, define, ideate, validate. AI has accelerated all of them. Landscape analysis in hours. Prototypes in less than a day. And then we hit UI execution, and everything slows down.

This is where designers go quiet. Where iterations happen alone. Where the wireframes get translated into screens by hand, component by component, in silence. And then the hours pile up. On top of that, the mental load builds. The rest of the team moves on while you are still assembling.

UI execution is different from the stages before it. It is not one handoff. It is hundreds. Every screen, every component, every state, every variation is counted. You are holding the user research, the product constraints, the design system, the technical constraints, and the business goal all at once, and translating them into pixels one decision at a time.

The rest of the process speeds up because AI is good at synthesising from context. UI execution stayed slow because it is about assembling, with hands, and we never separated the assembly from the parts around it.

Until I ran an experiment to see if that could change. If agentic UI execution could work. I got it!

How agentic UI execution works

Three pieces work together. Claude holds the context. Everything I know about the user, the product, and the business is stored in a Claude Project. Figma Console MCP is the bridge between Claude and where your design happens, or I would say, your canvas. And Figma is where the work happens. The screens get built in the source file, using my actual design library that I built.

Think of Figma Console MCP as a connector, not a plugin. It brings Claude directly inside my Figma environment, reading what is there and executing changes on my actual files, with my components, my tokens, and my structure.

Claude is not working from a description of my design system anymore. It is working from the source.

I chose Claude specifically because my project context already lives there. Everything Claude knows about the project travels with it into Figma. That continuity is the whole point.

I am a product designer, and I am proud of three things in my work

The taste

Knowing what good looks like. Judging which component fits the context, what hierarchy feels right, where to break a pattern and where to hold it.

The craft

The foundational design knowledge. Principles, typography, spacing, accessibility, interaction patterns. The stuff that took years to build.

The assembly

The act of putting it all together. Taking the user flow, pulling from the design library, constructing the screens. Making something usable and buildable.

We usually talk about these as one job. They are not. They are three.

The assembly part is what’s actually draining us

The taste stays fun. The craft stays meaningful. The assembly is what drains us. It is manual. It is costly. It is tedious. It is the part that takes hours and leaves you with nothing to show for your skill, because the skill was spent on repetition, not judgment. If assembly stops eating our time, here is what we get back.

🕒 Time
Hours that used to go into building screen variations can go into the work only a designer can do.

🔥 Cost
Less designer time on mechanical work means projects move faster, and design becomes cheaper to scale without losing quality.

🧠 The mental load
No more holding every decision in your head. No more losing context every time you switch tools. No more translating feedback and ideas back and forth between Figma and everywhere else.

That last one is the part that keeps me up at night more than the others.

What success looks like

Before I introduce the tool, let me say what I was trying to achieve.

AI as the context keeper.
The information about the user, the product, and the business should travel with me into Figma, not get re-explained every session.

AI as the assembly assistant.
The mechanical work of putting screens together should be something I review, not something I build from scratch.

Taste and craft stay human.
These are the parts I want to protect, because these are the parts that make the design good.

Unlocking the capability

To get there, three things need to work together: Claude and Figma connected, your design library machine-ready, and your context is set up properly.

What you’ll need before you start

• Figma desktop app (MCP does not work in the browser version)
• Claude Pro or higher (for Claude Projects)
• A design library that meets the criteria below

Okay now let’s get to it!

1. Set the stage: get Claude and Figma talking to each other

Two things need to shake hands first. A bridge and a token.

1.1 Install Figma Console MCP
Follow Figma’s official MCP setup guide in the desktop app’s plugin settings. The browser version will not work here.

1.2 Set up the token
The token is a personal access key from your Figma account settings. It is how Claude gets read and write access to your files. Go to Figma > Account Settings > Personal Access Tokens to generate one.

1.3 Verify the connection
Once the bridge is running and the token is in place, test it. Direct Claude to draw a pink circle in Figma. If it appears on your canvas, that is the handshake. You got it right. But if it does not, restart the bridge, check the token scope, and try again.

1.4 Give Claude your project context
Claude needs to know about the project before it can help. I use Claude Projects to keep everything in one place: user research, product requirements, business goals, design principles, brand guidelines. All uploaded as files so Claude can pull from them in any chat I open.

This is the part that makes Claude a context keeper. Without it, every session starts from zero.

Once the connection is working, the next constraint is your design library. This is where most of the real preparation happens.

2. Get your design library machine-ready

The setup is the easy part. The real work is making sure your design library is something an AI agent can actually read and use. This is foundational work the whole team benefits from. It is not a designer’s side project, and it is exactly the kind of investment designers are positioned to make.

Four things matter.

2.1 Complete variant states
Every component covers all its states: default, hover, focused, disabled, error, loading. Gaps force the agent to improvise. And improvisation is where drift starts. The agent fills the gap with something that looks plausible, and your library slowly stops being the source of truth.

2.2 Annotated component descriptions
Each component carries a usage note. When to use it, when not to, what it signals to the user. Without this, the agent picks by shape, not by intent. A button that looks secondary gets used as a secondary button, even if it was designed for a destructive action. The description is what tells the agent why the component exists.

2.3 Token-linked styles
Colour, typography, spacing, all tied to tokens, not hardcoded values. The agent applies decisions through the token system. Hardcoded values break propagation, and propagation is how a design library stays consistent at scale.

2.4 Auto layout throughout
Components built with auto layout so the agent can resize and reflow without breaking structure. Fixed frames produce fixed output. If the agent cannot resize a component to fit the context, it either breaks the component or skips it.

The principle underneath all four is the same. The agent is not looking at your library. It is reading it. Everything that communicates visually to a human needs to communicate structurally to a machine. And if you are not sure where your library stands, Figma Console MCP can also help you audit it. Get it to flag what is not readable before you start building.

Once the setup is done and the library is ready, it is time to see it work.

3. Run your first wireframe-to-UI test

3.1 What context to give Claude
The context I give Claude before any screen gets built is more important than the prompt itself. Claude needs to understand the intent and the goal of the screens before it can build them. Here is what I put in the context:

👤 The user, and what they are trying to do.

📦 The product, and what problem it solves.

💼 The business goal behind this particular screen.

🎨 The design principles I want Claude to respect.

And then: the wireframe I want Claude to turn into a UI.

3.2 The context engineering that worked

3.3 What came back and what needed refinement

And… that was it! That was the test. But let’s look at where this actually changes the workflow.

The part where it improves our workflow

The real value is in the work where we actually spend the most hours, pushing pixels when it should be more efficient.

Derivative design.
Take one approved master screen and generate the rest of the flow. The settings page, the profile page, the confirmation page. What used to be hours of building from scratch is now a review pass. The time went somewhere better.

Different states.
Take one approved component and generate every state. Default, hover, error, loading, empty. What used to be tedious multiplication is now a review pass.

This is where the shift in where your time goes becomes obvious. You are not assembling the variations. You are reviewing them. And the review is the part that needs your judgment, so your time is finally going to the work only you can do.

Agentic UI design execution in your workflow

With the setup in place and the library ready, MCP becomes part of how you work. Here is the honest perspective.

Where it helps.
File hygiene becomes automatic. Layer naming and component organisation happen in seconds. Global variables sync across libraries without manual propagation. Design tokens match code before handoff, which makes developer handoff meaningfully cleaner. Accessibility issues and broken components surface through automated audits. Project context persists, so the agent is not working from scratch every session.

Where it breaks.
The setup is a barrier. A local bridge, a plugin, and real configuration work. Vague prompts have destructive potential. The agent can make edits that are accidental or hard to reverse. Large files consume significant API and token resources. Complex auto-layout and responsive logic still need manual refinement. The agent lacks intuition. It needs human oversight for deep UX and brand alignment.

None of these are reasons not to do this work. They are reasons to do it with eyes open, with a designer who knows their craft, and with realistic expectations about where the tool helps and where it does not.

The real gains

The shift is not about doing more. It is about where the time goes.

The taste got more of my time. I spend more of my day deciding what good looks like and less of it producing it. The craft got more of my time. I think more about principles, patterns, and accessibility, because I am no longer running out of energy building the screens.

The assembly got less of my time, and that is exactly what I wished for. The mechanical work is done by the agent. The review is done by me.

So, what’s next?

I am still tinkering. The prompts can get sharper. I am still figuring out what context matters most and what I can leave out. The library is never fully ready. Every new pattern needs to be made machine-readable before the agent can use it, and that is an ongoing piece of work.

Some things still need to be done manually. Complex responsive logic. Brand-critical screens. I do not use the agent for everything, and I do not think that is necessary. It still needs real designers.

The true value of AI is when it enhances human capability. Thinking and executing strategically. Taste stays human. Craft stays human. Assembly becomes agentic.

That is what this experiment showed me, and it is why I am going to keep going.

If you want to try this with your team, let’s talk. Reach out to me or anyone at Stampede on LinkedIn.

The post How I used AI to close the gap in UI design workflow appeared first on Stampede: the strategic design & technology company.

Now think about your favourite digital services: the ones that just feel effortless to use. Every interaction flows naturally, and it all feels part of the same trusted experience. That’s not by accident. It’s the result of a well-structured design library, working behind the scenes to create consistency, scalability and trust.

As both a designer and a user, I’ve had my fair share of frustrations with clunky interfaces and mismatched branding in UI. And because of that, whenever I kick off a new project, I’m determined to avoid those pitfalls by building a solid foundation: the design library.

So in this article, I hope to share why building a robust design library is the key to tackling these pain points and creating seamless user experiences at scale. It’s also why I’m driven to write this: I’ve seen firsthand how a well-crafted design library can transform not just a single app, but an entire organisation’s digital ecosystem, something I’ll share further as we go along.

Design library vs design system

I will focus specifically on design libraries in this article rather than the broader concept of design systems. In simplest terms, a design library is a curated set of style guides and reusable interface elements like typography, color palettes, and buttons, that help teams maintain a consistent look and feel. A design system, on the other hand, goes a step further by having code-ready components, more extensive documentation, and processes that unify the way teams update and govern the design system.

While design systems offer a more comprehensive framework involving deeper collaboration with developers and product teams, most organisations might not need to start there. Instead, a solid design library lays the groundwork, setting the stage for a more scalable design system as the product and organisation evolve. Think of it as an early-stage design system, delivering immediate benefits in consistency and efficiency without overcomplicating things.

What makes a design library great

In the years designing products across startups and enterprises, I’ve learned one crucial lesson: the bigger or more complex the organisation, the more important this foundation becomes. Let me explain why.

First, design library is your brand’s digital DNA

When most people think about design libraries, they picture a collection of UI components from popular design systems like shadcn/ui, Bootstrap, or the default iOS and Android UI kits. Just grab a UI kit, change some colours, and call it a day. While this might work for simple products, we’ve learned the hard way that it comes with significant costs, especially for complex products and enterprise projects.

When a design library doesn’t carry the brand’s DNA, it leads to a generic-looking product, making it hard for customers to distinguish your brand from competitors. Look at Netflix, Duolingo, or Instagram, you can recognize them instantly, even without seeing their logos. That’s because the most successful businesses invest in design libraries that truly reflect their identity, extending beyond colors and fonts to shape the entire user experience.

I saw this firsthand while we designed a mobile app for manufacturing plant performance monitoring. Rather than defaulting to a generic enterprise style, we worked closely with stakeholders to channel their brand DNA of efficiency and innovation into the design. We introduced a sleek dark mode interface that highlight key metrics without overwhelming the user, while giving the product a modern, cutting-edge feel. These choices not only supported advanced data visualization but also aligned seamlessly with the company’s future-focused vision.

Similarly, our work on the HMI Group hospital website was centered around building trust, an essential factor in healthcare decisions. The brand DNA was translated into the digital experience by focusing on clarity, warmth, and professionalism. We used clean, structured layout to make medical information easily accessible, a reassuring color palette that conveys safety and expertise, and real imagery of doctors and patients to create a sense of reliability and human connection. These design choices helped establish a confident user experience, ensuring patients felt informed and supported at every touchpoint.

Handles the real-world complexity when basic UI kits fall short

One real story stands out. A Global Fortune 500 energy company approached us to revive a project that had failed three times and cost millions. When we looked deeper, we realised the core underlying issue. The previous teams had built solutions without validating their assumptions with actual users. Without a structured design library to support rapid prototyping and testing, each iteration became expensive and time-consuming, making real user validation impractical.

The impact then was clear: users struggled with complex workflows and data visualizations that didn’t match their mental models or daily needs. What could have been caught early through proper user testing had instead led to costly rebuilds.

We knew we had to take a different approach. So we started by asking questions like:

• How can we use a design library to accelerate our user validation process and reduce the cost of iterations?
• What patterns do users actually need for interpreting complex operational data effectively?
• How do we ensure our design system supports continuous user feedback and evolution?

From there, we built a design library that made complex industrial data analysis and reporting more accessible and intuitive. We implemented:

• Legible typography with a clear hierarchy, ensuring key figures stood out for instant recognition.
• Strategic spacing and balanced UI density prevented data overload by grouping related metrics, making dashboards structured yet easy to scan.
• Color coding provided quick visual insights such as greens for positive trends and reds for warning, to help users identify key data points at a glance.
• Visual cues like progress status and last-update indicators enhanced clarity, ensuring users could quickly interpret real-time data without unnecessary friction.

What truly excited us over the years was seeing the design library evolve into a scalable enterprise solution that served diverse user needs, from engineers tracking real-time equipment data to executives analyzing company performance metrics. Despite their distinct needs and technical expertise levels, users experienced a consistent, efficient interface throughout.

Designed for real people and real needs, instead of generic user personas

Sometimes, the most valuable lessons come from specialised projects. Take VivaValet, a digital product we designed to make technology more accessible for elders. Generic design libraries would have failed here because they don’t account for age-related accessibility needs like declining vision, reduced dexterity, and cognitive differences. So we needed to go deeper. Through extensive UI research, we studied how elderly users learn, interact, and think about digital interfaces. This led to crucial design decisions, like:

• Increased text size from 16px to 24px for better readability and less eye strain.
• Carefully selected typography optimized for legibility.
• Enhanced touch targets to prevent accidental taps, accommodating users with reduced motor skills.
• High-contrast color schemes tested with vision disability tools, improving visibility.
• Simplified navigation patterns aligned with elderly users’ mental models.

As surprising as it may seem, culture plays a big role in design libraries. What works well in one region may not translate effectively in another. Working across Southeast Asia has taught me that digital behaviors, expectations, and even visual preferences differ dramatically. A one-size-fits-all design library risks alienating users, making cultural awareness a key factor in creating effective, scalable designs.

Through research and testing, I’ve found that cultural considerations impact several design aspects, including:

• Visual hierarchy and UI density – Apps in Asia often have denser layouts compared to Western counterparts. This reflects cultural differences in written language structure. Asian characters convey more meaning per symbol, leading to a preference for compact, information-rich interfaces. Western apps, by contrast, use more whitespace and minimalistic layouts.
• Color meanings and symbolism – Colors don’t mean the same thing everywhere. In the West, red often signals errors or warnings, but for Chinese, it represents luck and prosperity. Similarly, white conveys purity in Western cultures but is associated with mourning in some Asian traditions. Understanding these cultural associations prevents unintentional miscommunication.
• Bilingual interfaces that feel native, not translated – Direct translation isn’t enough. Sentence structures, reading flow, and emphasis vary across languages. For example, Malay and Thai sentence structures differ significantly from English, requiring thoughtful UI adjustments to ensure readability and natural phrasing.
• Local payment behaviors – Even digital payments aren’t universal; different regions have preferred methods. In Southeast Asia, QR code payments and bank transfers are common, while Western users are more accustomed to credit cards and PayPal. A well-structured design library must support these regional differences without overcomplicating the experience.

By embedding cultural awareness into design libraries, we ensure that digital products resonate with real users, fostering trust and engagement. Rather than applying generic user personas, we tailor experiences based on how people naturally interact with technology in different markets, ensuring usability, familiarity, and long-term adoption.

Not self-limiting but continuously evolve to scale

Early in my journey, I could get away with rigid design libraries for smaller products. But enterprise projects taught me a valuable lesson: if your design library can’t evolve, your digital platform can’t either.

A truly effective design library must anticipate growth, supporting new features, products, and even entire business lines as you scale. Ultimately, a robust design library is key to removing friction when your product suite expands, ensuring consistent user experiences across new markets, functionalities, and digital platforms.

How do you know if your design library is too rigid?

A rigid design library often creates more problems than it solves. Some telltale signs include:

• Hardcoded components that break or require extensive customisation when a new feature or product is introduced.
• Overly prescriptive guidelines that don’t allow flexibility for different teams, leading to workarounds and inconsistencies.
• Minimal documentation or poor onboarding, causing teams to misuse or abandon the library altogether.

What does a flexible design library look like?

Now, I build design libraries that are:

• Component-based and scalable, ensuring that UI elements can be easily repurposed for new services.
• Structured for modularity, so teams can mix and match UI patterns rather than being locked into rigid templates.
• Supported by clear documentation and onboarding, ensuring that internal teams and external vendors can adopt it seamlessly

We treat our design libraries as living documents, continuously engaging with stakeholders and testing with real users to identify pain points and opportunities for improvement. This feedback loop ensures our design libraries remain relevant and effective, allowing organisation to grow without sacrificing brand consistency or user experience.

The joy factor, making digital products people love

Even in business contexts, emotional connection matters. When we worked with TNG ewallet on their in app parking, a locally infused microcopy was essential to making this an immediately resonant touch point for Malaysians. Users loved it so much they shared screenshots of our playful writing on social media.

As a Malaysian born and bred UX design and development agency, we know Malaysians well. We believe that adding delightful, culturally relevant details is key to creating memorable experiences. By infusing the local culture into interface elements, microcopy, and overall design, we make digital products feel personal and engaging, even for something as everyday as parking or payment applications. This human touch can transform mundane interactions into moments of genuine delight.

Real business metrics improvements

Remember that Fortune 500 enterprise project we redesigned? The results speak for themselves:

• 90% Monthly Active Users (MAU)
• 30% improvement in Manufacturing Plant Cycle Efficiency
• 50% reduction in plant interruptions
• Expansion across 14 applications

While the design library wasn’t the sole driver of these metrics, it played a crucial role in enabling rapid prototyping, structured validation, and efficient design production, helping teams iterate faster and implement changes at scale.

What surprised me the most was seeing other projects within the same enterprise begin adopting the design library, amplifying its impact far beyond the original scope. With a shared system in place, teams could build upon existing components, reducing duplication and streamlining workflows. This is the testament to what I mentioned in the introduction: a well-structured design library doesn’t just improve a single app; it has the potential to scale across an entire digital ecosystem of the organisation.

Over time, we’ve consistently seen how a well-structured design library accelerates operational excellence:

• Product and development teams release features faster
• Different departments easily maintain a unified brand
• Updates and maintenance become more efficient
• New team members quickly get up to speed
• External vendors deliver high-quality work with fewer inconsistencies

Ultimately, these metrics highlight that a well-structured design library isn’t just about looks; it’s a strategic asset that boosts operational efficiency, ensures user satisfaction, and strengthens brand credibility across the entire organisation.

Hard-won lessons: what actually works

After building design libraries for everything from small startups to major enterprises, here’s what I’ve learned:

Lesson #1: Start with understanding

Instead of jumping straight to UI components, start by understanding your users, operations, and vision. The strongest design libraries are built on deep insights, ensuring they address real needs rather than just assembling UI elements.

Lesson #2: Build for your reality

Focus on creating components that solve your specific challenges. Align your library with your team’s workflow and product requirements so it grows with your needs instead of forcing unnecessary constraints.

Lesson #3: Think long-term

Approach your design library as a strategic investment rather than a quick fix. The most successful libraries support where organisations are going, not just where they are today.

Lesson #4: Test with real scenarios

The true test of a design library is how well it handles your most complex use cases. Every library improves dramatically through thorough testing with users in real scenarios.

In fact, we’ve found that with the right foundational elements in place, you can go from hypothesis to user-tested prototype in a 5-day design sprint. Because the UI components already adhere to consistent branding and standards, teams can focus on testing new ideas, rather than building everything from scratch.

Final thoughts: Building a foundation for lasting impact

A well-designed design library is more than just a collection of UI components. It’s a foundation for digital success. By investing in a robust, flexible library, you can accelerate product development, create user-friendly experiences, and ensure your brand stands out in an increasingly crowded market.

At Stampede, we’ve helped organisations build design libraries that truly transform their digital capabilities. If you’re considering this for your organisation, let’s discuss how we can create something that doesn’t just look good, but delivers real impact. Reach out to studio@stampede-design.com

The post Design Libraries: The Key to Success (or Failure) appeared first on Stampede: the strategic design & technology company.