Knowing the words is half the battle
February 3, 2016
February 3, 2016
One of my favorite career stories is this one from Michael Beirut:
I designed little magazines when I was in the third and fourth grades, and I made logos for my friends’ bands when I was in the seventh grade. I could do hand lettering, and if someone wanted an animal in the logo, I could do that; if someone needed a poster for the school play, I could do that, too.
All along, I had no idea that what I was doing was called graphic design. I lived in the middle of nowhere at a time when no one knew anything about something like graphic design.
By accident, I happened to find a book in my high school library…it was called Aim for a Job in Graphic Design/Art. I opened the book up, and it was like receiving an instruction manual for my future career: it was all right there. I was about 15 at the time, and I thought, “This is what I want to do.”
This bears repeating: one of the world’s preeminent graphic designers **didn’t know graphic design was a thing **— let alone a job you could get paid for — until high school.
He knew what the idea of graphic design was, and he even knew how to do it. But he didn’t know what to call it.
Perhaps the biggest obstacle to gaining skills in a given domain is knowing the right words. Being a beginner is intimidating because you don’t speak the same language as experts, who have often forgotten what it’s like to be a beginner.
If you’ve ever had to talk to a car mechanic, you know how it feels. In the immortal words of George Costanza:
Of course [car mechanics] are trying to screw you! They can make up anything, and nobody knows! “Why, you need a new Johnson Rod in here.” Ohh…a Johnson Rod…Yeah, well, better put one of those on!
Here’s another example. Millions of people use iPhones, but they don’t know the official names for all the interface widgets and the underlying stuff that makes them work. It doesn’t affect their ability to use an iPhone, because the iPhone is well-designed.
I went to Twitter, then hit the thing that said “Notifications”, and a new screen came in, then I saw some messages, and it stopped working.
By contrast, an iOS developer knows the domain words, so they can be more precise:
The customer opened the Twitter app, then selected the Notifications Tab in the Tab Bar. The Notifications Table View rendered for a moment but then the app crashed. The issue might be the Notifications View Controller or some malformed data in one of the notifications.
In product design, this is related to User Experience (UX). Part of a UX designer’s job is making sure a product’s internal language is either hidden away, or translated into common words that users can understand and interact with. If you don’t do this, you might end up with this kind of thing.
A customer support rep’s job is the opposite: they translate customer-speak into domain words so a specific problem can be resolved — especially in the case of a bug report that gets passed along to developers.
Here’s one last example. I’ve been an obsessive music fan for most of my life, but I’ve never formally studied it, so I don’t know the terminology. Check out this video of Jeremy Leaird-Koch building an electronic song from scratch on an OP-1. (Jump to 1:25 or so.) Be sure to watch the subtitles.
If you make it through the whole video, you’ll see a ton of expert language:
I’ve put in 30+ years of music listening, and these phrases might as well be in a foreign tongue.
So it’s not enough to have exposure to the outer surface of a domain. If you want to level up your understanding, you have to be willing to feel ignorant for a while and study it in depth, until you find your sea legs and pick up a handful of those all-important words. There’s no magic to it. This willingness, and a lot of practice, is all that separates the experts from the beginners.
Once you’ve learned a bit of lingo, you’ll find that the words help you ask questions. The questions help you learn how things interact. When you know how things interact, you can start understanding the system as a whole. And pretty soon, you’re an expert too.
As experts who’ve put in the time, then, how can we make things more approachable for beginners? Wouldn’t it be nice if we could simply eliminate all jargon and special words? Then we’d have no problem, right?
Well, then we’d have a new problem: we’d have no way to talk to each other! Any sufficiently complex system needs names for its component parts— otherwise there’s no way to talk in detail about the system. So eliminating internal complexity isn’t always possible or even desirable. Still, there are a few things we can do to help.
For example, if you’re a programmer modeling a message sent by a client, call it ClientMessage instead of ExternalActorSubmissionContent.
In Basecamp 3, we called group chats Campfires and direct messages Pings. They’re still abstractions that users have to learn, but at least they’re helpful names—a little descriptive and a little less intimidating.
We did this recently by noticing our customers called Basecamp projects “Basecamps.” They’d say, “Oh, I made a Basecamp for that.” So we ran with it and called Basecamps Basecamps instead of Projects.
Trying to be too simple or succinct is usually worse than being clear and verbose. This is why people are confused about what food is “healthy.” Even though healthy is a simple word, it’s an unclear way to define food.
If you’re in the privileged position of being an expert at something, don’t forget what it felt like to be a beginner. Let those battle scars inform how you communicate, and choose your words with intention. If you need a reminder of how it feels to be a newbie, just pick yourself up an OP-1 and let me know how that ambient poly lead turns out!
This was originally posted on Signal vs. Noise.
Want to get new posts by email?
Subscribe to my newsletter: