As a designer, how often have you been in a situation where the engineers on your project don’t correctly capture your design in code? For some, unfortunately, this is a regular occurrence. However, it doesn’t have to be.
What does Designer-Engineer synergy mean?
It is the collaborative relationship between designers and engineers when creating digital products or experiences.
Why this synergy is important
- It ensures consistency between the design and the final product.
- It improves the workflow and reduces misunderstandings between both teams.
- When designers and engineers work together, it creates an avenue for sharing diverse ideas and perspectives, leading to better problem-solving.
Tips on achieving synergy
Good communication is the secret to any successful product development cycle and the backbone of this synergy. Here are some tips on how to improve communication with engineers.
Early involvement of engineers
Product development is not linear. It involves cycles of feedback, iteration, and refinement. In the same way, the collaboration between designers and engineers shouldn’t be treated as a linear process in which the engineers only learn about the design after it has been completed.
Instead, engineers can be more involved in the design process by providing context to technical bits of the product development process that may affect implementation.
A good rule of thumb for designers is to bring in the engineer when uncertain about a design’s technical feasibility, share ideas, and brainstorm workarounds if needed.
Design Handoffs
There isn’t one way to properly hand off a design to engineers. However, one thing to avoid is only sharing a Figma link and expecting the engineers to figure it out themselves.
Handoffs could take the form of a properly documented Figma file where you give context to every screen (through written text). They could also take the form of a huddle or call where you verbally explain the flow to them or a prototype of the design that they can interact with. Either way, the type of handoff you do generally depends on what’s most comfortable for you and your team.
Regardless of the method, you should use the handoff to provide detailed information about the design.
Testing and Feedback
Ensure that proper testing has been carried out before a project goes live. Testing usually looks different for different teams. For example, Product managers may focus on whether the implementation matches the requirements provided. In contrast, engineers may focus on whether the implementation works as it should. Designers should test to ensure that the design and the final product are consistent. If they aren’t, you should provide feedback on areas of improvement.
Know when to be flexible.
When engineers push back on our designs, it’s often because they’re not technically feasible. Sometimes, despite our efforts, our design approach just isn’t doable, which can be a difficult position for a designer. In such cases, it’s important to listen to the engineers’ concerns, understand the technical constraints, and work together to find a solution. We may need to rethink our approach and come up with a technically feasible design.
An example was a recent project where we updated the payment screen design. The back story here is that customers can have multiple accounts within the same bank, which can be used for direct debit — investment top-ups directly from customers’ bank accounts. The original idea was for customers to swipe to see their other accounts, and if an account hadn’t been linked for direct debit, they could do so from there. However, after the handoff, the engineers informed me that the different heights of the cards would make it difficult to implement the swipe feature.
The solution was to make both cards the same height. Putting any extra information in a bottom sheet that will come up when a customer taps on “see more”.
However, there are times when our designs are technically feasible, but we still face pushback from engineers. In these situations, it’s a chance for us to explain the reasoning behind our designs and show their value. We should clarify our decisions, highlight how the design supports the project goals, and be open to feedback. By collaborating and compromising when needed, we can create solutions that balance design and technical considerations.
To conclude
Collaborating with others isn’t a one-size-fits-all situation. What may work for some, may not work for others, and that’s fine. In such situations, nuances and individuality always come into play. That being said, always pay attention to what works best for your team.
