Over the past year, we’ve been exploring how AI can actually work inside a design tool.

We started with Merge AI, introducing features like AI Component Creator and AI Helper. These helped us understand where AI works well — and where it breaks down.

One pattern kept coming up:

AI can generate UI.
But that’s no longer the hard part.

The real challenge starts after.

Where AI UI tools fall apart

Most AI tools today can generate something that looks good.
But when you try to use it in a real product, things get harder:

❌ the UI doesn’t match your components

❌ it drifts away from your design system

❌ you lose context after a few changes

❌ you end up rebuilding most of it anyway

Instead of speeding things up, AI often creates a second workflow:

One for exploration.
One for actual implementation.

What we wanted to fix

At UXPin, we’ve always focused on one idea:

Design should stay connected to code.

With AI, that became even more important.

We wrote about this in Design is a craft. AI is just a better workshop — the idea that AI shouldn’t replace the craft of design, but should make the workshop better. The tools should get smarter, but the designer stays in control.

We didn’t want to build another tool that just generates UI.

We wanted AI to become part of the workflow — something you can iterate with, not restart every time.

That’s why we built Forge.

Introducing Forge

Forge is the AI system powering UXPin.

It brings generation and editing into one continuous workflow:

🎨 Start with a prompt, image, or URL

🔄 Refine layouts step by step

✏️ Edit components directly

🔀 Switch between AI and manual changes anytime

Instead of restarting, you keep moving forward.

👉 Try Forge in UXPin

Start designing with AI that works with real components and design systems. → Explore Forge

Built around real systems, not mockups

Forge works with real components.

That can mean:

• built-in libraries
• or your own component library
• or even defined design system guidelines

So the output stays aligned with how your product is actually built — not just visually, but structurally.

From output to iteration

One of the biggest shifts for us was moving away from “one-shot generation”.

Most AI tools generate something once.
If it’s not right, you start over.

Forge is built around iteration.

It keeps context across steps, so you can refine instead of restart. More like working with a teammate than using a tool.

What about the code?

If AI generates UI, the code matters.

Forge outputs clean JSX based on real components.

Not a mix of frameworks.
Not something you have to rewrite.

Something you can actually ship.

👉 See how Forge works in practice

Watch how UI is generated, refined, and edited using real components.
→ Try it yourself

A shift in how AI fits into design tools

Forge isn’t just another AI feature.

It changes how AI fits into the product.

Not a separate generator you use once and leave.
But part of how you design and iterate.

What’s next

The next direction for UXPin is enabling teams to go from UI to a working product experience with real logic.

Not just screens — but flows that behave like the final product.

We’ll share more soon.

👉 We just launched Forge on Product Hunt
If you’re exploring AI in design workflows, we’d love your feedback.

I’m the CEO of UXPin. We built an AI design tool called Forge. So yes, I have a horse in this race.

I spent the weekend testing Claude Design on real projects. Seven PowerPoint slides. A landing page concept. A component exploration. It burned through over 50% of my weekly tokens before I even got to refinement.

Here’s my honest take.

What Claude Design gets right

It’s genuinely good at getting non-designers from idea to visual quickly. Founders, PMs, marketers who need a pitch deck or a mockup without opening Figma — this is a real workflow improvement. The questionnaire that forces design decisions upfront is clever. The output is aesthetically strong. I’m not going to pretend otherwise.

For personal projects and early exploration, it’s impressive.

What everyone’s getting wrong

The claim I keep seeing: “It reads your codebase and uses your components.”

It doesn’t.

Claude Design reads your codebase and extracts visual patterns — colours, typography, spacing. It then generates new elements styled to match those patterns. That’s approximation, not usage.

When Claude Design generates a button, it creates something that looks like your button. When Forge generates a button, it places your actual Button component — same props, same variants, same states, same code your developers ship.

Reading a codebase gives you visuals that look like your product. Syncing a component library gives you the real thing.

That’s not a feature difference. It’s an architectural difference. And it shows up fast.

Multiple designers reported design system drift during their first sessions: wrong fonts, incorrect button colours, inconsistent spacing. One spent more time fixing the AI’s mistakes than it would have taken to build from scratch. That’s not a bug — it’s the inevitable result of approximation.

The prompt lock-in problem

Here’s the issue nobody’s naming: in Claude Design, the AI is the only way to interact with your own design.

Every adjustment — spacing, colour, layout — routes through the AI model and costs tokens. Users on the Max plan reported hitting their weekly limit in 2–6 hours. The community quickly developed a mitigation strategy: Opus for the first prompt, Sonnet for edits, Haiku for minor tweaks.

That this strategy is necessary tells you something.

Adjusting spacing shouldn’t require a round-trip to an LLM. It shouldn’t cost credits. It should be a design tool.

At UXPin, Forge handles the generation. Then you switch to professional design tools on the same canvas — same components. Layout adjustments, prop tweaks, variant exploration, responsive breakpoints. No tokens burned. AI for the scaffold, design tools for the craft.

The output question

Claude Design exports to Canva, PDF, PPTX, HTML, or hands off to Claude Code. That handoff is positioned as a closed loop, but Claude Code still interprets the design and generates new code. It’s a translation step.

