{"id":350466,"date":"2021-09-13T12:21:00","date_gmt":"2021-09-13T19:21:00","guid":{"rendered":"https:\/\/css-tricks.com\/?p=350466"},"modified":"2021-09-14T12:21:51","modified_gmt":"2021-09-14T19:21:51","slug":"developers-designers-uxpin","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/developers-designers-uxpin\/","title":{"rendered":"Developers and Designers Work on a Single Source of Truth With UXPin"},"content":{"rendered":"\n

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<\/em> of websites. That disconnect is a source of immense friction. Which is the source of truth?<\/p>\n\n\n\n

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<\/a>.<\/p>\n\n\n\n\n\n\n\n

Let’s set up the facts so you can see this all play out. <\/p>\n\n\n\n

UXPin is an in-browser & code-based design tool. <\/h3>\n\n\n\n

UXPin is a powerful design tool with all the features you’d expect, particularly focused on digital screen-based design and advanced prototyping.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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\u2019t only look<\/em> like a website or app but also work like it<\/em>. For example, an input field is not a static box with an outline, but it\u2019ll give you the real experience of filling it with text.<\/p>\n\n\n\n

Code-based design already provides all the specs for each element \u2013 like with this card component; exact colors (in the right formats), as well as the exact pixel dimensions, etc. In some cases \u2013 even the exact right code of the UI component for your dev can be pulled.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This is laid out nicely by Ania Kub\u00f3w in a video about UXPin<\/a>.<\/p>\n\n\n\n

\n\n\n\n

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?<\/p>\n\n\n\n

I don\u2019t 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\u2019s that imagination\u2014or spark\u2014at the beginning of a design that lays the path for everything that follows.<\/p>Jason Santa Maria<\/em>, “A Real Web Design Application”<\/a><\/cite><\/blockquote>\n\n\n\n

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:<\/p>\n\n\n\n

Webpages are living, dynamic spaces where the smallest interaction from a visitor can change the scope of an entire site. […] Because we\u2019re 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. <\/strong>Photoshop, Illustrator, and Fireworks have some low-level functionality in this regard, but the need for more dynamic and non-destructive handling is clear.<\/p>

<\/p><\/blockquote>\n\n\n\n

You can work on your own<\/em> React components in UXPin.<\/h3>\n\n\n\n

This is where the single source of truth<\/strong> 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.<\/p>\n\n\n\n

It\u2019s impractical to have a design tool that can\u2019t 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.<\/p>\n\n\n\n

This is where UXPin Merge<\/a> comes in.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

UXPin helps you with implementing this in your project, including:<\/p>\n\n\n\n