There are few forces as formidable as designers and developers working together. When they’re working effectively, they hardly need anyone else. Entire companies have sprung up around strong designer+developer teams, and these collaborative teams have built many of the tech and social platforms that have changed society itself in recent years.

When designers and developers are in sync, they can truly change the world…but the trick is getting in sync in the first place.

Collaboration is a learned skill. As humans, we all generally have the instinct to work together for the greater good, but we don’t always have the instincts, experience, processes, or models to know how to make it happen in practice.

So, we flounder. We guess. We experiment. We frustrate each other. We argue. We point fingers. And sometimes the final product turns out okay after all that. Sometimes it doesn’t. Either way, it’s a rough journey, and we sometimes wonder if it’s worth it.

The problem isn’t collaboration, though. The problem is not knowing how to do it. If both sides can learn the skills required to work together successfully, they can accomplish miracles in a consistent (and even scalable) way.

Neither designers nor developers alone see the whole picture

In the old days at Forty, we used to approach a typical web project as being something like 80% design and 20% development. We’d put in a huge effort to carefully explore and craft every aspect of the design process, then bring in a developer to quickly execute what we’d done. It took us years to realize how essential developers were to the process, and to gradually shift to a process that really embraced development as part of the process.

Early on, Crowd Favorite had the opposite issue. As a tech-centric firm, it would tend to look at a website project as 20% design and 80% development. Engineering and technology were seen as the heart of the project, with design just being a single step in the larger process.

Both views are totally understandable. And both are wrong.

In March 2014, at Owner Summit in Portland, I happened to sit next to my friend Alex King at dinner. Since we’d just spent the entire day talking about business strategy issues, my head was swimming with ideas about where Forty might go next, and I opened up to him about my plans to start building out a development team within our company.

Alex said it was funny I’d mentioned that, because they were having the inverse problem at Crowd Favorite, and were trying to figure out how to build a more robust design team.

“Huh,” I said. “That’s interesting.”

By May we’d made a handshake deal to combine the companies, and actually started integrating our teams. By November we’d finished the paperwork and made it official.

Crowd Favorite’s acquisition of Forty was fundamentally based on the idea that neither designers nor developers alone see the whole picture. Each side needs the other in order to create a whole solution. It’s a yin and yang kind of thing.

Nothing is obvious

The classic rookie mistake made when teams from different disciplines come together: assuming the other team knows what’s normal and expected for you.

The initial communications between design and development teams often sound like this:

• “I thought you knew…”
• “Isn’t it obvious?”
• “How could they not realize?”
• “Why didn’t you just follow standard practice?”
• “Everyone knows you’re supposed to…”
• “I don’t understand why they did it that way.”

It’s difficult for us to remember that the ideas we take as universally understood in our own industry may be completely new to the people we’re working with. If you’re a developer, it may seem utterly shameful that the design team doesn’t have their past client work in a carefully organized version control repository. If you’re a designer, you may scoff at a solution the development team previously built for the client that missed several important UX design patterns.

Instead of mocking, blaming, eye-rolling, huffing, weeping, and gnashing teeth, we’d all do well to remember that both sides bringing an incomplete set of answers to the table. The other team isn’t really as clueless or incompetent as they seem (at least not any more than your own team is).

However, if you put what your team knows on the table and mix it up with what the other team knows, you’ll gradually realize that they had a lot of pieces you were missing. If both teams work together collaboratively, instead of competitively, they’ll be able to create a significantly more robust and polished solution than either team would have been able to come up with on their own.

To do this, though, you have to accept a couple of hard facts:

• They may know something you don’t.
• They may not know something you do.

You have to get really comfortable with those facts in order for this to work, because they’re going to come up on a daily basis.

(If you instead react to those facts with fear, anger, negativity, sarcasm, passive aggression, insinuations, haughtiness, defensiveness, or any other negative vibes, the whole thing is going to fall apart fast.)

Overcommunication is essential

