The traditional way that developers and designers have worked together when building services and products was as two very distinct and separate teams. Designers would produce their designs, and then pass them onto the developers. The developers would then replicate them as accurately as possible.
This way of working keeps the two disciplines at a distance from one another, and leads to an “us and them” mentality, which in turn leads to misunderstandings, disagreements and distrust. Moreover, the whole process takes much longer as work keeps going back and forth, with no clear communication between the two.
Instead, designers and developers should be working together as part of a multidisciplinary team, discussing their work and collaborating on ideas. This should be happening at all stages of the agile process.
Planning together
It is essential that both disciplines attend planning sessions for the next sprint’s worth of work. When a designer and developer read a user story, each may have a very different idea of what it means, what work needs to be done, and what the constraints might be. As they discuss the story together these will come to light, leading to comprehensive acceptance criteria and how to achieve it.
It gives designers an idea of what technical constraints their designs will have to work within, and it gives developers a chance to understand what direction the designs may go in. This saves time later on as the stories will be more fleshed out and each discipline can begin the work with an understanding of the gaps that will be filled in by the other.
Making together
Developers should attend sketching sessions and workshops, contributing to the discussions and giving their advice so when it comes to coding the designs they are technically feasible. The two disciplines tend to see patterns that the other does not, leading to more creative and innovative solutions.
Once some ideas have come together, designers should avoid working in isolation and then handing over pixel perfect designs, but keep discussions about their work in the open. And then as a developer begins to start coding, any questions about the design should be discussed with the designer, preferably sitting at the desk with them (remotely or otherwise). Working like this saves time - for example changes can happen before the code goes into peer review or is put on a staging environment. It also demystifies the black box of coding for designers and gives them more power in the relationship to question why things are done as they are and suggest changes.
It is also great for developers to attend user testing sessions. This allows them to see their work being used, and understand the user problems themselves. Then, if the designs do need to change, they know why and can put the changes they are making into context. It also helps keep the need for user value at the forefront of the developer’s mind.
Reflecting together
Everyone then attends a retrospective to discuss how they worked together, and how the process might be improved for the next sprint. Maybe next time more developers should go to user research sessions, or a designer could talk through their designs before a developer picks them up. Some methods may work in some teams, but not in others, and having open and honest discussions about how you worked together allows the process to be fine tuned for each team.
What does this result in?
All this comes together to mean product development is quicker and has better results. There is less back and forth as everyone is on the same page from the start and continually discussing and improving the product. It removes the frustrations that inevitably happen when work is handed over, with neither side having a say what happens once the work is off their desk. There are also a variety of perspectives looking at ways to solve problems which will lead to more innovative solutions.
Working in this way creates a collaborative atmosphere where everyone can learn from each other in what is very much a team environment. It is important that this is happening at every stage of a project, not just the build phases. This can save a lot of pain and frustration later down the line when it turns out that what has been designed isn’t technically feasible, or that a user’s journey through the system doesn’t make any sense. And most importantly, it’s a much more enjoyable experience for everyone involved.