Design Tools Move Closer to the Real Component Stack

Design systems have long suffered from a split personality: the design team maintains one version of each component in a visual tool, while developers maintain another in code. Keeping the two in sync is a constant drain on both teams. UXPin's Merge technology has been attacking that problem by letting designers work with actual React components on the canvas instead of static drawings. The latest addition to Merge is npm integration, which lets designers pull component libraries straight from npm packages with no developer involvement in the import step.

Previously, Merge still required engineers to export components to UXPin as part of a build or deployment pipeline. With npm integration, that step disappears. Any existing npm package — a company's internal design system or a widely used open-source library — becomes directly available inside the design tool.

What It Means to Design With Real Components

Most design tools use a canvas that renders images — historically raster, now typically vector. You end up drawing rectangles that merely approximate what the final interface will look like. UXPin takes a different route: placing a component on the canvas places the actual React component the development team uses in production. Prototypes built this way are fully interactive and high-fidelity, matching what users will eventually interact with rather than an artist's impression of it.

This overlap reduces duplicated effort between design and engineering. It also shrinks the gap between what was designed and what gets shipped, because the two are literally the same components.

Despite the "npm" in the name, no local installs or coding are required to use the integration. The import happens entirely within UXPin. You just need a package already hosted on npm.

Setting Up an npm-Powered Library

To bring a component library in, you add a new library under the "Merge: Component Manager" section and choose "Import React Components with npm integration." From there, you provide:

  • A name for the library (any string you like).
  • The npm package name and version — latest is a valid version string.
  • The path to the styling assets.
  • Any permissions you want to configure.

Once the library is imported, the real work begins: each component must be mapped individually, with its properties configured in the Merge Component Manager. For a large library this setup can take a serious chunk of time, but it unlocks a prototype environment that is as true to the final web product as possible.

If you want to skip the configuration entirely, UXPin offers pre-built libraries for Ant Design and MUI that can be used as-is.

Fitting the Workflow to Your Team

How useful this integration is depends heavily on your current situation.

Your Developers Already Publish an npm Package

This is the cleanest scenario. Teams that already run a component library as an npm package — often documented with Storybook as the source of truth — can now feed that same package into the design tool. The shared reference point stops being documentation alone; the design canvas itself uses the production components, removing an entire step from the handover process.

Designing Before Developers Are in the Picture

In the discovery phase of a project, when no engineering support is available yet, open-source libraries fill the void. Prototypes can be built with, say, MUI components and adapted to the project's needs. Later, when developers start building, those placeholder components can be swapped for internally designed and coded ones.

A Mature Team With Established Tooling

Seasoned teams are often the hardest to move off familiar tools. Even so, the payoff of a single, integrated path for sharing components between design and development is a compelling reason to absorb the switching cost — the consistency across the whole process tends to justify the upfront investment.

Where This Is Heading

The npm integration makes Merge's core idea — collapsing the distance between the design surface and the codebase — more accessible to teams that did not have the infrastructure for the older export pipeline. UXPin continues to push in that direction release after release. The path away from vector-based mockups toward working with the real component stack has been a long one, but each step narrows the collaboration gap a little further.