In order to overcome the knowledge gap between teams of different disciplines, you need to communicate MORE:

• more often
• more clearly
• more empathetically
• more diligently
• with more detail
• with more feedback
• with more follow-up

If you’re a designer handing approved mockups over to a developer, for example, you should never just email her the the layered source file and say “Here you go!”

Instead, you should walk through the design with her in person or by videoconference, explaining how it should work and giving them the opportunity to ask questions you might never have realized she’d have. You can then provide a writeup of your notes so she has it as a reference while she’s working. While she works, you should check in periodically and ask how she’s doing, and see if she has any questions.

When she’s done with the draft code, you should review it with her to make sure it’s working the way it was intended to work. If the responsive layouts are off, or the animations aren’t timed right, etc., you can have those conversations and talk through the details.

It can feel like a lot of work in the beginning, but overcommunication is the process by which you can ensure solid work pretty much every time, even with people who’ve never worked together before.

Pretend you’re a center fielder in the World Series. The batter smacks the ball. It flies out toward the stands, then starts to descend right between you and the right fielder. You’re facing four possible scenarios right now:

• One of you assumes (correctly) that the other will run under the ball and catch it. Risky. It works, but only because you got lucky.
• One of you assumes (incorrectly) that the other will run under the ball and catch it. The ball drops on the field with neither outfielder having moved, and the opposing team scores three points. Embarrassing.
• Neither of you assumes the other has it, and you both run toward where it’s going to fall. You collide catastrophically. The ball drops on the field right next to you, and the opposing team scores three points. Really embarrassing.
• Neither of you assumes the other has it, and you both run toward it. Both of you communicate as you approach the landing spot: “I can’t quite see it.” “It’s okay, I’ve got it.” “Are you sure?” “Yeah, I’m sure.” The ball drops safely in the right fielder’s glove and the batter is out.

When in doubt, overcommunicate.

The sublime joy of standardization

As teams work together over time—and especially when they’re doing a good job of overcommunicating—it quickly becomes apparent that some things can become accepted (and hopefully documented) conventions.

For example, it may take significant discussion to identify a WordPress plugin to use for social sharing that fits the technical constraints of the project while being customizable enough to fit with the overall design approach. However, once that’s been discussed and agreed upon, it’s possible that the project team could begin using that particular plugin as a baseline assumption, unless there are logical reasons not to use it. On the next project, the wireframes and mockups delivered to the client could reflect the assumed use of that particular plugin, saving both the design and development team a lot of time and effort.

It can sometimes feel (especially to designers) like standards and conventions are “cheating,” and that the only right way to do justice to the project is to think everything through from scratch. It’s not actually true, though.

User experience design in particular is built on a robust and constantly-evolving framework of assumptions, conventions, and standards. It’s not cheating for a site to have a horizontal main menu bar, a search bar at the top right of a page, a copyright statement in the footer, etc. We take these all for granted, but there was a time when these aren’t conventional, and every site took a different approach to solving those needs. No design pattern is appropriate for every situation, but there are absolutely opportunities to use the exact same design pattern across many situations.

Design and development teams should work together to understand what they can do to make each other’s lives easier, or simply to understand how the other prefers for things to work, and then codify those conventions as accepted standards to be used later. They can be anything from interaction design patterns to file naming conventions; standardization helps all around.

Documentation alone isn’t communication

This can sometimes be a difficult concept to embrace, especially in an industry that really loves its asynchronous electronic communication, but it’s important to understand that sending someone a long email, a marked-up PDF, or a Google Doc full of notes isn’t the same as actually communicating with them.

In the event of a misunderstanding, it’s really tempting to go back to the written documentation to point something out as proof that you’re right and the other person (often your teammate) is wrong. “Ah-ha! It’s right there, see? On page 17, paragraph four, in the second footnote of this document I sent you three months ago. Didn’t you see it? Can’t you read?”

Listen, it doesn’t actually matter what you said.

