Jargon

Once I was in a meeting with a pretty diverse group of people. A few of them were developers, but most — myself included — were not. We had spent an hour or so hashing out a plan for merging two large, complicated product databases into one consolidated, streamlined system. One of the developers had just said pim for what must have been the tenth time. Unfortunately for me, I had no idea what pim was. Otherwise, I was following the discussion just fine. But the pim mystery eventually became a problem. Later, when I suggested a particular next step, that same developer — who I’d already begun to suspect doubted our ability to do this job right — replied, “So, just how many pim systems have you worked with?”

Pim. Again.

So I went for it: “I don’t know that particular acronym. What do you mean by PIM?” It was an educated guess wrapped in a risky admission. The developer was not impressed. “Product_inventory_management.” The emphasis, I assume, was for his boss — the decision maker — not me, and so that it would be abundantly clear that these guys (us) were out of their league. Of course, now that I knew what he meant by PIM, it was no big deal. We’ve worked with plenty of those systems. They’ve all been different. We’ve always just called them product inventory systems. Of course, I could have Googled “PIM” at some point and saved myself the possible embarrassment, but you know what? I wasn’t embarrassed. Why should I have to use a robot to translate a conversation I’m having right now with another human being?

And another thing: Just because you don’t speak the language doesn’t mean you don’t know anything. Judging someone’s intelligence by their ability to communicate with you on your terms is an unfair — but sadly very common — practice. We do it to each other all the time. In fact, did you know that language barriers represent one of the most common biases in intelligence testing?

On a smaller scale, any time you assume someone will know what you are talking about, you run the risk of being wrong. Whose job is it to fix that?

So, jargon. Unless you speak it, it’s a language barrier. And by its very definition, very few people speak jargon. One should never invent it, speak it, or be intimidated by it.

But not all jargon is bad, right? After all, it wouldn’t exist if it wasn’t efficient and useful. Perhaps. But it’s only efficient if everyone knows what it means. Stick a bunch of developers from the industrial, manufacturing, or retail industries in a room and most of them will probably know what PIM means. But add some marketing people or some designers to the mix and they might as well be speaking in code. I mean, technically, they are speaking in code. That’s exactly what jargon is!

If you’re designing something that you are sure is for a closed audience — one you know already speaks “the language” — than jargon is permissible. But if you’re designing something for an audience that you first must educate — in order to best describe a solution you’re offering, perhaps — than jargon will only hurt your chances of doing so successfully. That’s why you’ll never see a (good) website with anything much more complicated than “About Us,” or “What We Do,” or “Blog” in its main navigation. Each of those items are like signs, which have a simple job of directing users from one place to another without taking so long that those in need of direction start thinking about it too much.

I know it seems obvious. That’s because it is. But if there’s one thing I’ve learned from years of helping people design systems for communication, most obvious things aren’t obvious at the most convenient times! So before you commit to any language, run it by someone else — ideally someone as close to the sort of person with whom you are trying to communicate. If they don’t get it, let it go.

P.S. Taking a “don’t make me think” approach to interactive design is not about encouraging or capitulating to intellectual laziness. It is certainly not the user’s prerogative to think less. It’s really not a matter of quantity, so much as it’s a matter of time. It is the user’s prerogative (and habit) to think quickly, which means we cannot assume a user will slow down and process something that lies beneath layers of meaning. Instead, we have to assume that a user will make quick assessments, quick deductions, and quick decisions.