{"id":30749,"date":"2021-07-01T00:05:15","date_gmt":"2021-07-01T07:05:15","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=30749"},"modified":"2022-07-01T07:01:59","modified_gmt":"2022-07-01T14:01:59","slug":"try-storybook-integration-design-with-code","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/try-storybook-integration-design-with-code\/","title":{"rendered":"Try Storybook Integration: Say Goodbye to Design-Dev Inconsistencies"},"content":{"rendered":"\n
\"\"\/<\/figure>\n\n\n\n

Just a few weeks ago, we wrote about our game-changing Storybook integration<\/a>, which helps designers and developers break the silos and improve the UI consistency by using code components when building prototypes. Based on our Merge technology, the integration lets you harvest the power of code, use it to build advanced prototypes faster and massively reduces the complexity of the handoff process. The bottom line is, both designers and devs get to build products with the same components.<\/p>\n\n\n\n

Now, we\u2019ve decided to go one step further \u2013 today, we\u2019re enabling Storybook integration on trial. Check us on Product Hunt!<\/a> <\/p>\n\n\n\n

<\/div>\n\n\n\n

Why product teams need the real single source of truth <\/h2>\n\n\n\n

The single source of truth<\/a> in product development is this one place that stores all the documentation and elements needed to design and build products. In the ideal world, it\u2019s easily shared, is always up to date and is used by everyone involved in the process. We all know how things end up \u2013 messy, scattered and siloed.<\/p>\n\n\n\n

Design systems<\/a> were supposed to solve the problem of disorganized information across product teams. Now, we know that this solution is a great first step to systematize UI and documentation but won\u2019t completely remove the disconnect between design and development.  <\/p>\n\n\n\n

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

The revolution is the Merge technology, which allows product teams to leverage dev tools such as Git repos or Storybook to improve their DesignOps<\/a> processes and maintain parity between design and code. As a result, designers and developers can all use the same UI elements, documentation, and code from one source.<\/p>\n\n\n\n

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

Imagine taking all the production-ready, code-based, fully interactive components from the dev library and just dragging and dropping them on the canvas to use them in the design editor. Here\u2019s why this is so exciting:<\/p>\n\n\n\n

<\/div>\n\n\n\n

Don\u2019t ever ask again, \u201cWhere\u2019s that component?\u201d <\/h3>\n\n\n\n

Just like with the puzzle pieces scattered around, it takes a lot of time to find and match the right product development collaterals. It\u2019s a real challenge to keep the components and documentation up to date. But with a centralized place to store all the information, you won\u2019t need to search for the right version of the component or its code.<\/p>\n\n\n\n

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

When you bring UI elements from the developers\u2019 library to a design editor, you only need to maintain them in one place, and for designers, the libraries sync automatically. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Use the same technology as devs<\/h3>\n\n\n\n

The gap between what designers have created and what developers have built usually boils down to one thing \u2013 everyone used different technologies to do their work. Design tools are typically powered by vectors or pixels, whereas apps and websites are powered by specific programming languages and frameworks. <\/p>\n\n\n\n

The vector or pixel-based approach is extremely limited and represents just a simple visualization of the end product. For example, when you want to add some advanced interactions to a prototype \u2013 it\u2019s not always possible, because neither vectors nor pixels can work with variables, conditional logic or even simple input fields. However, when developers use code in UI components, those blockers disappear. <\/p>\n\n\n\n

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

If you could prototype with code-powered technology, where design has its reflection in code, you and developers would speak the same unified language. So, instead of creating the UI elements in two different environments, you can remove the product drift by using the exact same one. What\u2019s important, you could enjoy the complex built-in interactivity that works great already on the design stage. <\/p>\n\n\n\n

<\/div>\n\n\n\n

10x designer <\/h3>\n\n\n\n

When designing a product, you need to explain to developers what exactly should happen when a user clicks this or that. You can choose to build either lo-fi <\/a>prototypes to start the development process faster but sacrifice some details which you\u2019ll need to catch up later or build hi-fi prototypes that, with all the interactions, explain the product behavior better. Building advanced prototypes takes a lot of time and usually getting the details right, ends up with a lengthy conversation in comments about interactions and the prototype\u2019s functionalities. <\/p>\n\n\n\n

This is not an efficient workflow from a design operations point of view. But if you decide to use the coded UI components in the design editor, you critically speed up the entire design process<\/a>. <\/p>\n\n\n\n

When working with the elements that are fully interactive and in line with all production standards the design outcome you produce is way over 10x of what it takes to build a prototype in a conventional way.  The time you save can be spent on other important things like user testing.<\/p>\n\n\n\n

<\/div>\n\n\n\n

User testing perk: prototypes behave just like the end product  <\/h3>\n\n\n\n

How can you test a prototype when all the UI parts aren\u2019t fully interactive? User testing<\/a> isn\u2019t reliable enough when a user can\u2019t click through a project on their own without a lot of handholding. Describing what will happen after clicking an accordion or hovering over the menu won\u2019t give the same feedback quality as showing it. <\/p>\n\n\n\n

When all the drifts are gone, and the code-powered prototype works exactly like the end product, you can support your research team with a fully immersive experience for their usability tests.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Design with code \u2013 try Storybook integration <\/h2>\n\n\n\n

<\/h2>\n\n\n\n

Storybook<\/a> is this one place where developers can build and store the UI components. It\u2019s also a great tool to test the elements and prepare clear documentation. Storybook supports a lot of frameworks, including the most popular ones like React, Angular, and Vue<\/a>. <\/p>\n\n\n\n

<\/div>\n\n\n\n

UXPin and Storybook Integration <\/h3>\n\n\n\n

Storybook is one of two integrations (Git repo<\/a> is the first one) that use Merge technology to sync coded components with our design tool, UXPin. The entire integration with Storybook takes around 1 minute, and lets you design with code components right away! <\/p>\n\n\n\n

\n