It really doesn’t.

(And that’s hard to accept, right?)

It’s not your job to say things; it’s your job to make people understand things. You can’t just throw some words at the problem and walk away feeling as though you’ve washed your hands of the issue; you need to check in with the other party to confirm that they actually understand what you’re talking about. If they don’t understand, that’s on you, not them.

I used to see this issue come up often in project scope debates. The team would tell the client, “Okay, here’s the final deliverable, so we’re done,” and the client would freak out: “Where’s the [whatever]!? What about the [something else]!?” The project manager would intervene by politely going back to the original statement of work, which “clearly states” (a phrase that almost always highlights a poor communication exchange) that those things weren’t included in the project scope.

Here’s the deal: If you ever have to go back to the original statement of work to prove a point to the client, you’ve already blown it. The scope should have been crystal clear to the client at every point along the course of the project, not a surprise to them as the project is wrapping up.

Design and development teams should be particularly careful about this because they’re often speaking different languages and coming to the situation with different expectations, so opportunities abound to misinterpret or misunderstand documentation.

Written documentation is great as a reference, supplement, clarification, record of an agreement, etc., and it can and should be used for those things; but beyond that, there should be regular two-way communication between the designers and developers, whether in person, by phone, or by video conference. (Chat and email don’t count.)

Documentation creates the illusion of actual communication, but it’s just a mirage. Don’t fall for it.

Dynamic solutions require dynamic prototypes

We’re entering an era of digital design that’s full of dynamic interfaces, including the following:

• User feedback animations
• Variable screens that adapt to user behavior
• Pages that change without making a round-trip to the server
• Animations illustrating transitions between states
• User flows spread across multiple screens for clarity
• etc.

In this situations, the traditional approach of creating “wireframes” (a digital design deliverable equivalent to an architect’s blueprints) may not tell the whole story. Saying, “Don’t worry, you’ll understand it when you see it finished” defeats the whole purpose of doing wireframes in the first place.

In this kind of situation, dynamic prototyping may be required in order to more accurately convey a sense of what you’re recommending. By enabling the client or other project team members to actually see and interact with the interface in a higher-fidelity way, you get clearer feedback, more constructive criticism, and approvals based on actual understanding.

There are many solutions out there, including prototyping tools like InVision and Axure, clickable HTML prototypes made with front-end frameworks like Bootstrap and Foundation, animations created in PowerPoint or Keynote, etc. Technology isn’t the problem so much as it is including the time and budget in the project to allow for additional time spent building the prototypes.

Apart from helping the client to understand the prototype, though, there’s a powerful additional benefit: designers can help developers clearly understand the intended functionality of an interface. It’s helpful to stare at a static wireframe and try to explain what will happen, but far more helpful to allow the developer to click around, see how things respond, see where things lead, and so on. It gives them a clear sense of your intentions, and significantly reduces the opportunities for misunderstanding, which saves both designer and developer time overall.

Always be able to summarize what’s going on

You should always understand roughly what’s happening with a project, and be able to explain it if asked. There’s a temptation to say things like “I don’t know, they’re doing some designy stuff” or “Oh, the developers are doing their techy things now,” but both of those can cause major issues because the overall lack of understanding may cause important questions to go unasked, issues to go unnoticed, etc.

At any given point, you (as the developer, designer, project manager, or whatever else you are) should have at least an approximate idea of what’s happening with the project, even if it’s not in your particular phase anymore. While a design is still being sorted out, developers can contribute a lot of insight and perspective, and also prepare for what’s coming by understanding what kind of functionality and interfaces are being discussed on the design side.

Similarly, even after handing off the approved designs, designers have an important role to play in helping the developers to understand and interpret the intended behavior, to help steer smaller design decisions that may come up over the course of the development project, and potentially to help with the quality assurance testing after development is completed.

At any given point in the project, you should have a relatively clear—even if summarized—understanding of what’s happening with it, even if you’re not directly involved. If you don’t know, just ask someone who does for a quick status update.

