Michal Charemza

I've been fortunate to work on projects where there is often a direct (or at least short) route between myself and the users of products I've worked on. These are the sorts of questions I ask myself when communicating with them.

Am I answering their question?

I might suspect that they're not asking a question where the answer will ultimately help them (an XY problem), but I can't be sure. In most cases I do really try to answer their question.

Do I understand what they're trying to do?

Even if I answer a question, understanding the context and what they're trying to do can lead to much better help. If I don't think I understand the context enough, I ask them for more details.

Am I explaining why I need the answer to a question?

I think it can be a bit frustrating to be asked to do things without understanding why. For example, if I ask for a screenshot, it's not because I don't believe the user, it's because there can be subtle bits of information along with the error message that explains what the problem is. "Oh it's that sort of 403. Right... I think I know what's up."

Can I offer alternatives, even imperfect ones?

There are often just so many alternatives that might help a user. I often try to think of the closest thing to what the user is asking for, and suggest that. (And if it's perhaps a ridiculous suggestion, I state that I'm aware it is!)

Have I asked my collegues if there is a better way?

There are always things I don't know, even about systems I've worked on for a while. A quick message to collegues is often helpful: for the user since it might result in a solution to their immediate problem, but it's also helpful for the team, since it communicates what users are struggling with, and what parts of the system might need some attention.

Am I acknowledging pain points?

You don't need to go overboard with this, but just a tiny bit of empathy goes so far. I think it can even be efficient as well - it can serve as a very clear statement that you understand what the user is trying to do and why. Then the conversation will probably move on to working around or fixing whatever the pain point is.

Am I giving an appropriate amount of technical detail?

This is a tricky one - I don't want to bore users with too much detail, or for them to think "why are you telling me this? Just fix my problem!", but also feels a bit odd to not communicate anything at all. I think in general it's helpful to give some detail. Knowing, even roughly, what the problems/limitations are can help users come up with their own workarounds.

Am I being realistic in promises?

Saying no can be hard, but it's usually so much better to be up front about what's realistic. In so many situations people are happy to plan given realistic information.

Am I over-apologising?

Apologising is tricky one to get right, and I don't think I'm quite there yet. It's probably extremely culture and situation-dependant, but so far I think I try to keep apologising to a minimum. In so many cases it just doesn't really help. Instead, I acknowledge pain points, and try to get a solution to the user's problem.

I think I might even imagine I'm talking to Marla Singer from Fight Club. She's gives the impression that she's been apolgoised to a lot, that apologies have no value to her, and she just wants to move the conversation past them:

Yeah, you're sorry, I'm sorry, everybody's sorry

Marla Singer, Fight Club

Have I checked what I'm suggesting works?

I try to check what I'm telling users, even if I'm confident about it. Or if I can't for some reason, I say I can't. Quite a few times I have been so close to hitting that "Send" button, but I decide to paranoia check X, and I realise I was about to be wrong.

How would I feel if I read/heard this if I were them?

This is easier to to with written communication, but I think worth just putting yourself in their shoes for a moment. It might be worth tweaking the message a bit (or asking yourself more of the questions above!)