I was sitting at home waiting for an A/C repairman when my phone rang. The dispatcher said: “Our tech called. There’s no answer at your front door.”
I live on a Court. The adjacent street is a Drive with the same name, and the house numbers overlap. This isn’t the first time someone has ended up at the wrong address. What irritated me wasn’t the mistake. It was the tone. She said it like I wasn’t home, like I’d stood her tech up for a date.
I told her he was at the wrong house. Only then did she ask me to verify my address. Once she realized her office had left the “Court” off the work order, she became a lot more pleasant.
Here’s what that interaction reminded me about working as a UX designer.
Pay attention to details, not just information
The dispatcher wrote down an address. She just didn’t write down all of it. She had information, but she didn’t have a complete picture, and she didn’t notice the difference.
As designers, we get a constant stream of requirements, requests, and constraints thrown at us. It’s easy to listen and take things at face value. The better move is to listen and analyze: Does this make sense? Is something missing? Does this conflict with something else I already know?
The time you spend reviewing and questioning information on the front end saves you from rework and wrong turns later. A missing detail that seems minor on day one can become a significant problem by day ten.
Ask questions without putting people on the defensive
If the dispatcher had said “Can I verify your address? Our tech is having trouble finding your house,” I would have been helpful immediately. Instead, I felt accused of something, so I got defensive.
This happens on design teams constantly.
Getting stakeholders to sit down and answer your questions is already hard. When your questions feel like an interrogation, you’re making it harder than it has to be. The goal isn’t to expose a gap in someone’s thinking; it’s to fill the gap together.
When you notice something missing or unclear in a set of requirements, try a different approach: “I probably missed something, but can you help me understand this part?” It puts the uncertainty on you instead of on your stakeholder. You’ll get more useful answers, and you’ll be a lot easier to work with.
Document the decisions, not just the designs
When the tech finally arrived, I recognized him. He’d been to my house on a different service call a few weeks earlier. He didn’t remember me. Fair enough: he visits a lot of houses. But it still stung a little.
As designers, we do the same thing to our stakeholders when we fail to document our design rationale.
Recording what you decided is not enough. Record why you decided it: what options were on the table, what tradeoffs you considered, what you ruled out and why. When you come back to a project six months later, or when a new designer picks up where you left off, you won’t spend hours rehashing discussions that were already settled. Your stakeholders won’t watch the same rejected ideas come back around.
Good design notes aren’t a record of outputs. They’re a record of thinking.
We all have strong opinions about customer service when we’re the customer. It’s worth remembering that our stakeholders are customers too, and the way we ask questions, gather information, and communicate our decisions shapes whether they trust us with the work.
If you’re building a research or design practice and want to think through how your team is working with stakeholders, let’s talk: cal.com/mattwallens