Oct 7, 2025
Interview Practice: Working with Difficult Collaborators
This is a blog series where I use common interview questions as prompts until I become a pro interviewer.
The question, sourced from a pre-interview assessment:
Describe a time you’ve worked with difficult customers, coworkers, or clients. How did you ensure the project was successful?
As a UI/UX designer, your job is to understand the needs of stakeholders and users and the constraints of product teams, and turn that into something that solves the right problem while checking the necessary boxes for all of those audiences. Like any job where you work closely with other people (read: any job), you’ll at some point be in a situation where you have to work with someone you find difficult.
Before I dig into how you do that, I want to challenge your perception of what a “difficult person” is..
What does a difficult person look like?
Maybe they’re not receptive to new ideas of feedback, they’re nitpicky or (in your opinion) focusing on the wrong things, or maybe they’re unresponsive or unengaged.
I think the most important (and sometimes most difficult) step you can take is figuring out why. With empathy being at the core of what we do, it’s in our best interest to flex those muscles and leverage them for better communication and collaboration.
I find the 5 Why’s exercise helpful here – but keep in mind, sometimes it’s as easy as just asking them.
Let’s use an example:
A key stakeholder isn’t responding to our requests for feedback, effectively blocking our project.
Why aren’t they responding? They said they’re too busy - they just don’t have time right now.
Why don’t they have time? This project isn’t a priority for them, they have more important things on their plate.
Why isn’t this a priority? They don’t really understand the value prop of the project - they don’t see how it benefits them.
Why don’t they understand? We didn’t get their buy-in early on, so we don’t have a clear picture of what success looks like to them or if we’re even solving their major pain point.
In real-life, this is what that has looked like for me:
In a past role, I joined a notoriously difficult product team as a sole designer. The team had a history of ignoring or arguing with design feedback, going to leadership instead of discussing disagreements directly with the designer on the team, and developing screens that were very difficult from the designs.
I was specifically selected for this role because the hiring manager believed that I would be good at compromising with the team to settle design debt and bring the product back in line with the design system.
When I talked to the previous designer to gain some context, they shared that, in their experience, the team wanted to hear more than one person agree with any piece of feedback before they would take it seriously.
When I talked to the team itself, they expressed frustration with changing design direction when their focus really needed to be on moving the product forward, not updating old designs.
It turned out, the team was acting on tight deadlines and weren’t given the context to understand where the design feedback was coming from or why, exactly, it was so important. They didn’t feel like they could trust that the past designer was aligned with the stakeholders’ goals, because they only ever saw the recommendations – not the research that led to them.
Both sides cared deeply about the quality of the product, the needs of users, and the priorities of stakeholders - but what we had was a communication problem.
Here’s what I did:
I invited key members of the product team to all of my stakeholder and user interviews, so they could see how I was interacting with our stakeholders and what kinds of questions I was asking.
Besides the high-level findings, I gave them access to all of my research - so they were free to dig in as deeply as they wanted to see where my conclusions were coming from.
At the end of our preliminary research, we developed and recorded the goals and priorities together, to ensure we were in agreement and were using the game guiding principles.
I checked in with in-progress designs as often as possible (sometimes daily) to get feedback early and often. In the end, this helped clear a lot of misconceptions before time had been sunk into designs that were moving in the wrong direction.
When issues arose, we brainstormed together so that the solutions we came up with had the technical constraints and the logic built-in. This helped ensure that the team was on board with any changes in direction and there were no surprises.
All of this sounds time-consuming, but not only did it help our initial project launch ahead of schedule, it created trust that served the rest of our time working together. That “difficult” team started reaching out directly with questions or to ask for design feedback, collaborating more deeply with design than ever before, and completing new development work at a higher fidelity and ahead of schedule.
By taking the time to work with this team and understand their perspective on past collaborations, I fostered an incredibly positive working relationship that I was genuinely excited about for the duration of my time with them.
There were a couple of takeaways from this experience that I’ll carry into all of my future collaborations, “difficult” or otherwise:
I’ll ask why, as many time as it takes, to understand the real perceptions and experiences of my collaborators.
I’ll seek to be genuine and to understand, rather than blame.
When I can, I will try to seek solutions together - I want to always give my teammates, clients, and customers the opportunity to buy-in on the solution we’re building.