Here’s what UXPin actually exports — real output from a Forge-generated card:

import Button from ‘@mui/material/Button’;
import Card from ‘@mui/material/Card’;
import TextField from ‘@mui/material/TextField’;
import Typography from ‘@mui/material/Typography’;

<Card >
<CardContent>
<Typography variant=”h5″>Create Account</Typography>
<TextField label=”Full Name” variant=”outlined” fullWidth />
<TextField label=”Email Address” type=”email” fullWidth />
<Button variant=”contained” fullWidth>Sign Up</Button>
</CardContent>
</Card>

That’s production-ready React with real MUI imports. Developers copy it and ship it. Nothing to interpret.

Who should use what

Use Claude Design if you don’t have an existing design system, you need quick mockups or pitch decks, or you’re a founder/PM who needs something visual without a design tool.

Use UXPin with Forge if your team has a custom component library, design system governance matters, you need production-ready code output, and designers need real tools for refinement — not just a prompt box.

Use both if your team wants Claude Design for early exploration and UXPin for production design with real components. They solve different parts of the workflow.

The question nobody’s asking

Claude Design isn’t a threat to tools that generate with real components. It’s a threat to tools whose only value is the AI model underneath.

If your tool’s entire value is “prompt in, AI output out,” you’re building on infrastructure controlled by your biggest competitor. Anthropic will always be better at their own model.

UXPin’s value is the component architecture — Git sync, real component rendering, production code output. That existed before AI. Forge makes it faster, but the moat is the component layer, not the model layer. We already support both GPT and Claude models. The model is interchangeable. The architecture isn’t.

The question isn’t whether AI labs will enter your vertical. It’s whether your value survives when they do.

What didn’t change

AI generates the happy path. Every time. Error states, edge cases, accessibility, the flow that handles the user who clicked the wrong thing twice — that’s still human judgment.

We named our AI tool Forge for a reason. A forge doesn’t replace the blacksmith — it gives them heat and speed. The craft still requires human judgment. Claude Design reinforces that truth, not undermines it.

This is a condensed version. The full analysis with comparison table, FAQ, and detailed architecture breakdown is on the UXPin blog.

If you want to see the difference firsthand: try Forge free at uxpin.com/forge

Blacksmithing is one of humanity’s oldest professions.

The tools have evolved dramatically over centuries. Bellows became power hammers. Hand files became CNC machines. The forge itself went from burning coal to burning gas to electric induction.

But the blacksmith still exists.

Why? Because the craft requires something tools can’t replicate. Judgment about materials. Knowing when something is “right.” Adapting to the specific problem in front of you. Skill that compounds over years of practice.

The tools change. The craft endures.

The anxiety is real, but misplaced

There’s a lot of fear in the design community right now. Every week brings another AI tool that can generate interfaces, write copy, produce variations. The demos are impressive. The implication feels threatening: maybe designers aren’t needed anymore.

I don’t buy it.

What I see is a fundamental misunderstanding of what AI is and what design actually requires.

AI is a tool. A powerful one. It can generate, suggest, accelerate. But it can’t judge whether something is right for this user, this context, this business problem. It can’t hold the full picture in its head. It can’t taste.

That’s still you.

The question isn’t whether AI will replace designers. It’s whether designers will learn to use AI as a tool — the way blacksmiths learned to use power hammers instead of swinging manually all day.

The craft stays. The workshop gets better.

The problem with AI design tools today

Most AI design tools work like this:

1. You describe what you want
2. AI generates something
3. You hope it’s close
4. If it’s not, you start over or get stuck in prompt loops

That’s not how design works.

Design is iteration. It’s refinement. It’s shaping something through dozens of small decisions until it’s right. You don’t start from zero every time — you push, pull, adjust, respond.

Current AI tools treat design like a vending machine. Insert prompt, receive output. But design is more like sculpting. You need to keep working the material.

There’s another problem too.

Most AI tools generate pixels. Objects that look like interfaces but aren’t connected to anything real. A button that looks like your button but isn’t actually your button — the one engineers use, the one that’s in your design system, the one that ships.

So what happens? AI generates something impressive. Then engineers rebuild it from scratch anyway. No reuse. No trust. No real speed gains.

Impressive isn’t the same as useful.

What we built — and why we called it Forge

We’ve spent the last year asking a different question: what would AI look like if it was built for how designers actually work?

Not generate-and-hope. Not start-from-scratch every time. Not a separate tool you have to leave your workflow for.

Something that stays with you. Keeps context as your design evolves. Lets you take over manually whenever you want.

We called it Forge.

The name isn’t arbitrary. A forge doesn’t replace the blacksmith — it gives them heat, speed, power. The smith still shapes the metal. The anvil provides the foundation. The hammer gives precision when you need it.

That’s the relationship we wanted between designer and AI.

You’re the smith. You have the judgment, the taste, the understanding of the problem.

Your design system is the anvil. It’s the solid foundation you shape against — your components, tokens, patterns.

Forge is the heat. It accelerates transformation, but you’re still in control of what gets made.

