Can Designers and Engineers Use a Single Source of Truth? Part 2.
Now that you understand the constant tug-of-war between designers and developers (read part one of this article here), let’s talk about how to fix this.
Design Systems and a Single Source of Truth (Part 2 of 2)
The past 10 years brought a lot of maturity to the world of web technologies. CSS became extremely powerful and grew in tools that empowered predictable and sustainable workflows (from preprocessors to modules and style linters). JavaScript became the standard of development for a variety of platforms. It added features increasing readability (maps, arrow functions…) and modularity of code (ES6 Modules). It even gained amazing tooling that brought the ecosystem to the next level (NPM, Webpack, React.js).
Both, the progress in CSS and JavaScript, led to a fast growing popularity of a modular architecture of web applications. As a consequence, it also led to a drastic popularity of design systems. The need for design systems originated from the chaos, expensive maintenance and inconsistent experiences of the early web. The fast growth of the popularity of design systems became possible thanks to the progress of web technologies.
Design systems offered many promises:
- The unification of the sources of truth
- Predictability of the product development workflow
- Increase in the quality of user experience
- Decrease in the maintenance cost
Like a workflow revolution started by the Toyota Production System, design systems offered alleviation of the pains of modern product development thanks to a systematization of processes.
It’s still too early to judge the overall effect of the design system boom. However, it’s becoming more and more obvious that the current generation of design systems is great at systematizing frontend engineering and only semi-successful at fixing the disconnect between design and engineering.
Take, for example, Design tokens, which are a fundamental part of many great design systems. They can be used to generate complex sets of style sheets and color palettes for design tools, but interactive components essential to any design system will remain disconnected from design tools.
Few attempts to bridge this gap didn’t gain either mass popularity or significant traction. The best among them, HTML Sketchapp, offers an import of HTML elements to Sketch. Unfortunately, all the states and interactions are lost on the way. Sketch, ultimately a vector illustration tool, doesn’t offer component-level states or interactions.
Don’t blame design systems for that shortcoming. Blame design tools. As long as design tools enforce the vector format on user interface designers, implementation of a single source of truth will remain impossible.
The issue of a single source of truth sounds theoretical, but think about the practical implications.
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.
Revisit the story of two conflicted date pickers from the first part of this article. If the designer had access to an interactive component synchronized with the production database, she could make an informed design decision about the experience of selecting data and reuse an existing component. The entire conflict would dissolve, resulting in a faster design process, faster development process and a less frustrating experience for the entire team.
Relying on manual redrawing of production-coded components in a vector illustration tool is not only expensive but also prone to critical errors.
In the perfect implementation of a design system, designers and engineers use a single source of truth to cover all the facets of the workflow. Once designers ditch their old vector illustration tools (inevitably losing all the problems related to this old paradigm), this level of an integration and maturity of the process will become possible.
Unified Design — Engineering Collaboration with UXPin Merge
At UXPin, we’ve spent the past 8 years building a collaborative, code–based design editor. With accurate rendering, stateful components, component level advanced interactions (conditional interactions, variables, API integration…), we’ve managed to avoid many of the shortcomings of vector illustration tools like Sketch, Figma or XD. Instead of relying on hundreds of static artboards, UXPin allows designers to create fully interactive and reusable stateful components. Designing forms with full validation becomes easy even for designers who do not code.
Whenever a designer creates anything in UXPin, our rendering engine builds HTML CSS and JavaScript (for all advanced interactions). So designers and engineers can rest assured that there’s going to be a 100% match between designs created in UXPin and the final production implementation. Misunderstandings regarding animations or font rendering mentioned in the first article don’t exist in the UXPin’s universe.
We did not solve all the problems at once. Even our code–based editor, which by all counts seems to be the strongest on the broad market of design tools, fell into a problem of the unification of the sources of truth. Our tool helped designers avoid many misunderstandings, but we didn’t have a way to build a lasting connection with coded components existing in a design system. We didn’t have it… until now.
Nearly 2 years ago, we’ve started to work on building a lasting connection between design and engineering. After exploring multiple ideas, we’ve decided to pursue the following workflow:
- UXPin connects to a Git repository (command line tool is being installed as a project level dependency)
- UXPin learns about the code of components stored in the repository and serializes its content
- UXPin runs the build process and delivers production code to the UXPin design editor, where all the components are identical with the production environment, fully interactive and available to designers (even if they don’t know how to code)
- UXPin allows for connecting to a Continuous Integration Server to enable automatic synchronization between a Git repository and our design editor (every change in the production code is automatically reflected in the components in UXPin’s design editor)
- UXPin shows accurate specifications for all design projects that will show informative code snippets to tell developers how to implement a given design
This approach was extremely ambitious and much broader in its scope than any competitive solution. From the start we wanted to avoid:
- Creating a gimmick feature able to gain some attention on the market, but failing to fix the key problems of the design–engineering workflow
- Forcing designers to learn to code (which characterizes the approach taken by Framer)
- Forcing teams implementing our workflow solution to create code just for UXPin (instead we believed in a plug and play approach, where unmodified production code can be consumed by UXPin).
It took us over 18 months, but I’m happy to say that UXPin Merge has just delivered a solution that truly unifies design and engineering into one continuous workflow.
Merge seamlessly connects to any GIT repository, imports React.js (support of more libraries and frameworks in the future!) components to UXPin’s design editor and keeps all the versions in sync thanks to CI integration. Whatever exists in code, exists in UXPin, giving designers access to real coded components without forcing them to learn coding.
With UXPin Merge, designers and engineers use a single source of truth and can finally work together without unnecessary misunderstandings and frustrations. Guess what? The perfect implementation of a design system is possible.
UXPin Merge is currently in a closed beta. Sign-up for early access below. Our customers and most passionate believers in a unified workflow (if that’s you, let us know your thoughts on Twitter!) will be offered access first. See you on the other side.
