I started my UX career at a huge corporation where designers were seen as more of a nuisance than an asset. I quickly took up the banner of the champion of our user’s needs and proudly went to battle each day to fight for those needs. I thought I was doing my job — and I was in some ways — but it left me exhausted and frustrated. I didn’t understand why it was so hard to get things done the “right” way for our users.

What I failed to grasp at the time was that the design isn’t the star of the show — but neither is the business side or the technical side. The most successful products balance all of these needs. I think Susan Rits puts it best when they say “the value is in the tension between us.” Only together will we create something excellent.

Gone is the age of designers creating in their gilded towers passing the design along, hoping for the best, and ultimately being disappointed with the outcome. “That’s now how I designed it…” doesn’t cut it anymore. When I started to create WITH my engineers and product managers I was able to make more progress than ever before.

No matter how intricate our prototypes are, whatever is in our Figma file isn’t going to impact any users. Only with collaboration between engineers and product folks will our vision become a reality. The end result will always be a compromise, but it can still be an excellent experience.

How do we ensure the built design is the best it can be?

Don’t fight, collaborate

Product teams are just that — teams. So collaborate and compromise. Define what is most important to the user (and I mean goals, not features) and push for those top items while trying to understand the perspectives of the other folks on your team.

Put yourself in their shoes

As UXers we are great at empathizing with our users. Practice using some of that empathy towards your own team. Engineers and product managers have valid goals and constraints that can conflict with our goals as user experience professionals. Product managers face pressure from the business to build quickly, cheaply, and efficiently. Engineers are balancing complexity, time to complete, performance, and other factors. Overall everyone wants to make great products, but product managers and engineers have to balance great experiences with the goals in their roles.

Talk to your team to understand their motivations and express your own. You’ll be surprised how much easier it is to collaborate when your PM goes from the ‘person who only wants to do the bare minimum for users’ to ‘my teammate Rachel who is under an enormous amount of pressure to meet a client commitment in 4 weeks.’

Speak their Language

Once you have a better sense your teammate’s goals you can frame your conversations more effectively. Reflect on these questions and use the answers to influence your team.

For Product Managers:

• In what ways will this design help meet our business goals?
• How much more satisfied will users be with this design than another option or what exists today?
• What user needs is this design addressing and how important are those needs?
• How can this design help us to save money as a company? (For example, reducing support calls)
• How will this solution differentiate our product from our competitors?

For Engineers:

• How will this design be efficient to build and maintain?
• What elements of this design are being reused from other existing projects (and thus easier to build)?
• How can this design help improve performance?

When showing a design solution pepper in answers to these questions before they are even asked. This shows you are hearing and respecting the other perspectives on your team. Speak the language of your teammates and help them to understand that everyone’s goals are not mutually exclusive.

Communicate clearly and without bias

Part of our job as designers and researchers is to communicate to the team the user implications of decisions. Use your information design skills to ensure the team understands the risks and rewards of choices, what competitors are doing, and the best practices of user experience design. Keep the tone neutral, factual, and research-based. It’s all about what is about what is best for your users and your company.

Do some compromises leave you worried about the user’s experience?

Maybe where the team has landed is not your ideal experience. Like I said, it isn’t always going to be exactly as we envisioned it. In this situation, I like to switch to something that takes the opinions out of it — data.

When I feel strongly that the direction is the wrong one, I will put together a usability test and put it in front of users. Create tasks and see what the success rate is for the approach the team is driving towards. Craft questions to provide you and your team with clarifying information. Sometimes this process puts me at ease and shows me my fears were unfounded. Sometimes my fears are confirmed and I then have data to bring back to the team about the exact risk we’re taking with the approach.

If the project is small and an infrequently used part of the system, I take a wait-and-see approach. I agree to get the design we’ve settled on into the world and then see what happens. Do we get an increase in calls to customer support? Are customers complaining? If we do post-launch usability testing, are users successful?

Take this as your sign to take the burden off of your shoulders

We are designers, not miracle workers. We can do our best to empathize with our team, collaborate, and provide data to influence decisions, but we can’t change everything. Some projects and organizations just don’t have the time, resources, or commitment for the user experience to be completed in the way we know will be best for users. At a certain point the decision is out of our hands. Rest easy knowing you did what you could, reflect on what you can do differently next time, and look forward to the next project.