Manual tools are your hammer. When you need precision, you take over. Forge and UXPin’s design tools work together, not as separate modes.

Real components, not pixels

Here’s what makes Forge different from other AI design tools.

Forge is built on UXPin Merge. That means when you design with Forge, you’re designing with real, coded components — the same ones engineers use in production.

Not a visual replica. Not a Figma approximation. The actual React components from your design system.

When AI generates a variation, it’s not generating a picture of a button. It’s placing your real button, with your real props, your real styles.

What you design is what ships.

This solves the core problem with AI-generated designs. Engineers don’t have to rebuild anything. There’s no translation layer. No gap for things to get lost.

The design and the code are the same thing.

How Forge actually works

Forge lives inside the UXPin Editor. You open it, select your library (global libraries such as MUI, ShadCN etc or your own custom library from GIT or Storybook) describe what you want, and start working.

But unlike other AI tools, the conversation doesn’t end after one prompt. Forge keeps context as you iterate. You can say “make the header bigger,” then “try a different layout,” then “add a secondary action” — and Forge remembers what you’re working on.

When you want to switch to manual editing, you just… do. There’s no export, no conversion. The design is already real. You can tweak a component directly, adjust spacing by hand, then go back to Forge for the next iteration.

AI and manual tools aren’t separate workflows. They’re the same workflow.

You can also connect your design system guidelines to Forge, so generated output stays consistent with your styles, spacing, and patterns. It’s not generic AI output — it’s your design system, accelerated.

The craft endures

AI is changing design tools. That’s undeniable.

But tools have always changed. What remains constant is the need for people who can judge, decide, refine, and solve problems that don’t have obvious answers.

Blacksmiths didn’t disappear when power hammers arrived. They got more productive. They took on more complex work. They spent less time on the mechanical and more time on the craft.

That’s the future for designers too.

Forge is our bet on that future. AI that accelerates the work without replacing the worker. Tools that get better while the craft stays human.

The tools change. The craft endures.

Try Forge

Forge is available now in UXPin for all accounts with AI enabled and available for 14 days free with a new trial.

Open any project, find Forge in the bottom bar, and start working.

Get started today at uxpin.com/signup

Last year we launched Merge AI to show a simple idea: AI should create interfaces you can actually ship — not just pretty pictures. Since then, thousands of teams have used Merge to turn prompts into layouts with open-source libraries.

This week we’re shipping Merge AI 2.0. It’s faster, more precise, and most importantly — it stays grounded in your components from start to finish.

👉 We just launched on Product Hunt! Come say Hi, ask anything, provide feedback and grab the launch promo discount code!

Why this matters (and what we heard)

AI can draft a UI in seconds. But if it ignores your component library, someone pays the price later: devs rebuild it, design drifts from code, and velocity drops.

Design teams told us they needed:

• Real components in, real components out.
• Refinement without starting over.
• A path to their own design system (not just OSS libraries).

That’s exactly what Merge AI 2.0 does.

What’s new in Merge AI 2.0

1) Refine with AI Helper (no reset button)

Generate a dashboard, then tell the AI Helper:

“Make this denser, admin-style; tighten table columns; swap primary to tertiary.”

It updates the coded components in place. Keep iterating without wiping your work.

2) Image upload → component-aware layout

Drop in a screenshot or sketch. Merge analyzes structure and recreates it using real components (e.g., MUI Table, Shadcn Button). You keep the fidelity and the semantics.

3) Prompt Library

Use optimised prompts from UXPin’s own prompt library that we know work well. Choose pre-written promps for basic componenets, key sections and even layouts, or select one at random to see what happens!

4) Better models, cleaner outputs

We’ve tuned layout, spacing, and copy defaults so the first pass is closer to what you’d actually ship. We’ve also added the latest and best performing LLMs.

5) Expanded OSS libraries

Out of the box, generate with:

• MUI
• Shadcn/UI
• Ant Design
• React Bootstrap

…and better yet, you can easily swap between libraries per project, or even use your own custom library.

6) Code-backed templates

Don’t want to start with AI or manually? That’s fine. Choose from our range of code-based, optimized templates. Refine by your preferred design library and easily iterate to make it your own.

A 60-second tour

1. Load into the UXPin editor and select the AI button.
2. Pick your preferred global library (e.g., MUI) or your own (if integrated)
3. Start with your own Prompt, or select one from our prompt library.
4. PromGenerate: Merge outputs a layout using only MUI components (or whichever library you selected).
5. Refine: Ask the AI Helper to densify spacing, switch button variants, or add a side nav.
6. Handoff: Export code or hand the exact components to your devs.

No throwaway mockups. No rebuild loop.

Built for the way teams really work

• Designers: Skip blank canvas. Get a shippable first pass, then polish by hand.
• PMs / Ops: Start from code-backed templates; ship internal UIs without waiting in line.
• Developers: Receive layouts already composed from your library — stop redrawing in code.

“Can it use our own components?”

Yes. If you maintain a custom React component library, Custom Library AI (Merge Enterprise) lets you:

