Why talking more won’t solve your design/dev collaboration problems

In case you missed it: We launched a new free book, the Design Engineering Handbook. To celebrate, over the next couple of weeks we’ll be publishing excerpts we think Inside Design readers will find especially useful. Here, author Natalya Shelburne explains why the designer-developer “gap” is all in your head: 

If collaboration between design and engineering were easy, everyone would be doing it and you wouldn’t be reading this. The hard truth is that the effort to facilitate effective workflows between disciplines is as real and challenging as the rest of our work. In fact, it’s an entirely new way of working. Fortunately, there are steps anyone—from an individual contributor to a team lead—can take to help create the conditions for the efficient exchange of ideas and empower people to do their best work. But those steps are not “talk more” or “sit next to each other, ” which both render the effort of creating effective workflows completely invisible. The first step is asking yourself, “How can I make the way I think, decide, and create more visible?”

I know this because I did that invisible work myself for years. My passion for both design and engineering meant I always volunteered to be the one to bridge the infamous gap between the two. Scope creep? Work late. Surprise feasibility issue? Close some tickets on the weekend. Notifications always on and mind always occupied. Like many, I felt the guilt of stepping away, so I didn’t. I saw myself as the expert, and my prize was late nights, stressful deadlines, and the occasional frustration at anyone who disagreed.

But all of this changed once I needed to go on parental leave. I realized that I felt like everything would completely fall apart if I left, since no one would be doing that invisible work. Collaboration would grind to a halt without my maintenance of the collaboration channels.

My first impulse was to document the specific “right way” to do things, like translate between design assets and engineering implementation. But then I realized that no individual who values their time would ever read that.

It hit me: The solution wasn’t to keep lobbing the same old ineffective solutions back and forth. Documenting the “right” way of doing things was essentially the same mindset as speaking louder in hopes of being heard. Instead, I realized I needed to introspect openly and honestly and identify my own patterns of failure. I was a skill silo, a bottleneck. I had to embrace meaningful organizational change, and that started not just by formalizing my working methods.

I thought back to my graduate education, where I learned that “gaps,” like those between design and engineering, are often the result of a struggle to communicate effectively at the intersection of different mental models. People aren’t computers. They don’t just acquire knowledge line by line as they read it; instead, they organize patterns of thought in their minds and construct meaning in the form of mental models. When confronted with more information, they reinforce or adjust their mental model of how things work. That means prior knowledge is key. Every new bit of information has to interact with our existing mental models of how stuff works. What you learn first matters: It serves as the foundation upon which you build understanding. Our starting points inform our perspectives, which means that two individuals can have two very different experiences of the same event. Intersections where people with different mental models need to work together tend to be loud and sometimes even hostile— but that’s where learning happens.

Establishing conditions for growing effective design and front-end workflows means working with the people you have, not the people you wish you had—starting with yourself. I needed to facilitate the transition between my mental model of how things worked and the mental models of my coworkers. And to make that happen, I needed to create systems, tools, and workflows to enable others to do the translation between design and engineering without being inside my head. I created a style guide and component library to make our design patterns visible and honed a structure to relay it to the application code: the layout rules, colors, functionality available. The hope was to help my colleagues learn how to speak the same language as I did, and make sure we were talking about the same things.

It felt like a huge risk at the time—making myself entirely redundant and replaceable—but it turned out to be the best thing I’ve ever done. Since then, I have been obsessed with creating systems that help lower the barriers to contribution. When I’m not working solo, I shift my focus to thinking about what would enable my teammates to work best instead of what would be most comfortable for me. On the front end, for example, I embraced CSS modules despite my own preferences so that other programmers on the team would feel more confident about writing CSS. The module approach more closely matched their existing mental models of programming, and I no longer had to review every pull request that contained style changes because now any error would be scoped by default instead of remaining precariously global.

If you want to change how your team works together, changing how you work is mandatory. Fortunately, getting out of one’s comfort zone is the best way to learn and grow; in our fast-paced world, that’s a very good thing. Whether you’ve been part of a cohesive team collaborating and communicating effectively or a team struggling to sync up, asking more questions will help determine your systemic pain points and guide your next steps.

Here are some questions you might ask:

• Where are your team’s collaborative pain points? Is someone constantly having to pick up the slack? Is a single person a bottleneck for a workflow or process?
• Are unhealthy team dynamics emerging? Are designers and engineers increasingly feeling unheard or undervalued for their contributions?
• Do we frequently experience feasibility surprises and amass technical debt as a result? Do we find ourselves reinventing the wheel? Are we losing time solving solved problems and duplicating code and effort?
• Who owns the work? Who is accountable? Who reviews the code? How does a component get shared? How do we collaborate on ownership?
• Is our approach too waterfall-like? Are engineers unable to start working (prototyping, validating, scoping work) until designs are finalized? Are designers having to make decisions without having requirements set?
• Are design and UI in alignment? When design brand guidelines are updated, who makes sure those changes are correctly updated at the appropriate level without creating overrides or inconsistent implementation? How do we test that something is not missing?
• Are we having a lot of unnecessary, unproductive meetings? Are we throwing time at the problem of communication gaps?

If any of these questions hit home, it’s time to take a deeper look at the patterns of dysfunction that have emerged. Every workplace and team is unique, but since the barriers are arbitrary and largely self-imposed, a lot can be done to overcome them. The first step lies in increasing the flexibility of your own mind, un-siloing ourselves, and deliberately practicing acquiring different mental models. Collaboration does not happen by accident. Like the products we work on, it takes design and engineering.

Read Natayla’s entire, unabridged chapter in the Design Engineering Handbook—available in epub, PDF, and audiobook formats.