Illustrations by Trevor Fraley for this article.

If you're a designer who wants to collaborate well: learn to include others in your process early and often, share and gain insights into how each side works, and focus on removing friction from your partnerships.

Easier said than done, of course. But the reality is that just a little work can go a long way into turning even the most fragile of partnerships into highly collaborative teams. This is good news for individuals and businesses alike: cross-functional teams who work closely together outperform the now outdated factory floor model of doing business in independent and often disconnected solos (or cubicles).

Companies have learned that whenever one person conducts their work in private before passing it off to the next person down the line, opportunities for innovation and higher-caliber work are missed. Producer and artist Julia Kafanskiy put it simply during her talk at the 2017 99u conference:

"Interdisciplinary collaboration produces more interesting and innovative ideas.”

So why do many designers regularly ask how they might convince engineering partners that design matters? Why do product managers and company executives often overlook the process of design? How is it that in any gathering of designers there are stories of struggles related to quality production? How many times have you encountered a situation where an engineer will often, blatantly, refuse to implement something you've created (typically with the excuse of: "that's just too difficult to build”)?

I've heard these types of issues raised by designers across many different industries and varying levels of experience. Everyone from university grads on their first job, to a number of my peers at Facebook, veterans of product design. Close collaboration can be difficult—particularly between design and engineering.

But bridging the gap between design and other disciplines is certainly not impossible. Like all good things: it just takes work.

Involve your partners early and often

Because design typically takes place earlier in the product development process than engineering, it's important to pull engineering and quality assurance partners into ideation at the beginning of your project.

If you can schedule half an hour or more of time for generating ideas alongside product managers, researchers, engineering partners, and anyone else, at the kickoff of a project, you give them a peek into your thought process and get them invested early on. As a result: when it comes time to execute the final designs, engineering will have already mostly signed off, because they were involved in the process.

Additionally, by involving cross-functional partners early on, you expose them to the process of design thinking. This exposure can dramatically help future conversations revolve around the rationale logic of design, as engineers will better understand your role is not to make arbitrary aesthetic decisions or rely on personal preferences, but to use actual, rational logic to make informed, intentional, design decisions.

Initial attempts at partnering during ideation phases can sometimes be tricky, but focusing on alignment of objectives and discussing how the team will measure success, means the collaborative effort is constructive, not combative.

Over time, as trust builds, the initial collaboration between cross-functional should come easier, with more trust and clearer expectations of each person's function within the team.

Invest in learning about non-design skills

Similar to getting engineering and product managers invested and involved early on, design too should get invested in other, non-design skills.

Every designer should find time to sync with their engineers, researchers, content strategists, and product mangers, to talk about their work and process. As a designer, the more you understand about your team's engineering process and toolset—and vice versa—the easier collaboration will be.

Really get to know how your non-design partners work. I use regular, weekly 1-on-1 meetings to talk not only about projects, but process with my team mates.

What technology do they use to do their job? What does their "stack” consists of, and which tools do they use on a regular basis? What constraints do they often run up against, and how are they measured for success? What do they wish were easier? What do they care most about on the job? What does success look like for them on each project?

Investing in learning about these things allows you to not only build a better rapport, but also help to better define your own constraints.

For example: if you know the engineers are working in a certain technology with limited capabilities—while on a tight deadline—you can use that knowledge to propose a simpler solution, or segment solutions to be built over an extended period of time.

You won't be able to improve your own process until you learn about your partner's. Of course: you don't have to have weekly meetings like I do to do this. A monthly conversation or even after-hour meet ups can be good avenues for investing in learning about others too.

Build more rigorous design systems

Another way to ensure design and non-design are collaborating well is to take out as much friction of that process as possible.

One way to do this is by working alongside engineers to build out rigorous components as part of a larger design system.

Having a set pattern for common things (like animations, transitions, interactions across the product, or common visual patterns) and setting clear expectations means using those as standard in your work becomes a norm, for both design and engineering. And because the components will be part of a larger system, you save both yourself and engineering time in investing in them upfront.

So when you approach your project manager or engineering partner with a new feature, if part of the work has already been completed in the design system you've made their job (and yours) that much easier.

The trick is getting anyone to invest in the system up-front. At Facebook we do this in a myriad of ways, everything from a series of monthly miniature "lockdowns” or sprints, to brief, after-hours sessions where design and engineering come together to develop the system.

But selling the idea as a means of speeding up both design and engineering is typically enough to convince your cross-functional partners to invest at least some time into it. After a while the small investments in a design system add up.

‍