How to Improve Communication Between Designers and Front-End Developers
Applying leadership theory into practice.
This article will explore practical strategies for fostering a collaborative and productive relationship between design and development teams.
My story — Where the journey began
Early in my career, having a strong education background in leadership and significant management experience, I believed I could lead any team to victory. After all, for every challenge, there existed a good solution waiting to be discovered.
However, it changed when I started my start-up in the IT field. I had to lead not just any team but specifically a team of developers. In most cases, I was the primary UX/UI designer and also played the role of project leader. There, I faced a reality: one where effective communication was the secret sauce for success.
Oh, how communication matters!
Ineffective communication is a common cause of project failure. According to a study by PricewaterhouseCoopers, more than 50% of all IT projects fail due to poor communication.
I have been involved in various projects with the IT team. While some of them were successful, others failed. During the process, I faced several issues caused by poor communication.
But here's the twist: I couldn't point fingers solely at my development comrades. No, the blame game wasn't my style.
My journey taught me that designers everywhere face similar struggles. This inspired me to write a blog about my transformation and share my insights with others.
The situation — Navigating Communication Challenges with Developers
Why can't they see what I see?
I often wondered why communication with developers sometimes failed. Even when I explained my designs clearly, the developers sometimes did not understand my ideas and vision correctly.
And, oh, the perennial question: Did they thoroughly test their code before nudging those tickets into the review column?
I searched for tips on communicating better with developers, but nothing worked. Frustration would sometimes bubble up, and I'd silently lament, "Why can't I understand these developers?"
But negativity breeds no solutions, so I shifted my perspective. Instead of pointing fingers at the developer team, I embarked on a different path, prioritizing empathy and collaboration.
#1. Establishing Project Priorities: Balancing Ego and Project Success
Our emotions and character define us as human beings. During project engagements, we often struggle with pressure and moments of introspection, and sometimes, we let our emotions control us too much.
The story — The aggressive communication that led to project failure
Three years ago, I engaged in a conversation etched into my memory — a dialogue with a junior developer on a project. I joined that project quite late. On that fateful day, I was a secondary designer tasked with refining UI elements and organizing mock-ups to facilitate comprehension for the development team.
The scene: a review session
The Product Owner (PO) and I huddled over tickets. These items needed precise left-aligned and fixed widths to maintain visual consistency — a wish from the client and a design principle rooted in the Gestalt laws.
The PO shuffled the tickets back to the improvement column, and I nodded in agreement. But the junior developer? A rebel with a keyboard. "Who'll notice?" he scoffed. "Do we measure alignment with a ruler?"
Then came the blur — a background blur, to be exact. But he misread the ticket and the mock-up, conjuring a layer blur instead. The reviewer commented, "You misinterpreted the task," and moved this ticket back to the improvement column.
The developer, sensitive to critique, faced me. "Don't treat us like a machine. We're human," he declared, "and humans make mistakes." At that moment, I really let emotion control me, "Even machines could do better," I snapped.
Regret gnawed at me afterward. I had crossed a line—one that no human should cross. If you found yourself in a similar situation, how would you navigate the storm of emotions and communication breakdowns?
The Resolution: A Humbling Choice
Taking a deep breath, I turned the mirror inward. Self-reflection became my compass, and I made an important decision at that moment.
The following day, I approached him with sincerity:
"I apologize for my words yesterday. Please accept my heartfelt apology. Our project journey still lay ahead, waiting to be shaped. How about we mend the cracks, fix the bugs, and, in the end, hold a retrospective? A space where we dissect every issue, learn, and emerge stronger."
A Valuable Lesson: Beyond Client Satisfaction
In retrospect, our client celebrated the project's outcome — the external stakeholders deemed it a resounding success. Yet, as a designer and project leader, my perspective diverged.
To me, success transcends mere client contentment; it hinges on equipoise — the delicate balance that nurtures both project fruition and the well-being of my team.
My mistake was allowing ego and anger to steer my actions. Their influence seeped into my words, coloring how I communicated with my team. This was a humbling realization that reshaped my approach and underscored the importance of empathy and collaboration in every endeavor.
I learned a lesson and changed how I communicate with the dev team without violence. However, believe it or not, some developers have a high ego and still complain that designers don't know how to code every time they receive the mock-up.
Therefore, changing the way I talk is not enough. I have to improve the quality of my talk, and to do so, I have to think like a developer.
#2. Think as a developer
I learn how to code
I was never ambitious to become a developer, but I was interested in understanding how code works.
So, I started learning HTML, CSS, and JS and later delved deeper into Three.js, where 3D realms danced with light and shadows. The theories were my compass, but practice — the forge where theory melded with reality — became my faithful guide. I joined a development team and worked on projects with them.
Although my work typically involves management and design, learning and practicing coding has made me appreciate developers' unique and logical mindsets.
More than I expected, it changed how I design and significantly improved my prototypes.
Talk to them
In a previous project, we had to develop a WebGL application with a red-colored button. Upon reviewing the button, I noticed that it was sent back to improve it further.
A junior developer complained to me that all red colors are the same, and he couldn’t understand why we — design team were so sensitive about it. I asked him which color hex code he had used, and he replied with #FF0000. I explained to him that the branding color was #D30000, which he should have used.
I asked the developer how the project started. He told me that the team was given the Figma file and instructed to build the site exactly as it was designed.
Small conversations like this often help me understand the real problem between designers and developers. Knowing all the design and branding rules can be challenging as a junior developer.
Communication without context leads nowhere. I suddenly understood and felt the confusion of the development team when they were on the project.
I start to find the solution as a developer
While designing any website, I frequently ask myself: How would I build this site if I were a developer?
I still remember the first time I started learning to code. I asked Google, “ How do I center a div?”
All the components, variants, frames, and elements in my Figma design are named as developers would do. This means developers will not need to rename them, creating consistency between design and development.
Naming elements in this way also makes it easier for future reviews and for developers who may join the project at a later stage.
In Figma, there is a developer mode that allows me to check if the codes are reliable after designing and testing them myself.
I have been in many kickoff meetings where designers introduce their designs to the development team. The designer simply tells the dev team what they should build and the requirements.
We are pretty familiar with the golden circle in leadership. The same method can also be used in communication.
#3. Give the developers a chance to understand my design
Start with the "Why"
Before diving into the specifics of a design, I always begin by explaining the rationale behind my choices. Take the color palette, for instance. Rather than simply selecting colors that look good, I follow the company's branding guidelines. By sharing the "why" behind these decisions, developers gain insight into the purpose and context of the design.
How to use Figma as a developer
Do you know that not all developers know about Figma?
Not all developers are familiar with design tools like Figma. In the past, I used Adobe XD for design and prototyping — it offered comprehensive features for creating website prototypes.
However, as collaboration became essential, Figma emerged as the preferred platform. Its real-time collaboration features and developer-friendly interface make it an excellent choice.
Recognizing that not all developers are well-versed in Figma, I organize workshops specifically for them. These sessions cover the basics of using Figma as a developer, from navigating the interface to understanding design components. These workshops empower developers to work seamlessly with the design files.
Transparency from Day One
Keeping the design stage transparent is essential. Rather than treating it as a mysterious black box, I involve developers right from the project's inception. Regular discussions and updates ensure that everyone is on the same page. After all, developers possess a logical mindset, and their insights can lead to innovative solutions.
Design isn't just about aesthetics; it's a critical part of problem-solving. Developers often provide valuable feedback based on their technical expertise. By embracing their input, we create more robust and user-friendly designs.
Conclusion
During the process of writing an article, I realized that communication is more than just talking. It involves a whole process of understanding each other's perspectives. It's crucial to ensure that there is no misunderstanding between the design team and the development team because the success of the project and the well-being of the entire team are of the utmost priority.
