“The most dysfunctional relationship between designers and developers happens when there is a distinct division of labour.”
You’ve probably caught wind of all the collaboration hype these days. At Polymorph, it is a way of life. We breathe collaboration, and it’s what makes our product teams stand out from the crowd. It is also one of the reasons I love working here as a UX designer. Collaboration is a game-changer that can either make or break a product.
I decided the best way to tackle this topic is by utilising …. you guessed it: collaboration! So, I chatted with a few of our developers to learn more about their experience working with UX designers – specifically, what they felt was working well and where there’s room for improvement.
In this article, I’ll look at the following issues and recommend best practices for each:…
Without further ado, let’s jump in.
Unexpected Changes
Last-minute tweaks to the design can throw off planned work, requiring developers to reshuffle tasks and adding unnecessary stress. This can become frustrating and create a lot of resentment between team members.
Best Practice: Create a page (in my case in Figma) where you can explore and play around with designs. Then create a separate page for your final designs that you DO NOT TOUCH. This page is for the developers and you only make changes here after discussing it with your team. And always try to keep it up to date. Nothing is more frustrating for anyone on the team than having to figure out where the latest designs are saved.
Developers going “off-script”
Sometimes developers go off-script without consulting their UX designer. This can breed feelings of disrespect and undervaluation of creative efforts. If the developer feels that they cannot talk to you before implementing a change, then it is up to you to initiate that camaraderie. Talk to them and get their thoughts or advice about the project before you even start the UX review. This step isn’t a waste of time at all; it’s a great opportunity to build a stronger team. Plus, it’s especially useful for understanding any technical limitations right from the beginning. Developers also have the users in mind when they are building a product and oftentimes UX issues are spotted during the development phase. As UX designers we thrive on feedback from users, why should feedback from our colleagues be any different?
Best Practice: As a developer, it is important that you feel you can chat with the designer if you have any questions about the design. As the designer, it is essential to be open to suggestions from your developer and not get defensive. You are NOT your designs! And you never know when they might come to you with a perspective you might not have considered! Embrace each opportunity as one you can learn from which is exactly what my next point is about.
“As the designer, it is essential to be open to suggestions from your developer and not get defensive.”
“It’s not you, it’s the design”
This bears repeating. You are NOT your designs! Taking UX review feedback personally can create an “us vs them” mindset, impeding effective collaboration. There are times when a feature gets the green light in the UX review and everyone’s on board. But a week later, during the refinement phase, or maybe two weeks later when the developer gets into the nitty-gritty, we hit a snag. That’s when you might hear the developer say, “Wait a minute, this won’t work. How about we try it this way instead?” It’s important to remember developers aren’t doing this just to be difficult. It’s often only during the actual building process or when they’re delving into the more intricate technical aspects and requirements that certain issues become apparent. This level of detail usually isn’t, and perhaps shouldn’t be, a part of the UX review process. If you find yourself fuming during review sessions, it is best to take a step back and check in with yourself about why you’re feeling upset. Maybe go make a cup of coffee and listen to that song you love. Until the emotions blow over and you realise that none of it mattered, as long as the design can be improved. There is always room for improvement. Best Practice: Voice encouragement for constructive feedback and don’t ignore it when a team member gives their opinion on the design. Consider it, and if you have a better solution, suggest it and explain why you made that decision.“I’m not implementing that”
Insisting that developers implement a design won’t get you very far, especially if they have voiced concerns about its feasibility. When you force a design decision on developers, it is the opposite of collaboration and it can stifle any future work you might need to do with them. Best Practice: Rather listen to your developer. They know what’s best from a technical stance. This is why discussing the design with them is so important. This will foster trust and mutual respect and make working on the project that much easier and enjoyable. Congratulations! You’ve come this far, and here are some bonus tips as a reward.BONUS tips
- Encourage regular brainstorming sessions. Got a design idea? Initiate a huddle with your developer. Chat about it.
- Find out what design system your developers will utilise (e.g. Material3). It will make it easier for developers to implement.
- Provide your team with earlier access to the design journey. This could facilitate timely input and prevent developers from feeling “stuck” with a design that has progressed too far.
