Talking in Circles

No matter how many times you try to describe a complicated interface, there will be some people who just don’t get it. Not that they’re dumb, but the way you describe things and the way they visualize things might just not jive. I spent maybe an hour in a meeting yesterday talking in circles. What seemed so clear to me was quite obviously not clear to others, although they didn’t say so; no one likes to admit they don’t understand. Except me–for some reason I’ll freely admit I have no idea what’s going on (yesterday: “Does that make sense?” “…….um……nope, not at all”).

People have beat the drum of prototyping on the internet more then enough, so I don’t really need to add to the cacophony here. I just find it so fascinating how people can have such a hard time communicating visual things to each other. Me, in particular. I want to just photocopy my visual landscape or somehow Matrix-ize my mind into someone else’s mind. It’s frustrating to see something so clearly and not be able to adequately explain it. Particularly over the phone. Yes, I have had to do this. I generally have to step back and pretend I’m talking to a 5 year old, again, not because they’re dumb, but because I have a tendency to skip over important details that I just assume everyone knows.

What do they say about assumptions?

Assumptions are the ultimate budget-killer. The ultimate project tank-er. We assume other people’s working mental models are similar to our’s, and skip over the things we generally take for granted. I think this is where developers can really get tripped up. We know how things actually function, so when we talk about how something should work, we’re talking about how something should technically function. However, a clever design can hide how something actually works and give the user a UI that makes maps better to their mental model.

But this can result in meetings with non-developers going haywire. I find myself having to say “Well, this is how it will be programmed, but to the user, it won’t look like it”, and in my mind I’m thinking “and I shouldn’t have even brought this up because it won’t look like it to you either”. A saavy designer will get this, although they still might double check a few times, to make sure they get it. A non-saavy client? Forget it.

It’s the age old question: how much of the behind-the-scenes stuff do you tell people? Since I’ve been working at an agency the last year and a half, I haven’t had to deal directly with clients for the most part. Recently I took on some freelance work, and I found myself sending a very long email about a database migration. Unsurprisingly, she emailed back: “can we talk about this?” I was worried, I thought maybe I imported the data incorrectly, but no, I just overwhelmed her with technical details that she didn’t give two shits about.

At the same time, you want to make sure everyone is clear on the capabilities of the system, and there will always be questions about how something is set up that require going into the details. It’s a hard balance to strike, and something that changes on a client-by-client basis.

Someone should write this book Communication 101 for Web Developers: How to Convey Technical Concepts without Sounding Like as Asshole or Overwhelming People with Unnecessary Details. Get on it, internet.