UI Design System and Component Library: Where Things Break
Is the workflow between designers and developers broken for UI components? And will it be better in 2020?
So here’s a question… “what is your design system really?”
Ask a designer, and they will say it’s some images and guidelines. Apart from components, it will include guidelines for fonts, sizes, margins, positions, and other important aspects of the visual experience you provide to people.
As a developer, and they will say it’s a library on GitHub, written in React, Vue, Angular or just plain JavaScript. And maybe mention Zeplin too.
This is a real problem, as the gap between what you imagine and hope for and what you end up having a couple of years later is growing each day. Why? because some things get lost in translation between visuals and code, and because over time reality forces developers to changes stuff. That’s just life.
So let us depart for a second from the Sketch->Zeplin->GitHub->Apps workflow we know today and try to explore how the future might look. Let’s also visit some tools that might help in consolidating this workflow today.
This post was written based on the experience of over 30 teams building a component design system, at different stages of the process. Please feel free to comment below with any ideas, insights or suggestions you have. It will help other people learn too. Enjoy :)
What is your design system, really?
The only real truth is this:
Your real design system is what your users get. Nothing more or less.
You can have the most amazing bunch of components in Figma or Sketch, and the best guidelines for a stunning design system ever written. If it’s not what your developers use and not what your users get, it’s not your design system.
You can have the best UI component library even written in React, Vue or Angular. If the developers building your apps just copy-paste code or change stuff from your library, that’s not your design system.
This is why a practical design system must accommodate the gap between images and code, and the gap between plans and evolution over time. Using the right thinking and tooling, you can find a practical solution today. Looking into the future, this toolchain and workflow should really be consolidated. We’ll look into tools like Bit, Framer and others which can make it happen.
- Also see: Building a UI component design system
Gaps between design and a UI library
Many companies like Uber Design and AirbnbEng are building a UI component design system (see Uber’s and Airbnb’s visual languages).
To translate these systems into code used in their apps, they implement UI component libraries (see libraries by HP, Atlassian, Pinterest and others). These libraries, in turn, are installed and used in different applications.
Gaps in building the library
But, when a developer has to translate images into code, things might end up a bit differently than expected. Tools like Zeplin can make this easier, but change is often inevitable. For example, relative vs absolute positioning is a common problem. So are fonts and the use of Fonts in your components.
When the design needs to fit into a real-world applicable component to be used in your real-world app, the developer is bound to make some choices. Even while consulting with the designer, differences are bound to form.
Gaps evolving over time
Over time, the library has to be put to use in 2 or 20 or 200 applications by 2 or 20 or 200 developers. Some will need to change stuff in order for the library to be applicable in the projects they are working on. Otherwise, they just won’t use it (Bit can greatly help mitigate this pain, we’ll get there later).
Some of these changes might find their way back into the library, changing the code to make it more applicable in the applications you are building. Then, the gap between design and code widens even further.
Gaps between a UI library and app developers
UI components also function as UX components, combining the power to create both functional and visual consistency for your users.
A component-based design system can grant your applications both visual and functional consistency, helping to make your users feel at home and easily navigating their way to complete the desired interactions with your product.
Sometimes, the developer building the app can’t use the library for various reasons. For example, a component’s styling or margins don’t fit. Or, maybe the library adds too much weight to an app that needs to be light and fast.
When a developer needs to change something in the library they have to make a pull-request, which might or might not get accepted, at an unknown date. This is a serious and very common blocker for the adoption of such libraries.
App developers won’t always use the library
Then what really happens is that some developers won’t use the library, and build their own components instead. Or, they might copy-paste the code from the library into their own project, and make some changes under the table.
You can’t really blame the developers, as they need to get the job done. You can’t enforce your design system, as it should really be made practical to adopt. You need to accept that changes will be needed, and to prefer regulation, transparency, and collaboration over enforcement. Always.
Using Bit this becomes much easier, and any developer can suggest updates to components right from any project they’re building, so you can collaborate on changes and regulate to keep track of the changes instead of ignoring them.
Consolidating design and development?
As with many other things in life, you need to bring people together to achieve greater things. In this case, you need to create common ground for 3 different audiences to build and iterate over your components together:
- UI Designers
- UI component library developers
- App developers (using the library)
Only if you create a consolidated space for all 3 to collaborate, you can (hope to) make sure that the end experience of your users is consistent with the design guidelines and visual assets set by the people who plan them.
And here we come into the real problem:
Designers don’t use GitHub and don’t read code in React/Vue/Angular. Library developers have to translate and you can never expect everything. App developers just really want to find and use components to build apps.
Neither Sketch nor Zeplin or GitHub can accommodate all these needs, and until it solves, we will have to experience a somewhat broken workflow. But, are there tools today that can already make this happen? Let’s check.
UI Component tools of tomorrow
Let’s quickly review a couple of tools which, looking forward, can help bridge the gap from the developer’s end and from the designer’s end.
Bit and bit.dev (for developers)
Bit is an open-source tool for turning components into shared building blocks. Using Bit and the bit.dev component platform, developers instantly isolate and share components from their libraries and projects into a “playlist-like” collection that makes them visually available to discover and use anywhere.
From this collection, components can be installed (npm/yarn) and even developed (bit import) across different projects, so developers and dev teams can easily share and collaborate on UI components to build apps.
Through bit.dev the actual code-components (React, Vue, Angular) are rendered and visualized so that both developers and designers can learn exactly how their components look, behave and feel-like to users. They can even play with the components at any moment, in an editable playground.
When developers make a change and update a version for a specific component, the designers can instantly see the new version and monitor the changes to make sure the actual components fit their design system.
This creates a balance when developers have the flexibility to make changes to a component when they have to, and suggest updates from their own projects, and designers can collaborate to review changes over time.
Framer and FramerX (for Designers)
FramerX is a quick prototyping tool that lets designers create realistic components in React and design advanced interactions for their apps.
The built-in use of React components allows designers to get closer to high-fidelity prototyping. In most design tools, designs are mostly visual — a picture of a button, slider or toggle. Framer Team’s editor means that designs can now be made more interactive. Interactions such as scrolling, clicking, moving and handling input are now possible, thanks to React components.
Under the hood, Framer X is built on top of framer.js, an open-source library that does the work of converting React code to interactive designs. The React components that can produce these design interactions can be coded from scratch (by you) or downloaded from the in-app design store.
Also check out: Hadron
FramerX and bit.dev together?
By integrating Framer and Bit you can create a workflow where you use FramerX to design React components and share them to bit.dev. Here is an example of a basic React button component designed with Framer and shared to bit.dev, so it can now be easily discovered and used across different apps.
Looking into the near future, combining these two power-tools together can bridge the gap between the design and development of UI components to consolidate the workflow between designers and developers. Cool, right?
Conclusion
Looking into the future, we can hope that the workflow of designing and building components will be consolidated for designers and developers.
The less room we leave for mistakes in our toolchain, the better experience we build for the people interacting with our products and applications. This collaboration should be unified from the get-go and kept alive over time as both our design system and our components grow and evolve.
Hopefully, we’ll see this happen sooner than later. Until then, please feel free to share your own takes on how to handle this complicated workflow and how you think it can be made better. Thanks for reading and hope you enjoyed :)
