The products and services we create are becoming more and more complex, getting “smarter,” more dynamic, and more impactful. Designing and developing the things that users appreciate and turn to over and over is also more challenging. This evolving landscape means that a fruitful, productive relationship between developers and designers is more important than ever.

And you and your teammate are at odds with each other. This is not good.

Throughout my career, I’ve been blessed to have had experiences working with developers where the work and the process were joyful. I’ve also worked in teams where that relationship wasn’t as productive. For my recent book, Mastering Collaboration, I interviewed dozens of people about what works in their collaborative teams, and how to get things on track and keep them there. Here are some insights and advice specifically for developers and designers who are looking to make better stuff, more easily.

It’s complicated: What gets in the way of getting along?

Our relationship with collaboration is complicated. We say we value working in cross-functional teams, with diverse perspectives. We seem to understand that when we work through productive struggles to get to a solution with people we trust and respect — we are working at our highest purpose.

But the business environment is not a fertile environment for collaboration. Teams get goaled on metrics like “bug count” or “time to release” over other harder-to-measure indicators of quality for customers. Time envelopes get compressed. Communication with management is tricky. This shows up in the final product as features that aren’t complete enough to provide value and as struggles to keep up with competitors. As teams focus on metrics, they lose sight of the impact their work has and can feel undervalued. The technical and UX debt builds up, and team morale takes a dive.

This corporate environment is the air you breathe. However, with a little effort you can carve out a different space for yourselves, reap the benefits, and deliver results. And, over time, with every great partnership you establish, you might just change it after all.

What follows are three of the major ways that you can create a space for designer/developer collaboration that clears the air of corporate pressures and lets us all focus on the good work. In the end, no one ever needs to know you approached things differently. They’ll just keep asking you to show them how you did it at all.

Establish a clear starting point

As I was researching Mastering Collaboration, I spoke to many different types of teams. And the one thing that struggling designer/developer teams had in common was that they lacked a clear starting point for their work. For some, time seemed better spent “making” things than co-creating clear objectives together. For others, it was a lack of vocabulary to use together. Clear objectives help you make smart decisions as a team and avoid ego battles.

At the opposite end of the spectrum are those businesses who are great at listing metrics that they can easily measure and adopting those as objectives. This is not helpful because they often aren’t great metrics (see bug levels or team velocity) that say almost nothing about what the team should achieve. In fact, metrics that specifically target team performance quantitatively always seem to lead directly to team strife since design inevitably becomes seen as “slowing things down” with no expressed value.

So what can I do?

Ken Norton and Braden Kowitz, both formerly of Google, have a lot to say about setting effective objectives. One of the most relevant here is the idea that they aren’t set at a functional area. By creating an objective that describes tangible benefits to the user, you create more effective and useful rules that govern how you work together and succeed. This model can be a good starting point to create your objective:

Make objectives simple statements about how the end user is benefitted. Use business metrics as your KPIs. And now, go forth and deliver value.

As a designer:

Put it in user-centred terms

Create a view of the problem and opportunity in user-centred terms. For example, the company might have a view of the features you design as a way to increase adoption, or decrease the time it takes to process inventory. Don’t fight these statements of what the business needs, but marry them with a simple view of how life for a user might be such as, “stronger confidence in the product” or “getting packages faster.” Be sure to bring data (or hypotheses) about why your design solution is good, what you don’t yet know, and be open to discussing both.

Respect the constraints

Or at least don’t dismiss them off-hand. I’ve definitely run my share of workshops urging us all to “let go of constraints,” but it’s good to remember that for most devs their real focus is on developing a system and dealing with those pesky constraints.

Be clear about big picture vs. details

Be clear when you are talking and speaking at an exploratory or conceptual level, versus specific design details. Devs may see an ambitious design, and all they can see is how far they are from it.

As a developer:

Adopt a user-centred view

Internalise an understanding of what users need, and use this to evaluate success at the team level. When you find yourself stuck on why something won’t work, it can be useful to back yourself and the designer back up to the why behind the idea. Push for user stories that provide the “so that I can…” part of the rationale.

Test the assumptions

