Rethinking designer-developer collaboration
Designers and developers… Two sets of folks. Two ways of thinking. This seems to be the consensus with most design and development teams. Developers think designers are the fashionistas of the IT world (and not in a good way), while designers view developers as code monkeys. To work well together, rather than to focus on the differences, we need to focus on what both teams are trying to achieve. Make themselves happy! Make customers happy! Make amazing products!… and maybe get out of work early?
With this in mind, we want to take a look at how these folks can work better together, as parts of a cohesive whole, rather than butt heads with each other over the simplest things and waste time on miscommunication and rework. Can we as a business improve the overall efficiency of our entire team by making just a few changes in how we work?
Get both teams involved
There is a tendency to keep the design team involved solely with the design and to keep the development team as far away from it as possible until one day suddenly it’s thrown over the wall and they are expected to work on it. We think this is a formula for disaster. Most designs have already been approved by customers before the development team even has a look at them, and by then having an opinion on anything is fairly moot. Because, as we all know, customers are so kind and understanding as a whole!
Alternatively, why not involve your development team from the beginning of the project? It’s expensive you say? More expensive than rework? Or having to go back to the customer with a design that can’t be implemented?
Look, we are not advocating that the entire development team sits through every single meeting, and looks over the designer shoulders, shouting out instructions and opinions on every single pixel. Have representation though, if the development team feels that they were part of the design process they are also invested in the design and if their feedback is taken into consideration then in later stages there is little room for designs that can’t be implemented for whatever reasons.
Go Agile
Do you know what’s a good idea? At the start of each project take a few weeks off to design the entire application. Sit separately. Don’t show it to anyone till the end. Then finally reveal it, hand it over to another team, and walk away. Sounds good? No, of course not!
And if you do that in your company, be assured, no one likes you much! Instead, why not go at it piecemeal. Break apart little chunks of work and have both teams sit down with it (is it really two teams then?). This will really help to reduce miscommunication while emphasizing on collaboration and helping to weed out any issues that otherwise might choke the project later on.
Apply these same thoughts to development. It’s way better to create chunks of an application and make sure you apply the design properly than complete development on an entire product only to find out you missed some small aspect in the design which is going to create major changes and needs massive rework.
Don’t be a knowledge snob
You are not going to sully yourself by knowing a little bit about designing while being a developer, or about development while being a designer. Do you know what it will do? Add value! To your company, to your team, and most importantly to you as a person. Look at you! Growing up, learning about other disciplines, making important contributions. Go you!
Nothing helps you understand another person’s view better than actually being able to understand it. Having some insight into each other’s disciplines goes a long way into being a better team, and creating better products.
Have a good hand off process
Make sure your company has a good process when you are handing off a design to the development team. In addition to making sure everything is labelled and marked clearly, and that your designs systems are up to scratch, there also needs to be a proper hand-off review where any questions can be asked and answered. While we are not in any way saying that access to the design team will be limited to the development team, I’m sure both teams are happier when they get their doubts clarified before starting development.
The same principles apply to the development hand off. Before the completed product is handed over to the QA team there should be a review with the design team to ensure that the design has been implemented correctly, and there are no miscommunicated requirements.
Communicate, communicate, communicate
In this era of communication tools, it’s amazing that we are talking to each other less and less. It’s great to have comments on Abstract, it’s awesome when you have a dedicated channel on Slack, and when used properly design systems have gone a long way to reducing the tension between design and development teams. But sometimes some old-fashioned face to face is really what you need to iron out any issues you are running in to.
Talk to your development team about the designs you make, while you are making them. Don’t complete an entire application and then get frustrated when people poke holes all over it. If you are all working on one product, why not work on it together? Have a common space, spend time with each other. Who knows, you might even make friends.
And please, don’t rely solely on documentation. Documentation is great, but a lot of things get lost in translation. Plus there’s a lot of people who will not spend too much time analysing and interpreting everything in that document.
Summary
For a great work environment resulting in great products, design and development teams should work together as part of a whole. Involve both teams throughout the life cycle of the product, get feedback from each other, help each other improve. Learn about each other’s disciplines, learn to appreciate and celebrate the differences. Work to process to work better, but don’t let it limit you. And most importantly, talk to each other folks!
How can we help?
At Amplifyn we work with corporates and startups who are ambitious in transforming the traditional business to improve financial performance. Over the years we have developed processes, skills, tools, and right people to do just that.
You can read more about our work at https://amplifyn.com or email us at about your ideas on hello@amplifyn.com