• Connect your Git repo to Merge
• Expose your components/tokens
• Generate and refine UI using your building blocks

This is the bridge to “AI that stays inside your design system.” If that’s you, reply and we’ll set you up.

How this compares to “AI page builders”

• They generate whatever looks nice.
• Merge AI generates with real components (MUI/Shadcn/Ant/React Bootstrap or yours).
• They hand you a picture.
• Merge hands your devs something they recognize — and can ship.

Who’s using it already?

• Product teams building dashboards and settings flows
• Internal tools teams standardizing admin UIs
• Design-ops groups turning patterns into reusable templates
• Enterprise UX teams such as Amazon, American Automobile Association, and T. Rowe Price leverage their own custom library with AI.

Getting started in three simple steps:

🎁 Product Hunt launch promo: redeem the PH code now.

Road to early next year: Design-System-Native AI

Today, Merge AI 2.0 delivers smarter AI grounded in real components — plus an enterprise beta for bringing your own library via Git.

Early next year, we plan to introduce an AI chat prototyping assistant to make creating and refining code-backed UIs faster and more natural inside Merge.

In parallel, we’ll keep expanding the custom library beta toward stronger design-system guardrails and governance — guided by what enterprise teams are actively using and what we learn from real-world workflows.

Be sure to follow us on ProductHunt to be notified of all future releases.

FAQs | UXPin Merge AI 2.0

Does UXPin Merge replace Figma?
It can, but many teams use both. Merge shines when you want code-backed design and AI that respects components. Use the right tool for the moment.

Can non-designers use this?
Yes! With the addition of templates and AI prompt assistance; Merge is easier to use than ever. That’s the point: self-service without chaos.

Do you support accessibility?
We lean on the accessibility built into the components you choose. Custom library beta inherits your rules.

Thank you 🙌

This release was shaped by thousands of conversations with customers who asked for one thing: AI that respects the system. We’re not done — but Merge AI 2.0 is a big step toward turning ideas into shippable UI.

👉 We’re live on Product Hunt — drop a question, get a free trial or demo, and tell us what to build next.

— Andrew & the UXPin team

Tackling a fragmented ecosystem

The newly launched MCP Registry seeks to address the challenges developers face when integrating AI agents into their toolkits. According to GitHub, the current landscape of MCP servers is fragmented, with resources scattered across registries, repositories, and community threads. This disorganization has made it difficult for developers to find the right tools efficiently while also raising concerns about security and interoperability.

“If you’ve tried connecting AI agents to your development tools, you know the pain: MCP servers scattered across numerous registries, random repos, buried in community threads — making discovery slow and full of friction without a central place to go”, said Toby Padilla, Principal Product Manager at GitHub. “Meanwhile, MCP server creators are worn out from publishing to multiple places and answering the same setup questions again and again. The result is a fractured environment that’s fraught with potential security risks.”

Padilla emphasized that the launch of the MCP Registry is a step toward solving these issues. “Today, we’re taking the first step toward solving this challenge. The GitHub MCP Registry launches as a new home base for discovering MCP servers. Whether you’re building with GitHub Copilot, agents, or any AI tool that speaks MCP, this is the place to find what you need”, he added.

Streamlined MCP integration

MCP, or Model Context Protocol, is an extensible framework that facilitates communication between AI agents and development tools. The protocol allows agents to access and interact with external systems, enabling more advanced workflows for software development teams.

The MCP Registry is designed to make MCP server discovery seamless within development environments such as VS Code, offering one-click installation options. Developers can also sort servers based on GitHub community activity and star ratings, helping them select tools that best suit their needs.

Collaborative efforts with industry leaders

The launch of the registry includes a curated selection of MCP servers from notable partners such as Figma, Postman, HashiCorp, and Dynatrace. These integrations showcase the potential for enhanced workflows and connectivity in software development.

Anna Kohnen, VP of Business Development at Figma, highlighted how the registry supports design-to-code workflows: “With the launch of GitHub’s MCP Registry, developers can easily bring Figma context into Copilot through our Dev Mode MCP server, accelerating their design-to-code workflow by generating code that’s both production-ready and aligned with their design system.”

At Postman, the registry is seen as a critical step in creating AI-ready APIs. “At Postman, we see MCP as a foundational layer of the AI agents stack and a vital part of building AI-ready APIs. The GitHub MCP Registry helps developers access the entire Postman platform from inside their coding assistants, further bridging the gap between code, documentation, and execution in a way that wasn’t possible before”, said Bajali Raghavan, Head of Engineering at Postman.

HashiCorp’s contributions include their Terraform MCP server, which simplifies infrastructure management. “Terraform empowers developers with consistent infrastructure management. With the launch of GitHub’s MCP Registry, they can now easily discover official MCP servers, such as HashiCorp’s Terraform MCP server, and add them to their workflows with a single click — making it faster than ever to bring Terraform’s capabilities into day-to-day development”, said Chris Audie, SVP Product Management at HashiCorp.