Keep track of the (assumed) limits, but don’t become too tied to them: performance, scale, existing infrastructure are all important parts of the problem, but aren’t generally good metrics of success. Many of them are assumed, so see if you can periodically challenge them. For example, it may seem a fact of life that you have to work with a legacy system, when in fact, if you could make a clear argument for the value of doing it differently, you might change the constraint.

As a team:

Commit to your “first team”

Whatever the overall environment, commit to your partnership as the way to get the best work done and get outcomes. Don’t let your alliances fall back to functional differences; look to keep yourselves aligned and united to deliver value, not keep each other busy.

Co-create your objective

The company’s KPIs will be what they are, but as a team you should decide what success looks like in dimensions that help you make good decisions; don’t just “juke the stats” to look good on paper. Establish a clear objective as you begin working together, and revisit it regularly: either when you take on a new piece of work, or you learn something new about what you are building. At a minimum, check in on it every few sprints to make sure it’s still understood and relevant.

Explore together, decide together

In my past, when I had a strong relationship with my technical partners, the best part of the day was spent exploring solutions together. Creating products and services is an inherently creative endeavour, and it’s often what attracts us all to the field – the challenge of solving a problem well, from the details of a UI widget to the architecture of an entire system. But, at times, we find ourselves in a world in which there never seems to be time and space to explore creative solutions together.

When teams become locked into a cycle of delivering something/anything, without having spent any time exploring solutions, life at work suddenly becomes very litigious. When this happens, the end result is a team that is fixated on overly detailed specifications that keep solutions in the safe, known, and trusted realm. Each person colours juuuust enough within the lines to be safe and avoid flare ups. Or, in the worst case, the team ships something embarrassing because they didn’t test out ideas with each other to find their blind spots.

I once watched a JIRA ticket go through a sprint attracting comments like it was a viral tweet. At one point the debate was about a line of text that didn’t have a question mark on it when similar other lines did. I watched people write a short story back and forth about the issue, because no one felt empowered to make a guess about what should happen. When the team doesn’t explore ideas together, then it becomes a game of chasing the “perfect hand-off” of information and responsibility that serves no one.

So what can I do?

If you notice that the design and dev team isn’t talking at least once a sprint about several different solutions to a problem, weighing up their pros and cons, you might have a problem. This isn’t about adding yet another sprint ceremony or meeting, but when you do come together to review work and decide what to pursue, use the time wisely.

As a developer:

Create “idea time”

Set aside some (brief) amount of time to just kick around ideas with your team. This could be as informal as grabbing a coffee, or a 30- to 60-minute window with some regularity. Do exploration work like this in a “sprint ahead” to give yourself or other devs a chance every so often to escape the cadence and think bigger/more long term. I used to plan and budget for at least one sprint a quarter like this, which pays lots of dividends for a small investment.

Ask how the idea helps the user

You understand what your users want. See if you both can get at the motivations for design ideas in those terms if they aren’t using them. And rather than meet poorly justified design with rejection, ask for a clearer argument about why the proposal is a good one, and what assumptions are being made. You will coach designers to tap back into their user research and show up more prepared in the future, and you will show yourself as a helpful critic.

Don’t use edge cases as cudgels

Instead, use them as prompts to challenge the design. “What if there are many ____?” or “What happens in 12 months?” are useful critique questions to have at the ready. Designers are focused on the 80 percent use cases most of the time. It’s helpful to have someone test the limits of ideas, when it’s done in a spirit of trust, not competitiveness.

As a designer:

Give up the monopoly on “design”

If you find yourself getting upset when other people develop competitive ideas to your own, take a moment to check yourself. When you insist that only designers “design”, you are signaling your mistrust in a developer’s ability to offer ideas, or find creative ways to deliver a capability. Engage the developers in an exploration of alternative solutions that might work better with underlying systems or other constraints and seek to make the alternatives work well for users rather than insisting on your original solution over and over.

Don’t just feed the machine

A dynamic can creep into designer / developer teams, where there’s pressure to “keep the engineers” busy, focused on shipping code even when the system and problem aren’t fully understood. In these situations, resist the pull of making “anything” just to keep shipping. This leads to UX debt, and keeps the team out of sync. If you aren’t in a spot to definitively develop a feature, it might be time to work through “sprint ahead” designs and help the team understand the big picture. There’s often infrastructure or tech debt work that this can unearth that needs tending to for a sprint while the design comes together more fully.

