Is it controversial to say deep integration of design systems, removing the need to maintain both a code and design version of each component, is the current Holy Grail of Web Design?
Traditionally the “Holy Grail” was the full-height three-column layout, but that is now consigned to history. Similarly, vertical centering can no longer be the punchline of a CSS joke. Even Container Queries, often considered an impossible task, are making their way into browsers.
This historical precedence gives me optimism. People throughout the web industry worked together, both in collaboration and competitively, to gradually, step-by-step, improve the web. To fundamentally improve the way we all work. The same is happening now with design systems. For all the advantages there are, we still have many things to solve. UXPin is focused on the goal of removing the gap between design and development tools.
Introducing UXPin’s npm Integration
We’ve written about our friends at UXPin before, and it’s been really great watching them iterate their product towards bringing designers and engineers closer. Recently UXPin have extended their powerful Merge functionality by adding npm integration, allowing designers to sync React component libraries without requiring any developer input.
Previously Merge required engineers to export the components to UXPin in the build/deployment pipeline… That’s not required when importing components from npm packages.
To understand how this works, we need to step back and look at how UXPin differs from other design tools. Usually, the canvas on which you design is an image. In the past, these were raster and, nowadays, vector, a step in the right direction, but you are still drawing images that are supposed to represent the direction of your product’s look and feel.
When you use your components on the canvas in UXPin, you aren’t drawing rectangles styled to look about right — you are placing the real components the developers will use in the end product. This means you can easily prototype fully interactive high-fidelity designs that would previously require coded prototypes, without any coding using the exact same components as the end product. This reduces the gap between designers and developers both in terms of overlapping effort as well as the gap between what’s designed and what the users interact with.
But npm Is For Developers, Isn’t It?
Let’s be clear: you do not need to install anything on your computer to import component libraries into UXPin using npm integration. You don’t need to write any code. All you need is an existing package hosted on npm. This may be a package that is open source and widely used, such as Ant UI or Material, or it may be specific to your company and already in use by developers.
Node Package Manager (npm) is a tool for importing specified versions of code. Developers use this for managing versions of “packages” of code that someone else has written. For example, they would tell it which version of React to download, and if a new version is released, they can update it when they are ready. This is basically an automated way to avoid copying and pasting zip files everywhere.
Okay… How Do I Use It?
Within UXPin, you define the UI component library by adding a new library to the “Merge: Component Manager” section. You will be given options and need to select “Import React Components with npm integration.” Here you will be asked to write the name of the library, and this can be anything. You will also need the package name and version (which can be
latest), the path to the styling assets, and any permissions you wish to set up. For a more thorough explanation, see the documentation.
Once that’s complete, you will have imported your component library from npm into UXPin!
This is not the end of the process, however. With the components imported, you need to configure the Merge Component Manager for the library you’ve imported. You need to specify each component individually and set up each of the properties that relate to it.
Although the setup, especially of a large library, can be quite a lot of effort, it really is worth putting in the time upfront to reap the rewards of an integrated design system. At this point, you will be able to build prototypes that are as realistic and true to the medium of the web as any prototype can be. If you want to avoid the integration process and use open-source solutions, you can also use built-in libraries of Ant design and MUI.
This Sounds Great, But Is It Suitable For My Team?
Your Developers Already Have An npm Package For Your Design System
This is the perfect situation for an integrated design system. A common situation is to create components both in code and a design tool and aim to sync them. Documentation tools such as Storybook are often used to provide shared knowledge and a source of truth between designers and developers. With npm integration, you are able to further reduce the handover process by literally using the same technologies without the step in the middle.
Designing Without Access To Developers
If you’re in the discovery phase for a new project and don’t yet have access to any developers just yet, UXPin gives you an advantage. You can prototype using open-source component libraries (for example MUI) and adjust them to your needs. When developers join the team those components can be swapped out for the ones you design from scratch and developers then code.
Fully-Fledged Team With Existing Practices
In a seasoned team, changing your tools can be the last thing anyone wants to do and can be hard to agree on. But even for these teams, the reward of having a consistent, integrated solution for sharing components between designers and developers is likely worth the investment.
The team at UXPin has taken an impressive step towards making their Merge technology more accessible with npm integration. With each new Merge release, we can see their vision of how teams can work more closely together with their design systems integrated throughout their process. We can see the future, and gradually we are getting there just as we did with their walking away from the vector-based design standard into working closer with devs. It was a long journey, but worth it in the end.