Dynatrace also brings AI-powered observability and performance tools to the table. “By bringing the Dynatrace MCP server to the GitHub MCP Registry, developers get AI-powered observability, security, and performance insights right at their fingertips — so teams can deliver faster, more resilient, and more robust software with less context switching and reduced cognitive load. We’ve seen rapid adoption across our own engineering organization because the integrated agentic AI experience helps our developers to ship faster and with more confidence — all without leaving their IDEs”, said Bonifaz Kaufmann, VP Product at Dynatrace.

Toward an open and collaborative ecosystem

In addition to its proprietary offerings, GitHub is collaborating with Anthropic and the MCP Steering Committee to establish an open-source MCP registry. This initiative will allow developers to self-publish MCP servers to the OSS MCP Community Registry, with those entries seamlessly appearing in the GitHub MCP Registry. The goal is to reduce redundancy, improve transparency, and foster broader contributions to the MCP ecosystem.

GitHub has also integrated its Remote GitHub MCP Server into the registry. This feature, which recently became generally available, enables AI agents to access GitHub repositories, issues, and pull requests, supporting sophisticated workflows across development teams.

By consolidating MCP servers into a unified platform, GitHub aims to make MCP server discovery as intuitive as searching on the GitHub platform itself. The MCP Registry represents a step forward in simplifying how developers integrate AI tools into their workflows.

Read the source

In the ever-evolving world of UI/UX design, bridging the gap between creative conceptualization and functional development remains one of the most critical challenges. The recent showcase by UXPin: “AAA’s Design Journey: Prototypes to Merge”, takes viewers into the heart of this conundrum, offering insights into how one team revolutionized their workflow with an approach that ensures consistency, efficiency, and breakthrough collaboration.

This article unpacks the lessons from the video and provides actionable insights for professional UI/UX designers, front-end developers, and design teams who are constantly looking to refine their design-to-development pipelines. Let’s dive into how AAA’s design journey can inspire your team to achieve seamless workflows and better product outcomes.

The Problem: Disconnect Between Design and Development

Every design team struggles with the same pain points: miscommunication between design and development, inconsistencies when transitioning from prototypes to live code, and inefficiencies that slow down the entire process. AAA’s design team was no different.

The video outlines how AAA’s initial workflow depended heavily on disjointed tools and methods. Design files often failed to translate accurately into usable code, resulting in repeated revisions, wasted time, and frustration across teams. Despite their best efforts, they found themselves battling version control issues, alignment problems, and a lack of design consistency.

This disconnect is a familiar challenge for many organizations, particularly as the complexities of modern user interfaces continue to grow. A solution that could harmonize design intentions with development realities was urgently needed.

The Turning Point: Rethinking the Workflow

Understanding the need for change, AAA’s team decided to overhaul their process. The primary shift? A workflow that centered around dynamic prototyping and merging.

Instead of treating design and development as separate silos, they adopted a unified framework where prototypes were the nucleus of the workflow. The video emphasizes how this approach helped their team:

1. Prototypes as the Single Source of Truth: By prioritizing prototypes as the definitive reference for both designers and developers, they eliminated the guesswork involved in interpreting design files.
2. Iterative Testing: Prototypes allowed for real-time testing of both design aesthetics and functional interactions, helping teams identify and resolve issues early.
3. Collaborative Tools: The adoption of collaborative software platforms enabled synchronized updates, creating a seamless bridge between design and development teams.

This pivotal shift allowed the team to align their goals, eliminate bottlenecks, and focus on delivering a consistent user experience.

The Solution: Prototypes with Real-Life Functionality

AAA’s new workflow placed a strong emphasis on prototypes that weren’t just visually accurate but also functionally interactive. This move helped to:

• Communicate Intentions Clearly: Developers could interact with designs in a way that mimicked the final product, minimizing misinterpretation.
• Facilitate Design Consistency: By linking prototypes directly to design systems, they established uniformity across all screens and interactions.
• Streamline Handoffs: Prototypes acted as a direct handoff mechanism, with fewer back-and-forth iterations between teams.

The video highlights how this approach translated into practical benefits: faster production timelines, reduced errors, and an overall increase in design quality.

Key Lessons from AAA’s Journey

AAA’s experience underscores the importance of rethinking traditional workflows to meet the demands of modern digital product development. Here are the three most critical takeaways:

1. Break Down Silos: Foster collaboration between designers and developers by using tools and workflows that encourage shared ownership of the product.
2. Prioritize Prototypes: Invest in creating interactive prototypes that serve as the single source of truth, reducing the scope for miscommunication.
3. Iterate and Test Early: By testing designs in real-world scenarios during the prototyping phase, teams can identify and address issues before development begins.

How You Can Apply These Lessons to Your Workflow

Professionals in the design and development space can draw actionable inspiration from AAA’s journey. Here are some practical steps to incorporate into your own processes:

1. Adopt a Unified Framework

• Choose tools that integrate seamlessly across design and development workflows. Examples include Figma, Adobe XD, or tools with code-export capabilities.
• Use a shared design system to maintain consistency across all deliverables.

2. Make Prototypes Actionable

• Go beyond static wireframes and create prototypes that mimic the functionality of the final product.
• Test these prototypes with stakeholders and end-users early in the process to gather actionable feedback.

