Illustration by Aysha Tengiz

Between 2017 and 2018, Google produced a series of 24 short videos that saw digital designer Mustafa Kurtuldu interview a host of designers and developers about the various quirks of their profession, from “Becoming a Creative Coder” to “UX Research and Usability Testing.” Despite the tongue-in-cheek title of the series, Designer vs. Developer, it was intended to offer insight into the multiplicity of outputs each field could produce and encourage more collaborative working practices between the two disciplines. A utopian vision of teamwork was revealed.

As is nearly always the case online, the comments below the videos told a slightly different story, and showed a level of discontent among designers and developers working at the industry’s coal face. They were not having the same seamless experience of collaboration as the folks who appeared onscreen—for whom cross-disciplinary teams and design sprints seemed to be the norm. “What I would give to have a designer actually listen to me,” said one. “I think it’s refreshing to see there’s actually teams out there that collaborate. I’ve rarely been in that situation and it’s become very frustrating to the point of wanting to do something else with my life.” Bummer.

In many ways, the problem of interdisciplinary collaboration has to do with a misconception of who designers and developers really are and what they do all day. “I think the perception of designers is that they are very creative people that work in abstract and fluffy ways—the kind of classic art student stereotype,” says freelance digital designer Myles Palmer. “It’s the opposite for developers. They’re seen as geeks, they’re nerds, they’re super serious people that are wired a certain way. A lot gets made of this false distinction and when they then work with each other, people think it’s like bringing polar opposites together. But it’s just nonsense. One of the people who’s taught me the most about design is a developer, so this us vs. them dynamic isn’t helpful at all. Everyone should be open to each other”

At this point, designers and developers should be seen as two sides of the same coin; designers need basic literacy in some programming languages just as developers ought to have a grasp of typography and layout. And yes, the debate about whether designers should code has run its course by now, too. (Of course they should know how to code, at least a little. Nobody’s ever seriously wondered whether it’s important for a magazine designer to be able to read.)

Sharing skillsets and understanding each other’s discipline is key to ensuring smooth working practices among the teams at Figma, a design, development and prototyping tool that facilitates real-time collaboration among teams. “I think more understanding comes from exposure,” says creative director Tori Hinn. “We try to make programming more accessible to everyone. Every Thursday we invite everyone in the company to bring their lunch and listen to a lightning talk by one of their co-workers. They started as tech talks—a way for engineers at Figma to educate their coworkers on different parts of their industry—but they’ve since expanded to be about other topics. It’s a really simple way to learn about other disciplines and gain a better understanding of the challenges they’re facing.”

As well as encouraging empathy between designers and developers, it’s also important to consider how these diverse skillsets can work within a team. Getting the right breadth and depth of understanding can have a huge impact on how a project or product comes together, not to mention whether team members feel positive about the process of co-creation.

At one level, this simply comes down to smart staffing. “All work at Figma is highly collaborative,” says Hinn, “so we try to be really thoughtful with how we staff and hire for teams. The design team, for example, has people who are each an expert in a different part of the design world. The product design team works directly with engineers, but mostly independently of each other. Each engineering team also tackles a different part of the product and experience and is deeply integrated with designers and researchers. On the brand side, our designers work with each other, but they’re also integrated closely with developers and design. So we’ve tried to create teams that have experiences far and wide, which gives us the most creative reach.”

At Wolff Olins, one of London’s largest branding agencies, the scope of work is more diverse and teams are built on a project-by-project basis according to the client’s needs. “We don’t have any full-time, in-house developers at the moment,” says senior designer Steffan Cummins. “We have had some in the past, and may do again, but it’s always about trying to find the right person to adapt to the type of work that we do. The challenge we have is that we work with developers in so many different capacities—whether it’s web development, creative technology, prototyping, or interaction design — that we need to try and find the right person for each job.” 

While that means Cummins and his team can work with some of the best developers in the business at various stages of a project, in some cases they’re not brought onto a job until the very last minute. “When it comes to the fine detail and final execution, that’s when we usually bring in the specialist developers,” he says. “By that point we know exactly what needs to be done. We’ll have a clear brief and can make sure we get the right people involved.”

Palmer thinks that having developers as part of a team from start to finish of benefit to everyone. “People so often treat digital design like it’s a print process,” he says. “You design something, give it to the developer to make, and then they send it back to you. It shouldn’t be like that. Digital design is a living, breathing thing that evolves over time. Devices change, technology changes, people’s habits change, and so it has to morph and grow with that. It’s a living organism.

“Ideally, you want everyone working together from the start of the project. It’s a much more iterative and enjoyable way of working. You do smaller chunks of work, put them out there, get people to use it, take the feedback, and then spend another week refining it. The alternative is a system where stuff gets designed without technical consideration, it’s passed on to a developer for building and the final result isn’t how anybody expected it to be because there’s been this big divide.”

Working iteratively with both designers and developers can be a big bonus for clients. Instead of waiting for the release of a final developed product, they can play with interactive prototypes at different stages of the project, getting a real flavor of how a product actually functions. “Even a super lo-fi prototype helps to engage the client,” says Cummins. “It’s important that they can actually understand the interaction.”

“We can’t all just imagine things in our heads,” agrees Palmer. “You can interpret something as simple as a page scroll in so many different ways.”

So if it’s good for the design process and helps to engage clients, why aren’t integrated teams of designers and developers already the industry standard? Unfortunately, it’s often budgets that hold teams back. “There’s a constant expectation that you can do things faster and better without an appreciation of what it takes to produce good design and development,” says Cummins. “That means designers and developers are often under pressure to come up with a minimum viable product in the quickest time.”

“Clients need to understand that creating great digital products takes time and a fluid collaborative effort. It’s not a linear process,” says Palmer. “It’s a constant loop. It’s a spongy blob that you’ve got to morph. The sooner people embrace that, the better.”

This story is part of an ongoing series about UX Design in partnership with Adobe XD, the collaboration platform that helps teams create designs for websites, mobile apps, and more.