Driving collaboration between designers and engineers
Designers and engineers approach product development in entirely different ways - and that’s the beauty of it. Each team needs the other to bring ideas to life. However, too often a lack of collaboration creates a nasty little knot of misunderstanding, distrust, and frustration that’s very difficult to untangle.
What not to do:
The wrong mix can create an adversarial environment that’s toxic for the working relationship.
The silo effect.
Instead of collaborating, teams sit in separate rooms getting riled up, making assumptions about the other team and how they work. Assumptions create blind spots, and blind spots mean a mess of misunderstandings.
Us versus them.
It’s easy to fall into the ‘us versus them’ trap, particularly when things go wrong. ‘The mockups the designer supplied weren’t functional.’ ‘The engineer’s completely ignored this part of the design.’ Distrust between teams can chip away at the foundations of a project and make it all fall over.
Misalignment.
Do you know what’s going on? (No, really.) Not having visibility over agreed project timelines, clear deliverables, or a unified objective is a recipe for frustration and disappointment.
Lack of communication.
‘Don’t they know that’s not how I wanted it done?’ Well, that’s exactly it - they don’t. Not being transparent and communicative throughout the process leaves a lot of room for misinterpretation, and deviation from what you’d envisioned.
How to make it work:
Acknowledging and accommodating the differences between designers and engineers can prevent headaches later on.
Talk to one another.
A lot of resentment can be avoided up-front if teams simply speak to each other from day dot. Don’t merely pass work along the chain - be collaborative, and solve the problem together from the get go.
Designers - it’s useful speak the language of engineers (they’ll be forever grateful). For example, knowing a little code goes a long way. When supplying mockups, get specific - show examples, working mocks (with animations or similar) - anything that builds context.
Expect the unexpected.
Transparency is crucial. Get the teams in a room together and lay it all out. Figure out what you can and can’t do before you start the project.
That way, everyone can agree on scope of work, and have a clear idea of any pain points (e.g. tight timelines, small budget, lack of resources). Understanding this upfront empowers the teams, and means there are no surprises if problems do arise later on.
Process, process, process.
Even if you have the best collaboration tools on hand, without a clear process that everyone sticks to, you’ll never be fully unified.
- Work together to develop the project timeline - designers and engineers have very different concepts of hours required.
- Have regular WIPs in the diary, so that everyone’s across each stage of the project.
- Make sure all comms are in writing (it can be tempting to grab someone at their desk for ‘just a minute’, but follow up with a note somewhere for the wider team to have access to).
- Think about common naming conventions for all files, well organised and labeled correctly.
Work, together.
Get rid of the wall - literally. A session with the designer and engineer in the same room (or same desk even) not only streamlines the process, but helps foster relationships that’s great for workflow.
Think about it. Are you more likely to make those changes for someone whose name you see pop up on email occasionally, or Amy who regularly checks in over a call or in person? Never underestimate the value of building relationships (or a cheeky coffee or after work drink, either.)
Flex your empathy.
When things threaten to change, it’s instinctual to not budge. You’ve worked too hard on the visual direction, or you just know that design is almost impossible to code. Here’s where the empathy needs to kick in - a little flexibility goes a long way. Be prepared to let go of some ideas - it’s not about you, but the greater success of the product.
Designers and engineers ultimately produce better work when they’re working as one team - even if they do look at it in different ways.