There is a conversation that has been percolating for as long as I’ve been in the web design and development industry. It’s centered around the conflict between design tools and development tools. The final product of web design is often a mockup. The old joke was that web developers make websites and web designers make paintings of websites. That disconnect is a source of immense friction. Which is the source of truth?
What if there really could be a single source of truth. What if the design tool works on the same exact code as the production website? The latest chapter in this epic conversation is UXPin.
Let’s set up the facts so you can see this all play out.
UXPin is an in-browser & code-based design tool.
UXPin is a powerful design tool with all the features you’d expect, particularly focused on digital screen-based design and advanced prototyping.
The fact that it is code-based is extra great here. Designing websites with all the visual components actually rooted in code brings the design much closer to the real end-product. What you design won’t only look like a website or app but also work like it. For example, an input field is not a static box with an outline, but it’ll give you the real experience of filling it with text.
Code-based design already provides all the specs for each element – like with this card component; exact colors (in the right formats), as well as the exact pixel dimensions, etc. In some cases – even the exact right code of the UI component for your dev can be pulled.
This is laid out nicely by Ania Kubów in a video about UXPin.
Over a decade ago, Jason Santa Maria thought a lot about what a next-gen design tool would look like. Could we just use the browser directly?
I don’t think the browser is enough. A web designer jumping into the browser before tackling the creative and messaging problems is akin to an architect hammering pieces of wood together and then measuring afterwards. The imaginative process is cut short by the tools at hand; and it’s that imagination—or spark—at the beginning of a design that lays the path for everything that follows.
Jason Santa Maria, “A Real Web Design Application”
Perhaps not the browser directly, but a code-based tool that makes UI work like your website or app could be the best of both worlds:
Webpages are living, dynamic spaces where the smallest interaction from a visitor can change the scope of an entire site. […] Because we’re not dealing with a static medium, we need to be able to design for interactions and the shifting landscapes of a webpage […] an application needs to see elements rather than blocks of color or text. Photoshop, Illustrator, and Fireworks have some low-level functionality in this regard, but the need for more dynamic and non-destructive handling is clear.
You can work on your own React components in UXPin.
This is where the single source of truth magic can happen. It’s one thing if a design tool can output a React (or any other framework) component. That’s a neat trick. But it’s likely to be a one-way trip. Components in real-world projects are full of other things that aren’t entirely the domain of design. Perhaps a component uses a hook to return the current user’s permissions and disable a button if they don’t have access. The disabled button has an element of design to it, but most of that code does not.
It’s impractical to have a design tool that can’t respect other code in that component and essentially just leave it alone. Essentially, the design tool is not that useful if it exports components as code but doesn’t allow designers to import those UI components in the first place.
This is where UXPin Merge comes in.
Now, fair is fair, this is going to take a little work to set up. Might just be a couple of hours, or it might take a few weeks for a complete design system. UXPin, for now, only works with React and uses a webpack configuration to integrate it.
Once you’ve gotten in going, the components you use in UXPin are very literally the components you use to build your production website.
It’s pretty impressive really, to see a design tool digest pre-built components and allow them to be used on an entirely new canvas for prototyping.
UXPin helps you with implementing this in your project, including:
- Documentation on Integrating Your Own Components
- Example repo: uxpin-merge-boilerplate
As it should, it’s likely to influence how you build components.
Components tend to have props, and props control things like design and content inside. UXPin gives you a UI for the props, meaning you have total control over the component.
<LineChart
barColor="green"
height="200"
width="500"
showXAxis="false"
showYAxis="true"
data={[ ... ]}
/>
Knowing that, you might give yourself a prop interface for your components that provides you with lots of design control. For example, integrating theme switching.
This is all even faster with Storybook.
Another awfully popular tool in JavaScript-components-land to test and build your components is Storybook. It’s not a design tool like UXPin—it’s more like a zoo for your components. You might already have it set up, or you might find value in using Storybook as well.
The great news? UXPin Merge works together awesomely with Storybook. It makes integration super quick and easy. Plus then it supports any framework, like Angular, Svelte, Vue, etc—in addition to React.
Look how fast:
UXPin CEO Marcin Treder had a strong vision:
What if designers could use the very same components used by engineers and they’re all stored in a shared design system (with accurate documentation and tests)? Many of the frustrating and expensive misunderstandings between designers and engineers would stop happening.
And a plan:
- Connect to Git repo or Storybook library.
- Import components from there to UXPin design tool.
- All the changes in the repo will be synced automatically in UXPin Watch for any changes to the repo and sync those changes in the visual editor.
- Let designers design and deliver accurate specs and fully functional design to developers.
And that’s what they’ve pulled off here.