An occasional minute of conversation can save dozens of hours of additional effort later on.

Compromise clears the way for success

Designers want things the way they want them. Developers want things the way they want them. And unfortunately, sometimes those things don’t line up nicely.

This can lead to some passionate debates about what matters, what doesn’t matter, “Why can’t you understand?”, etc. And because practitioners of a particular discipline have had the importance of certain practices or techniques pounded into them over the years, they’re very wary of compromising on them.

Because no one person has a complete view of what’s important for the project, it’s essential that everyone involved clearly understand that their view of what’s important is skewed by their past experiences, their particular talents, etc., and that there may be items missing from their priority list. Their perception isn’t the only valid one.

That being the case, every effective project will involve some amount of compromise. Neither idealistic designers nor idealistic developers are as effective in practice as it might seem like they might be, because they can wind up being uncompromising and unwilling to see that there may be important issues in play other than their particular pet issues.

Good collaboration between design and development teams requires an appreciation for the insights offered by both sides, and a willingness to occasionally let go of an issue if someone else is making a strong case for something outside your area of expertise.

You don’t need to let people walk all over you or fail to make your voice heard in order to collaborate well. In fact, both of those actions are contrary to the spirit of a truly collaborative team. However, you should definitely be willing to compromise, and to look for alternative solutions when the initial solution you’ve proposed causes issues you might not have considered.

Remember the story (and talk about it)

This might be the most important principle to keep in mind for effective collaboration between designers and developers.

Every project has a story behind it. There’s a reason the client is doing what they’re doing right now. There’s something motivating them, something forcing them into action, something that matters enough for them to be willing to make a change.

The sales guys usually know it. They have those conversations up front. They hear the stories, and they turn those stories into proposed solutions. Those solutions turn into scope agreements. Those scope agreements turn into task assignments. Those task assignments turn into individual to-do lists on someone’s day.

During that process, though, the actual story often gets lost. The developer at the end of that process who’s actually building the solution often has no idea why the project is being done in the first place.

That setup can work in some industries. If someone is building a hospital, the construction worker laying bricks doesn’t necessarily need to understand the whys and wherefores of it. He or she just needs to lay the bricks.

However, neither designers nor developers are equivalent to bricklayers. They’re not just “doing the work.” They’re making countless strategic decisions over the course of their work that can have a significant effect on the outcomes, and it’s important that they understand how those decisions might affect the project’s underlying story.

Some time ago, a client came to us deeply frustrated with their current website. It had been built using an off-the-shelf theme, and they were getting fed up with its limitations and clunkiness. They asked us to design and develop a new site completely from scratch. We assured them we could totally do this, and got started.

Unfortunately, by the time it made it through the game of Telephone all the way to the actual developer doing the work, that story was no longer anywhere to be found. Making what would otherwise be a very reasonable choice, the developer used an off-the-shelf starter theme as the foundation for the new site, and then heavily customized it to match the design.

Despite the heavy customization work, you can imagine the client’s response when they started looking into the code and realized what we’d done. It’s not just that they weren’t happy, it’s that we had entirely missed the point of the whole project. We wound up rebuilding the site completely from scratch…and let me tell you, it wasn’t a small project.

We learned a lot about team communication that day.

Every project has a story, and everyone involved in the project should understand that story, not just in the beginning but all the way through to the end. It should be discussed in project meetings, solutions should be evaluated against it, and new people coming into the project should be briefed on the story before they begin working.

Yes, it really can work

As I said in the beginning, there are few forces as formidable as designers and developers working together. I’ve seen collaborative teams accomplish remarkable amounts of high-quality work in amazingly short timeframes through clear and effective communication (and I’ve seen entire companies collapse from the lack of such communication).

It’s hard. Trust me. Real collaboration often goes against our basic human instincts, which means its a skill we have to intentionally prioritize and learn.

But when it works like it should, it’s truly a beautiful thing.