3. Prioritize Collaboration

• Use collaborative platforms that allow designers and developers to work together in real-time.
• Establish clear communication channels and regular check-ins to ensure alignment at every stage.

Key Takeaways

• Interactive prototypes serve as the foundation for seamless design-to-development workflows.
• Cross-team collaboration is essential to achieving consistent and efficient outcomes.
• Testing and iteration during the prototyping phase can save time and resources later in development.
• A unified design system ensures consistency across designs, reducing errors and inconsistencies.
• Adopting collaborative tools and processes fosters shared ownership and accountability.

Conclusion: A Blueprint for Seamless Workflows

AAA’s design journey serves as a powerful case study for teams looking to modernize their workflows. By shifting their focus to dynamic prototyping and collaborative tools, they were able to bridge the gap between design and development, ultimately delivering products that were both functional and visually engaging.

For UI/UX designers, front-end developers, and design teams, the key lies in integrating processes and tools that encourage collaboration, consistency, and efficiency. AAA’s success proves that with the right approach, it’s possible to transform challenges into opportunities for innovation.

Take inspiration from their journey, and start rethinking how prototypes can empower your teams to build better digital experiences.

Use: Embedded for reference. Brief quotes used for commentary/review.

Interaction design is more than adding clickable buttons and input fields; it’s about crafting a meaningful experience that facilitates smooth user interactions and meets their goals. Whether it’s an intuitive form, a simple rating system, or a helpful alert, every interaction tells a story and enhances the user’s journey through an interface.

To help you master these elements, we’re thrilled to announce our latest eBook on interaction design patterns.

📚 Download the eBook here →

What Are Interaction Design Patterns?

Interaction design patterns are tried-and-tested solutions for common usability challenges. For example, an “error message” design pattern could tell users they missed a form field or entered an invalid email address, allowing them to correct it. Using patterns helps create familiar, consistent, and reliable experiences by reusing successful elements across different interfaces.

Why do Patterns Matter?

🎨 Consistency: Patterns offer users a sense of familiarity, making interfaces easier to use.

🏃 Efficiency: Designers and developers can implement known solutions, reducing time spent on complex problem-solving.

📈 Scalability: Patterns are adaptable and can be reused across different projects and contexts.

Our eBook is structured around the most essential patterns in interaction design, helping designers easily replicate these elements in their work.

📚 Download the eBook here →

What Will You Learn from the eBook?

This eBook isn’t just a collection of design patterns; it’s a resource for understanding the context, tools, and techniques needed to apply each pattern effectively.

A) Context of Use: When, where, and why to use each interaction design pattern.

B) Tools to Build Patterns: Practical guidance on using tools in UXPin to bring these patterns to life (including AI help in quickly building interfaces.)

C) Best Practices: Get do’s and don’ts on interaction design fundamentals, such as feedback, visibility, and ease of use.

D) Prototyping in UXPin: Tips for designing realistic, production-ready prototypes that replicate the final product experience.

Ready to Build Interactive Patterns?

If you’re ready to design user experiences that look and feel like the final product, our eBook will be your guide. Transform your interaction design skills, optimize usability, and create prototypes that drive engagement — all in UXPin.

📚 Download the eBook here →

What happens when your developers don’t like — or worse, don’t use — the design system you worked so hard to create?

Here’s the hard truth: even the best-designed systems can flop if they don’t meet the needs of developers. Without their buy-in, your design system is just a pretty set of guidelines collecting dust.

Let’s explore why developers might be avoiding your design system and what you can do about it.

Reason #1 Too Much Focus on Aesthetics.

One of the main reasons developers might avoid using a design system is because it prioritizes design details over functionality. Designers often focus on creating pixel-perfect components, but developers care about how easy these components are to implement.

If a design system is overly focused on visuals and ignores the practical needs of developers — like proper documentation or clear component structure — it creates friction.

👩‍🔬 Here’s the solution!

Bridge the Gap with Code-Integrated Design Systems

The most effective design systems prioritize both design and development needs. Platforms like UXPin allow designers to create components that are directly tied to code — ensuring that the components developers are implementing are fully functional and match the design exactly.

This method helps eliminate the gap between design and development, making the design system more functional and developer-friendly.

Reason #2 Lack of Flexibility

Developers often run into situations where a component needs to be customized for a specific use case. If your design system is too rigid, offering no flexibility for edge cases, developers may start bypassing the system entirely.

For instance, using a set component might require small adjustments for a specific feature. If the design system doesn’t accommodate those tweaks — or worse, if those changes aren’t supported — it forces developers to create their own solutions.

👩‍🔬 Here’s the solution!

Support Theming and Customization

One way to fix this is by offering theming options and flexible components that can adapt to different use cases.

MUI and Fluent UI, which are integrated into UXPin, are great examples of libraries that allow theming, giving developers control over how components look while still adhering to the overall design guidelines.

Incorporating this level of flexibility into your design system shows developers that the system is built to support them, not limit them.

Reason #3: Poor Documentation