As a team:

Pair up

Just as in Pair Programming, you can use a Pair Design approach to explore solutions and work through rationale together. This doesn’t mean you have to be joined at the hip every day, but it will give your time together, exploring ideas and making decisions, some structure.

Tell a clear story

Developers and designers can become so focused on making the work, they don’t spend enough time and energy on thinking about how to communicate with those outside of their close circle. When stakeholders are reviewing progress without any framing about why a solution is good, or why it’s been pursued, managers become risk-averse, cost-conscious, and defensive. And in turn, developers and designers become focused on delivering the safest, most boring, copycat thing imaginable, every time.

Clear objectives help stakeholders make better decisions and give us better feedback. If you don’t give them the right info, stakeholders are just waiting to “know it, when they see it.” And you and your team’s solutions are decided by hierarchy, whimsy, or a mix of the two. Designers and developers become locked in a mutual guessing game about what will pass muster on any given day. This shows up in product teams as whiplash, and the features that are prioritised constantly shift.

When teams don’t communicate well, they also fall back to communicating along functional lines, rather than being a unit. I’ve seen designers and developers each share “their” work with leaders with all kinds of inconsistencies and differences, leaving their stakeholders lost about what progress was made. The team morale takes a hit because stakeholders won’t buy into their direction.

So what can I do?

When I’ve coached or been a part of teams who work well together, I’ve noticed and adopted a way of presenting work to stakeholders that looks something like this:

“Last time we got together, we showed you the ‘create a new thing’ ability. Today we’ll show you how Jane Doe completed the thing quickly. She did it correctly with confidence. This was tricky because we weren’t sure how she’d best be able to supply information and how to best catch and fix any potential mistakes. We looked at a few ways to do this… and it seems like using speech-to-text here makes sense. You can expect to hear what users thought about it in our next session.”

By teeing up the work well, from the core objective, to the limitations, to past progress, to the current struggle, you help leaders give more useful, actionable feedback. Otherwise, you’re asking the decision-makers and leaders for their best guess, and destroying their confidence in you.

As a developer:

Show what happened

Always have a build available. Don’t have designers demo the work based on solely on design. This tends to get teams out of sync, as designers show and revise work that is a few cycles out in front of development, and devs don’t get critical feedback and attention on what exists as well.

Argue for the overall health of the system

No one else will care about tech debt or other fundamental issues. Ground your work in arguments about what meets objectives and what investment is needed to make it happen, rather than trying to show how you cut corners to meet arbitrary metrics.

As a designer:

Keep a clear picture of the user-centred objective visible

Start every presentation with a clear statement of what you are enabling for customers. Ground stakeholders in this every time you engage them, and don’t just assume that they know it.

Don’t “take an order” for design from stakeholders

When stakeholders respond to work by offering a specific alternative, don’t assume that that is an explicit order you must act on. Try to understand the intention behind the suggestion, and what assumption it is making that can be tested. If an idea has decent rationale, bring it to users and bring back data from users about the idea once you have it, rather than try to argue the point on principle.

As a team:

Tell the story

Don’t rely on people to remember. Previously on lost/today’s problem/how we got here/what we did/explored/what we are doing as a consequence/what we hope to see next time.

Do it together

Don’t fall into the trap of communicating your functional progress separately. Take 15 to 30 minutes to prepare what you want your story to be, and follow the template above consistently to watch your stakeholders fall in line.

In conclusion: Here’s to “better together”

Learning to overcome the challenges for a strong designer/developer team will take some work, but in the end, it may take less energy than is being spent today. It takes a commitment to create your own environment that the team operates in, where objectives are clearly stated, in terms of benefit to the user. It requires making pockets of time to explore solutions together, not just optimise a hand-off. And it helps if you communicate the work being done in a way that helps leaders give more actionable feedback, and make informed decisions.

Building a strong designer/developer relationship makes it all worthwhile to improve the quality of communication, enable more creative solutions, and reduce the risk of embarrassing missteps down the road.