Design Handoff: What it Looks Like with UXPin Merge
The following article is written by UXPin’s developer, Robert Kirkman, who shares how UXPin Merge makes the design handoff easier from both (a developer and designer) perspectives.
Once the prototypes are ready for production, the designer hands them off to developers. Such a process can be troublesome – the right tool stack being a part of that. There are quite a few design tools that help with design handoff, but what’s the difference between them when handing off prototypes to the developer?
One of the major differences between popular design tools is their approach to the final product of the designer’s work – the prototype of the product. Some of them render prototypes to vector graphics, while others to code. Let’s explore it.
With UXPin Merge, designers can build fully-functioning interactive prototypes with the exact components used in the final product. It syncs fully coded components from a GitHub repository or Storybook to UXPin’s editor. See how UXPin Merge can make you release coherent products. Request access to Merge.
The Handoff Limitations of Vector-Based Design Tools
Here is a prototype that is going to be handed off from the designers to the developers. Let’s say that it is created in a vector-based design tool. It means that all the components are vector based while the interactions only mimic code.
Recreating UI components
Let’s focus on components first. Some of them might be new, which means that the developer has to build them from scratch. Others are existing components that this engineer may need to modify.
Developing interactions
When getting a prototype built in a vector-based design tool, the interactions might not even exist in the code, so the developer has to create them, or else, call for more designer-developer meetings to understand exactly what is needed and manage expectations.
Preparing design system
This is a system where designers and developers are creating the source of truth for a design system. They are the ones creating the documentation of the reusable master components, and how interactions should work.
Is such design handoff efficient?
This approach works but it might be a bit frustrating, time consuming and tedious. Not everyone will notice that it’s broken or feel an urge to fix it. They don’t have to do that. But, is this the best way to run things?
If you look at it from the perspective of what more can we do to make this better for both designers and developers, I think there is a lot we can discuss. This approach has issues based on where the source of truth is coming from, which is the vector-based documentation and what is handed off to the developers.
What Does Design Handoff Look Like with UXPin Merge?
We’ve taken this perspective of what we can do better during the developer handoff when we were creating UXPin Merge.
No longer are you designing with vector-based components and mimicked code interactions. You’re actually designing with live React components. You can copy and paste the components’ code into your application.
Imagine if the documentation was created by the designer and developer in tandem but the single source of truth for component design and interaction was the actual component code itself. Meaning when the designer is creating prototypes, they are using components that have already been coded, in a live production-like environment with real components.
The components have all the design tokens, interactions and editable properties already defined. Finally, when the prototype is made you can handoff the component code iself.
How Does Handoff with Merge Help Developers?
Imagine how much time is saved when you don’t have to imagine or have meetings with the designer to understand what components they’ve used or what interactions they’ve designed.
The developer handoff is simple, they give you a prototype, you copy and paste the JSX code, which includes the components, component properties and their coded interactions that already exist in the source code.
This is possible because the source of truth is the code itself, the source code.
The only component properties the designer can edit and how they can edit are specified in the source code by the developer, so no unexpected designs are handed your way.
If the designer wants a new interaction added, new properties or changes in the styling of something, they can explain to the developer, then change the source code. There’s no more guessing or wasted time in unnecessary meetings.
How Does It Help Designers?
This sounds great for developers but designers often feel that when they are given components with limited properties to design with, it’s limiting their creativity, right? I don’t believe so, so let me explain.
Imagine playing and designing cool spaceships or castles with your lego back in the day with your friends, or maybe now and alone. No judgement here – lego is cool at any age. You’re all given the same pre-built building blocks, how they connect to each other and how you can use them are already defined and yet each person can create an amazing spaceship, completely different from all the others.
Instead of focusing your creativity on making building blocks and then figuring out how to use them, you’re purely focusing on the latter. Imagine having to create the lego blocks first and figure out how they are meant to work, then build a spaceship.
That’s insane and yet that’s the current accepted state of designing prototypes.
Yeah, I understand designers have to create the components initially with both vector components but developers have a harder time with them. Whereas if you’re using code-based components, both parties only have to create it once, so we’re all happy.
It leaves designers more time to spend on other super cool tasks instead of continuously making adjustment meetings with developers.
Prototype Developer Handoff Using Merge
For the prototype shown earlier, let’s start with copying the JSX code from the MergeHeader component, created by the designers into our React application, exactly how the developer handoff will work.
As the source of truth is from the source code itself then you can just copy and paste, with a few adjustments such as adding data to objects and the component imports, then you’re ready to view your app in the browser.
Now, all that’s left to do is the same with the rest of the prototype… and VOILÀ! You have a fully working production React app, within minutes, exactly the same as the designer made.
So, in the end, which design process do you think is better?
Improve Design Handoff With UXPin Merge
UXPin Merge can help you improve a lot more than just the handoff process. Visit our Merge page to discover more benefits of designing in code and request access to start the integration process. Go to our documentation to read more about integrating Merge with your organization’s design system components.
