Design Systems: Developer And Designer Collaboration
What is your design system’s source of truth, Sketch or GitHub? Or maybe Bit.dev? And what does the future promise?
In the past few years, I’ve been working as a product builder in the frontend component space. My everyday work includes close communication with both designers and developers, internally and externally, building together.
Getting placed in the middle of this workflow can be challenging. Designers and developers don’t work using the same tools, don’t see the same things, don’t share the same concerns, and don’t even always use the same words.
The words “Design System” has different meanings when talking to a designer and a developer. While designers refer to visual elements and style guides, developers refer to components implemented in code.
So which is your design system? Your Sketch library or your GitHub library? And which is your system’s source of truth, design or code?
A tale of two “design systems”
Last week I was working intensively with both our lead designer and our lead frontend developer. We were building a new feature together.
The feature included a component that fetches and presents this data to the user. This component already exists in our web app, but it needed some design modifications to fit into the new feature.
So, I asked the designer to re-design the component. He did and uploaded it to Zeplin. The developer explained that the simple-looking design changes will require building a whole new component. Moreover, it turns out we already have 2 different versions of this component implemented.
After building the new one, we now have 3. So, I asked that all versions will be consolidated and cataloged in our design system.
Both the designer and the developer looked at me and said “no problem”. The designer quickly updated his Sketch files. The developer updated the code on GitHub and exported the new version of that specific component to our bit.dev collection. Both were perfectly happy.
I don’t think we solved the problem… 😢
Tip: Learn How we Build Our Design System! 🚀
Sometimes, systems just scale the problem
A UI design system is more than the code of a component library. It’s more than the colors, styles, and margins of your elements. It’s an ever-growing and ever-evolving creature that entails your brand and your user’s feelings.
Designers build an amazing visual language for your brand, an A+ grade style-guide with 15 pages, an abstract set of 5 master elements (see Uber’s case study) and over 50 concrete visual elements.
Here’s Slack Engineering’s design system, in a designer’s eyes:
The developers then build a state of the art component library with all the latest React features like Hooks and Context API. They do their best to implement the design components as code components and then try to enforce this library on (often reluctant) app-building teams.
Here’s Shopify’s Polaris design system, from a developer’s view:
Over time inconsistencies begin to pop-up. Designers working on new apps create visuals to fit their needs, and some frontend teams choose to write new components instead of waiting on external library updates.
Quickly, the consolidation between design and code begins to crumble.
Why does this happen?
Nathan Curtis beautifully described a design system:
“ A library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive.”
The core of the problem lies in the words “as code and design tools”.
Designers need to collaborate with developers to build UX/UIs together. Yet, they work on different sources of truth, using different tools. Instead of a mutual dialog, their joint workflow becomes a broken conversation.
So which is the source of truth, design or code?
Through a component-based design system, we aim to achieve both visual and functional consistency.
Functional consistency makes your product more predictable. Users know how an element behaves, and therefore will also feel more safe and secure to interact with it even on a page/screen they visit for the first time.
Visual consistency includes the colors, fonts, sizes, positions and other visual aspects of your UI which help your users cognitively identify and classify UI elements. A certain font color, for example, could be strategically used to help your users understand what they will get if they push a specific button.
Both of these goals are transmitted to users through code. No user ever interacted with Sketch files or your Zeplin assets. Therefore, ideally, both designers and developers should aim to communicate over code.
Yet, it’s easier for developers to look at designs than for designers to look at code. After all, this makes sense. I mean, look at this React Chart component:
Can you seriously look at the code, and not the visual rendered example, and choose the code as your source of truth for everyone on your team? Even as a developer, your eyes are instantly drawn to the visual component image.
That’s why our workflow is often focused on the wrong end of things. Or least, on the side of things that isn’t really what your users experience.
How can designers participate in code?
Lately, I’ve had the pleasure of meeting Eden Vidal, a passionate coder and designer. Eden is building a neat tool called “Relate”, that prides on attempting to consolidate design and code into one source of truth: code.
This approach reminded me of Framer Team, which aims to translate a design into code, probably with the same understanding of the problem.
The problem is that it’s very hard to generate code from design. The generated code is often not something that developers can really adopt in their apps.
In order to unify a design system into one source of truth, we need to give designers visual interactive access to the actual code of the developers.
How can this work?
In the traditional workflow, a designer creates a visual image that the developer translates into code. In modern apps, both design and code describe components including their styling, behavior, etc.
Instead of just “burying” the code of the components in a source-code repository on GitHub, it can be visualized and exposed to designers in a way they can see and monitor changes, provide feedback and take an active part in the code-driven workflow. In fact, the Zeplin team just recently launched “Connected components”- linking design assets to their code source of truth.
On the developer’s end, tools like Bit.dev let developers place and manage all their code components in a shared collection- in the cloud. These are the actual code units the developers build, share and use across their apps.
Every component is also visualized so that everyone can see and edit the code in a visual way. A bit further into the future, an interactive visual interface can provide designers with a way to interact with the code itself- in a visual way. For example, a simple React property panel can enable designers to edit a button’s styling in the web.
Then, these components can be integrated to tools like Sketch or InVision DMS. Designers and developers will have one mutual system, in code.
An interesting new technology in this space is design tokens. A great talk by the Salesforce lightning design-system team outlines this solution that uses tokens in the code to let designers change low-level styling parameters right from their own design tools. It’s probably just a matter of time before tools like Sketch and InVision DMS will adopt this new technology.
Imagine code components connected to the design assets in Sketch, letting designers take an active part in the building process over the actual code components the developers build and use in their apps.
With a Bit.dev-GitHub integration on the other end, a designer can visually edit a component’s styling, save the changes, and the actual code component will be updated with a new version. Every GitHub repository will instantly get a pull-request with the new component version, and every app is updated.
Into the future?
This is just one possible solution to the problem, which personally drives my passion. Regardless, the bridge between designers and developers is a future key to a more productive, inclusive and consistent workflow together.
That’s not such a futuristic scenario. We already see technologies closing this gap from both sides, to include more people in the app-building process.
I really hope we’ll see this happening in the next couple of years.
Thanks for reading, and please feel free to comment below to share, ask or troll anything. Until then, remember that communication between people is the best bridge to cross any gap. Cheers, Jonathan 🍻
This post was written in collaboration by Jonathan Saring (product-builder at bit.dev) and Amir Shalev (former design lead at Microsoft, Autodesk, and today Design lead at bit.dev). Thanks for reading :)
