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 with design collaboration tools 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 the above episode of “Designer vs. Developer,” host Mustafa Kurtuldu explores how designers and developers can facilitate easier collaboration.

Is it really “us vs. them?”

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.

Myles Palmer

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 skill sets and understanding each other’s discipline is key to ensuring smooth working practices. For some, this might mean casual coffee klatches where teams can share what they’re working on. For others, it might take the form of a set meeting or lunch where co-workers can give mini talks aimed at educating one another on the unique aspects and challenges of their corner of the industry.

Fostering co-creation

As well as encouraging empathy between designers and developers, it’s also important to consider how these diverse skill sets 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. A lot of companies claim to value collaboration, but few understand what this means on a day-to-day level. In order to truly foster a culture of collaboration, you have to hire with that in mind. This means bringing in experts in a range of skills and subject matters, and putting them in direct contact with one another in addition to working independently: product design with engineers, engineers with researchers, developers with designers.

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.” 

A fully integrated process

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 is 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.”

Forest Young, Wolff Olins’ global principal and head of design, talks technology, culture, and design.

Clients love prototyping, too

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 article was produced in partnership with AIGA Eye on Design.