Designer X Developer clash, and how to solve it.
UI vs Front-End
- 4 June, 2019
In my career I’ve been clashing with many Developers and it took me very long time to realize the big picture and learn how to deal with it. Many people helped me and taught me along the way.
The clash between Designers and Developers can have many different origins.
Common complaints about Designers from Developers:
- Arbitrary handover
- Inflexible solutions
- Wrong use of pre-stablished components
Common complaints about Developers from Designers:
- Confronting Design decisions
- Wrong implementation
- Blocking / making the process harder
- Denial of implementation
We Designers start our careers learning UX, Usability, Gestalt principles, Design principles and many other competences that give us the authority and confidence to make good inicial assumptions, or even exact choices for our Designs. Also Many solutions we can propose are so standardized, in the case of UI Design for example, that we know already what to do when. We can have this inicial confidence. It’s possible in many cases.
For all the other cases, we will have in hands or will conduct User testings, Accessibility testings and other tests that will give us the confidence we need to kickstart some Design. And it’s our job to guarantee that the results will be met and the ‘consumer’ of the product (or whatever you are creating) is satisfied and/or is able to use it efficiently, generating revenue or concluding some user task.
In the case of Interface Design / Web Design, the next step on the flow is implementation. So other team/professional will take these designs and will make it work, calculate, process, function. These are commonly the Front End Developers. In web or mobile. The exact gap between both competences is the origin of most of your clashes.
I will tell you a way to close this gap so you and your colleagues won’t kill each other, and the most important: The Organization you work for will benefit immensely from that harmony.
The first round is against yourself.
- Get out of the Designer’s cave
- Try to Develop something at least once in life
- Get down off your pedestal. You learn every single day. There’s no end for learning.
- Open your mouth
- Speak, interact, learn how to tell the story to Developers and Stakeholders.
Do you see the light yet?
Jab, Cross, Bob, Footwork – are boxing (Combat sport) techniques used to illustrate an example discussion. Yes, silly.
Jab: Call out the Developers and develop the solution with them, together. Just take a marker or something similar. Guide them through the solution.
Cross: If you have a strong opinion, it makes sense that you also have a strong reason behind it so Present it. This can possibly be a K.O.
Bob: The solution cannot be implemented because of legacy code or incompatibility with the project scope (something that generates overworking or touching other components).
Footwork: It makes sense? So yes, you need to find another way.
Cross: Ask what could be done instead.
Jab: Developer comes up with an idea that doesn’t look good but works ideally in the scope.
Footwork: Why it doesn’t look good? Because it’s a robot’s skeleton. You must do the skin cover for it. Or maybe it makes all sense and you simply agree. This can possibly be a Draw.
Jab: Make better use of the logical use of grids and elements that makes sense on the Design’s perspective, reshaping the solution.
In case of an ongoing project, Improve the Developer’s idea with a better Design proposal. Better alignment, use of correct components, use of correct typography font, size and color, and many other things can be improved.
Uppercut: Present Data, Results of UX researches, Strong requirement from above.
Or would that be a draw?! ?Anyway, everybody wins.
Keep screenshots and images of the whiteboard and share with everybody involved in the task. If possible, on the spot.
There is no gap anymore.
Now you are not only confident on the solution but also sure that you both will have no stress anymore.
Possible follow ups:
- Wrong implementation
- Denial of implementation
In both cases you must remind your colleague(s) what you’ve developed together.
- This approach can be used at any scale task.
- The more you’re challenged, the more you learn. It will make you exponentially a better Designer.
- Lack of communication is the root of many problems. In all kinds of relationships between two+ individuals.
The only secret here is
To start together with the Developers and not bring all the ideas ready and throw them in their desks. They have inputs as well and it’s important that you listen to them. You will be surprised with how much this can improve the results. Expand your feedback’s range and the results will be bulletproof.
I hope these insights can help you to have a more harmonic relationship with the members of your team, the same way it improved completely mine.