The friction of collaboration between designers and developers is fueling an evolving discussion as old as the industry itself. We’ve come a long way to where we are today. Our tools have changed. Our processes and methods have changed. But the basic problem often remains the same.
A recurring problem I often tend to see, regardless of the type and size of the team, is maintaining a reliable source of truth. Even hiring the best people and using proven, industry-standard solutions often leaves us feeling sick that something must be done better. The infamous “final version” is often scattered among technical documents, design documents, spreadsheets, and other places. Keeping them in sync is often a tedious and arduous task.
Note: _ This article was written in collaboration with the UXPin team. The examples presented in this article were created in the UXPin application. Some of these features are only available in paid plans. A complete overview of UXPin pricing can be found here.
Design tool issues
When it comes to maintaining the source of truth, the inefficiency of design tools is often pointed out as one of the most deadly pain points. Modern design tools are constantly evolving and evolving rapidly with great effort. But when it comes to building Bridges between design and development, it’s not hard to feel that many of these efforts are based on flawed assumptions.
Most modern design tools are based on models different from the techniques later used to implement design. They are built as graphical editors and behave that way. The way layouts are built and handled in design tools is ultimately different from what CSS, JavaScript, and other programming languages can offer. Building user interfaces with vector (or even raster) graphics requires constant guesswork on how and whether you should turn what you do into code later.
Designers often sigh that their creations don’t work out as expected. Even the most valiant efforts at pixel-perfect design won’t solve all problems. In a design tool, it is almost impossible to imagine and cover all possible scenarios. Support for different states, changing text, various viewport sizes, screen resolutions, etc., just provides too many variable variables to cover them all.
In addition, there are some technical constraints and limitations. As a designer with no development experience, it is very difficult to consider all the technical factors. Remember all possible input states. Understand the limitations of browser support. Predict the performance impact of your work. Designing for accessibility is, at least in a sense, broader than color contrast and font size. Aware of these challenges, we accept a degree of speculation that this is a necessary evil.
However, _ developers _ often have to rely on guesswork. The user interface simulated by a graphical editor rarely answers all their questions. Is it the same component that we already have? Should I treat it as a different state, or as a separate entity? How should the design behave in X, Y, or Z? Can we make it a little bit different because it would be quicker and cheaper? Ironically, it’s not always helpful to ask the person who created the design in the first place. They’re no exception. They don’t know.
And, more often than not, this is not the end of the spectrum of growing frustration. Because, there are all the other people. Managers, stakeholders, team leaders, salespeople. Their attention and mental endurance are pulled very thin between where all the tools and parts of the product are, and they work harder than anyone else to master it.
Browsing through the prototype, understanding why certain features and states are missing from the design, distinguishing which are missing, which are ongoing, and which have been consciously excluded from the scope can feel almost impossible. Iterating quickly over what’s already been done, visualizing your feedback, and coming up with your own ideas can also feel almost impossible. Ironically, increasingly complex tools and processes are designed to allow designers and developers to work together better; They set the bar higher, and it’s harder for others to actively participate in the process.
The solution
Countless leaders in our industry are grappling with these issues, resulting in new models, tools, and concepts. In fact, many things have changed for the better. Let’s take a quick look at some of the most common ways to tackle these challenges.
Designer code
“Should designers code?” It’s an old question, discussed countless times in articles, conference speeches and all other media, with new voices popping up every now and then. There is a common assumption that if designers “know how to code” (and let’s not even start trying to define “know how to code”), it will be easier for them to make designs that take technical constraints into account and are easier to implement.
Some would go even further and say they should play an active role in implementation. At this stage, it’s easy to conclude that it doesn’t make sense to simply “design in code” without using design tools at all.
Tempting as the idea sounds, it has rarely been proven in reality. All the best coding designers I know still use design tools. And it’s definitely not for lack of technical ability. It’s important to explain why, to emphasize the difference between an idea, a sketch, and building something.
As long as ** there are many effective use cases ** for “designing in code”, such as using predefined styles and components to quickly build a fully functional interface without bothering you with design tools, the promise of unfettered visual freedom provided by design tools remains undeniably valuable. Many people find it easier to sketch new ideas in a format provided by design tools and more appropriate to the nature of the creative process. And that’s not going to change anytime soon. Design tools will continue to exist and will always exist.
Design system
The great mission of designing systems, and one of the biggest buzzwords in digital design over the past few years, has always been this: limit guesswork and repetition, improve efficiency and maintainability, and unify the sources of truth. Enterprise systems like Fluent or Material Design have done a great job of spreading the word about this concept and creating momentum for businesses large and small to adopt it. In fact, designing systems helps change a lot, for the better. A more structured approach to developing a clear set of design principles, patterns, and components has helped countless companies build better, more maintainable products.
But some challenges are not directly addressed. Designing design systems within popular design tools hinders the efforts of many to achieve a single source of truth. Instead, a large number of systems have been created that, although unified, still exist in two separate, incompatible sources: a design source and a development source. Maintaining equality between the two systems often proves to be a painful exercise, repeating all the most annoying pain points that designing systems first addresses.
Integration of design and code
Another wave of solutions soon arrived to address the maintainability of design systems. Concepts such as design tokens are beginning to gain traction. Some are designed to synchronize the state of the code with the design, such as open apis that allow certain values to be fetched directly from the design file. Others are designed to synchronize design with code, for example by generating components from code in design tools.
Few of these ideas have gained widespread adoption. This is most likely due to the advantage that the possible benefits are more questionable than the necessary entry cost of the still very imperfect solution. For most professional use cases, automatically translating design into code remains a huge challenge. Solutions that allow you to merge existing code with your design are also severely limited.
For example, there is no solution that allows you to import coded components into the design tool, even if they are visually consistent with the source file, and cannot exactly replicate the behavior of those components. Not until now.
Combine design and code with UXPin
UXPin, as a mature, full-featured design application, is not a new player in the design tool arena. But its recent advances, such as merging technologies, could change the way we think about design and development tools.
UXPin with Merge technology allows us to bring real, living components into the design while preserving their visuals and functionality — all without writing a line of code. These components, even if embedded in the design document, will behave exactly like their real counterparts. Because they are their real counterparts. This allows us not only to achieve seamless equivalence between code and design, but also to keep the two in constant sync.
UXPin supports a React component design library stored in a Git repository, as well as powerful integration with Storybook, allowing the use of components from almost any popular front-end framework. If you want to try it out for yourself, you can request access to it on the UXPin website.
- Apply for access to UXPin and Merge technology →
Incorporating real-time components and design in UXPin takes just a few surprising steps. Once you find the appropriate component, you can click to place it on the design canvas. It behaves like any other object in your design. Most specifically, although it is an integral part of the design, you can now use and customize it just as you would in code.
UXPin gives you access to a component’s properties, lets you change its values and variables, and populates it with your own data. Once you start using the prototype, the component will behave exactly as expected, maintaining all behavior and interaction.
Using a component “as is” also means that it should behave according to the context, such as the width of the viewport. In other words, the component is fully responsive and adaptive.
Note: If you want to learn more about building truly responsive design with UXPin, I strongly encourage you to check out this article.
Context can also mean thematization. Whoever is trying to build (and maintain!) in a design tool Designing a system for themes, or at least creating one that allows you to switch easily between light and dark themes, knows what a tricky task this can be, and the results are often imperfect. None of the design tools optimizes the theme well out of the box, and the existing plug-ins designed to solve this problem are far from complete.
Since UXPin with Merge technology uses real, living components, you can theme them as real, living components as well. Not only can you create as many themes as you need, but switching between them is as quick as selecting the right theme from a drop-down menu. You can read more about UXPin theme switching here).
advantage
UXPin’s Merge technology enables an unprecedented level of consistency between design and code. Staying true to the source code during the design process gives all aspects of the process an unassailable advantage. Designers can design safely, knowing that what they’re doing won’t be misunderstood or misdeveloped. Developers don’t have to translate designs into code, nor do they have to fool around with ambiguous edge cases and undiscovered cases. Most importantly, everyone can get involved and quickly prototype their ideas using real-time components without any knowledge of the underlying code. A more democratic, participatory process is possible.
Incorporating your design with your code not only improves the way designers work with the rest of the team, but also their internal processes and practices. UXPin with Merge technology can be a game changer for those focused on large-scale optimization design work, sometimes referred to as DesignOps.
Using the right source of truth makes it somehow easier to maintain consistency between the work produced by different people on the team, helping them stay on the same page, and working together to solve the right problems through a set of joint tools. No more “out-of-touch notation” and a few unsolicited variations.
On the bottom line, what we get is a huge time savings. Designers save themselves time by using confident components and their out-of-the-box capabilities. They don’t need to update the design document as components change, nor do they need to document their work and “wave” their hands to explain their vision to the rest of the team. Developers save time by getting components from designers in an instantly digestible manner that requires no guesswork and additional tinkering.
The person in charge of testing and QA saves time looking for inconsistencies between design and code, and figuring out if the implant worked as expected. Stakeholders and other team members save time through more effective management and easier browsing of these teams. Less friction and a seamless process limits frustration among team members.
disadvantages
There are some entry costs to taking advantage of these benefits, though. In order to use tools like UXPin effectively in your process, you need to have an existing design system or component library. Alternatively, you can base your work on an open source system, which will always provide a degree of limitation.
However, if you are committed to building a design system in the first place, there will be almost no additional cost to using UXPin and Merge techniques in your process. With a well-developed design system in place, adopting UXPin shouldn’t be a difficult thing to do, and the benefits of such a shift could prove huge.
conclusion
The widespread adoption of design systems solves the media problem in the work of developers and designers. At present, we can observe a shift to a more unified process that changes not only the medium but also the way we create it. Using the right tools is critical to this change. UXPin with Merge technology is a design tool that combines design with real-time code components, significantly narrowing the gap between the design and development worlds.
What’s next?
- UXPin Merge. Storybook integration
Learn how Storybook integration can help your product team and try it out - UXPin merge. Git integration
Request access to see how integration with Git repositories works. - A short video description of UXPin Merge
As part of the interactive design system. Webinar with Johnson & Johnson.” - Design in code. UXPin Merge Tutorial – An introductory tutorial on UXPin and Merge technology.
- Responsive design using UXPin Merge
A guide to prototyping fully responsive experiences using UXPin and Merge technologies.