Reducing the Friction Between Designers and Developers
Practical tips for improving designer–developer collaboration
You’ll often hear developers say something like:
“Ugh, the designer changed the colors again.”
But, developers change things all the time too. We refactor code, rename classes, pull in third-party libraries. Yet when a designer tweaks a few colors, it somehow feels more disruptive.
Why is that?
👇 Watch the video version of this article below.
The Designer-Developer Relationship Is More Unidirectional
Part of it comes down to how we typically work together. In many teams, the designer works on a mockup or flow, and then hands it off to the developer. From that point on, the expectation is that the developer will implement what’s been designed.
Sure, designers don’t just throw a design at developers once they’re finished. Designers will involve developers during their process, and using the developer’s input, the designer comes up with a better screen.
But even with great cooperation, the workflow remains more unidirectional since the design oftentimes precedes implementation.
The Hand-Off Problem
Then, when the designer updates something post-handoff, it feels like backtracking and can be a frustrating experience for developers.
To a developer who just finished implementing the screen, this can feel frustrating: “I just built this. Now I have to go back and change it?”
But a design is rarely done when implementation starts. As the product evolves, designers may notice issues; Maybe a color lacks sufficient contrast, or a change improves the overall visual feel. So they iterate.
Or even if an implementation is 100% following a design, people learn it doesn’t work as well as they intended. Once you have an actual working version on a device, both a developer and designer learn what works and doesn’t work so well. Which means more iterations until your team considers the feature as finished.
Change Is Normal, So Plan for It
The issue isn’t that designers make changes. It’s that our processes aren’t designed to make those changes easy. This causes frustration. Sometimes it even breeds resentment between designers and developers.
If you’re developing a mobile app and starting implementation before design is fully finalized (which is a good thing, by the way, since it can speed things up), you need a system that allows for safe and quick updates.
One of the best ways to do this is by using a design system.
Make Changes Easy, Not Painful
A design system gives your team a shared language and structure: colors, spacings, font styles, and components are all documented and reusable.
This allows everyone to centralize and scale UI, and agree on a shared understanding.
With a design system in place, a developer and designer would be tweaking the UI on a higher abstraction, together.
For example, conversations are less about “This header needs to be 20 points”or “This margin is incorrect”, or “This blue is now lighter”. Instead, they are more functional. Such as “Let’s use a medium size for padding instead of small.”, or “How about we make this overlay a card instead of a tooltip?”.
It’s a whole lot smoother than fiddling with low-level details, like obsessing over whether that border is #DDDDDD or #DDDDDE and whether the designer will approve on your implementation of that tricky gradient.
Even better: A design system opens up new workflows where designers can propose changes directly, so you as a developer are interrupted much less often. Imagine a workflow where a designer can open a pull request to update colors directly in code. The developer just has to review and merge it. No back-and-forth needed. This is a powerway way of working!
To learn about various designer-developer workflows, check out the chapter From Semantic UI to Design System of the Mobile System Design book .
Build Together, Not Against Each Other
It’s important to understand that designers are allowed to change UI. Just like how you’re allowed to rename a property or delete a struct.
So when you catch yourself saying “Argh, the designer keeps changing the UI!”. Think constructively about what would be a better workflow. Taking this idea further: Consider a design system to allow for more designer-developer workflows.
A good workflow will make everyone happier and the release process much smoother.
-