This is a big one. Developers rely on clear, easy-to-navigate documentation. If your design system doesn’t come with thorough and up-to-date documentation, developers are likely to avoid it.

When developers need to spend more time trying to understand how to use components than actually implementing them, the system becomes a burden.

👩‍🔬Here’s the solution!

Dynamic, Developer-Centric Documentation

Documentation is the backbone of any successful design system. Especially the one that not only saves designers and developers from maintaining it but also one that ensures that everyone is always working from the latest version.

Make sure your documentation includes:

• Clear code examples (ideally in the frameworks your developers use).
• Usage guidelines: When and where to use each component.
• Customizable options: How to tweak components to fit different use cases.
• Accessibility considerations: Developers care about this too, so make it part of the component specs.

Reason #4: Inconsistency Between Design and Code

Another common frustration arises when the components in the design system don’t match the ones in the codebase. If developers spend more time trying to bridge the gap between what’s been designed and what can be coded, they’ll end up abandoning the system in favor of custom solutions.

👩‍🔬Here’s the solution!

Design and Code in Sync

Using tools like UXPin Merge, which allows you to use real, coded components in the design process, ensure that what designers see is exactly what developers will implement. This closes the gap between design and development, saving everyone time and ensuring consistency across the product.

This approach also helps when scaling the system, as developers can trust that components in the design system will work as expected in production.

Reason #5: Lack of Accessibility Focus

Developers are increasingly responsible for ensuring accessibility standards are met. If your design system doesn’t come with built-in accessibility features or guidance, developers are likely to either bypass the system or spend extra time building accessibility into the product themselves, which leads to frustration.

👩‍🔬Here’s the solution

Build Accessibility into the Core

Make accessibility part of your design system from the start. Color contrast checks, keyboard navigation guidelines, and ARIA attributes should all be part of your components.

UXPin, for example, has accessibility features that allow designers to create accessible components from the start. This saves developers from needing to retrofit accessibility later, making your design system a trusted source for accessible design.

Reason #6: Too Much Overhead

Sometimes, design systems create more overhead than they’re worth. If developers have to jump through hoops to implement simple components or get bogged down by rules and limitations, they’ll end up avoiding it altogether.

👩‍🔬Here’s the solution!

Start Simple, Grow Gradually

If your design system is still in its early stages, don’t overcomplicate it with too many rules or components. Start with the essentials — colors, typography, and a few key components like buttons or forms — and expand as needed. This way, developers can adopt the system without feeling like it’s a roadblock.

By keeping things simple and scalable, you can grow the system over time while making sure it always remains developer-friendly.

Collaboration is Key!

To ensure that your design system is embraced by both designers and developers, it’s crucial to create a system that prioritizes functionality, flexibility, and collaboration.

By using fullstack design tools like UXPin to keep design and code aligned, providing clear and dynamic documentation, and supporting accessibility and customization, you’ll create a design system that developers love to use — and that’s what truly makes a system successful.

Remember, a design system isn’t just for designers. It’s a living product that both designers and developers need to thrive with. Keep communication open and make sure the system works for both sides, and you’ll see your design system become a vital tool for the entire team.

Give UXPin a chance → Request an access.

Meet UXPin’s AI Component Creator — the revolutionary tool that brings your designs to life with just a few clicks.

Whether you’re working with static images or existing elements, our AI transforms them into fully coded components using MUI, Ant Design, React-Bootstrap, or Tailwind UI. Simply upload a sketch or right-click to convert, and watch your UI come to life — no coding required.

Ready to see it in action? Request a demo here or sign up for a free trial.

The Challenge of AI-Generated UI

Despite their potential, many AI-generated UI solutions fall short in real-world applications due to several challenges:

• Lack of Consistency: AI-generated designs often struggle to maintain consistent styles, layouts, and themes, making them difficult to integrate into existing projects.
• Image-Based, Not Code-Based: Many tools generate UIs as images or static elements without code, limiting their use for developers.
• User Data Privacy Concerns: Some AI tools use user data to train their models, raising privacy and security issues.
• Difficult to Maintain: The output often lacks scalability and adaptability, making it challenging to update or maintain as design requirements change.

How Does UXPin Solve it?

Unlike other tools that focus on images, UXPin creates interactive, code-backed components that are instantly usable for development.

• Generates Code-Backed Components: UXPin’s AI Component Creator generates fully functional UI components from popular open-source libraries like MUI, Ant Design, Tailwind UI, and React-Bootstrap. This ensures that the output is development-ready and easily integrates with your codebase.
• Seamless Design-to-Code Transition: Whether you start with an image, text prompt, or static UI element, the tool converts your input into consistent, production-ready code, maintaining the chosen library’s theming.
• Maintains Design Consistency: Using library-based theming and standards, UXPin ensures consistency across components, making your designs easier to scale and maintain.
• Using Open-Source Components: Unlike other tools, UXPin does not use user data to train external AI models, keeping your designs secure.
• Scalability and Easy Maintenance: The generated components are built for real-world applications, enabling you to scale, update, and maintain them as your project evolves.

What is UXPin’s AI Component Creator?

UXPin’s AI Component Creator revolutionizes how designers and developers bridge the gap between design and code. Imagine transforming an idea into a fully functional UI component within minutes. That’s exactly what this tool offers.

🤖 Generate UI Based on the Prompt

Write a text prompt describing the desired UI, and the AI will generate a fully coded component that matches your specifications.

🖼️ Turn Images into Functional UI

Generate production-ready UI directly from images or sketches to speed up prototyping and optimize design handoff.

🧩 Transform UI Elements into Code

Convert static UXPin elements that you put on the canvas into code-backed UI components. All you need is right-click an element and hit AI.

🎨 Automate Theming

Generate MUI components with predefined themes instead of inline CSS, ensuring design consistency and easy scalability.

How to Use AI Component Creator

1. Get an OpenAI API Key: Sign up on the OpenAI website and generate your API key.
2. Enable AI Component Creator: Contact UXPin support to activate this feature if you’re on the Merge AI plan or have Merge enabled
3. Open AI Component Creator: Navigate to the Editor and access it from the Quick Tools panel.
4. Enter the API Key: Go to the Settings tab and paste your OpenAI API Key in the designated field.
5. Generate Components: Open the Prompt tab to generate components using text descriptions or upload images to transform them into code-backed elements.

That’s it! You’re now ready to turn your static designs into fully functional UI components in seconds. For a more in-depth guide, check out our documentation.

Ready to see it in action? Request a demo here or sign up for a free trial.

Design systems are essential for maintaining consistency and efficiency in modern web development. By setting up design guidelines, resources, and documentation early in a project, you make the design process easier for your team and everyone involved.

In this tutorial, I’ll show you how to create a design system from scratch in UXPin. Fast. But before we start, set up a trial at UXPin to follow this guide.

PS: Did you know that UXPin supports React-based design systems? Bring your React Design System to UXPin and design with code-backed elements that make your design correspond with frontend 1:1. Request access to UXPin Merge.

Getting Started with Design Systems

To begin, open the Design Systems tab in the top bar of your UXPin dashboard. Here, you can create a new design system or view existing ones. Let’s start by clicking the “Create Design System” button.

You can build a design system in two ways:

1. Using an Existing Library: UXPin provides pre-built libraries that you can use as a foundation.
2. Starting from Scratch: For this tutorial, we’ll start with a blank slate by clicking “Create from Scratch.”

Adding Resources to Your Design System

Each design system in UXPin is divided into four main sections: Colors, Typography, Assets, and UI Patterns. Let’s go through each section to see how you can add resources to your project.

1. Colors

You can add colors by typing their HEX code and pressing “Enter,” importing colors from a website URL, or linking directly to a CSS file. For this tutorial, I’ll paste our website address to collect colors directly from the site. UXPin also supports color tokens.

2. Typography

Text styles and formatting can be added directly from the Editor. This section allows you to manage your typography consistently across all designs.

3. Assets

Assets include images and icons, which can be uploaded in various formats, including SVG. Click the “Upload Images” or “Icons” button to add your files.

4. UI Patterns

UI patterns are reusable components and elements that you design and prototype in UXPin. These need to be added to the design system while the Editor is open.

Using the Design System in the Editor

Once you’ve set up your design system, you can start using it to build and expand your prototypes. UXPin automatically creates a corresponding design system library with the same name, allowing you to use its elements directly in your designs. You can add, edit, and update elements from your design system to maintain consistency across your project.

Managing Design System Libraries

UXPin’s design system libraries store all elements and are organized into categories, making them easy to use and manage. Here’s a quick overview of the key functionalities:

• Colors and Text Styles: Colors imported into the system sync automatically with the design system. You can add text styles by selecting an element on the canvas and clicking “Add Text Style.”
• Assets and Symbols: Assets like images and icons are easily accessible, and you can add symbols to your library by selecting them on the canvas and choosing “Add to Library.”

Documenting Your Design System

Documentation is crucial for ensuring that your design system is easy to use and understand. UXPin allows you to add detailed descriptions, code snippets, and links to each category. This is especially useful for developers who can access the documentation when using the Spec mode, saving them time and reducing miscommunication.

Exploring Spec Mode

The Spec mode is a powerful tool for developers, providing detailed information about design elements such as colors, typography, and CSS code.

It also shows the origin of each element, linking it back to the design system. To access Spec mode, return to the Editor and select Preview. Here, you’ll find all the properties and documentation for the elements in your design system.

Finalizing and Sharing Your Design System

Once your design system is complete, you can adjust its settings to make it private or public. You can also create different types of tokens and upload a custom logo for a personalized touch.

Summary

To recap, setting up a design system in UXPin involves:

• Creating and organizing design elements like colors, typography, assets, and UI patterns.
• Documenting each element with descriptions, code, and links.
• Using the Spec mode to inspect elements and ensure consistent implementation across your project.

By following these steps, you’ll be able to maintain a cohesive design across all your projects, making collaboration and development much more efficient.

Don’t foget that… UXPin supports React-based design systems? Bring your React Design System to UXPin and design with code-backed elements that make your design correspond with frontend 1:1. Request access to UXPin Merge.