Do you understand your customer? Subtle word choices lead us into a lot of trouble

If we drag the wrong words with us, we’ll fail to communicate. It's the difference between a failed project and a delighted customer. Avoid ambiguity and make your actual outcome match expectations.

Photo by Ayo Ogunseinde on Unsplash

We don’t talk about language enough. Specifically, the language we use with customers. Let me illustrate:

Customer: Just to make sure we’re saying the same thing — As soon as a customer’s account is funded, they can use it for purchases with any merchant right?

Engineer: Uh, right. Once their account is set up. Let me explain. The first step is for a user to set up their account. They do that on the web portal. They enter their name, etcetera, hit submit, and the system will validate the account — check things like the name and email have the right format, things like that. Then it sends an opt-in email and they click the URL in the email before their account is activated. Then they can login and use their account…

Customer: Wait, wait, so any time a customer applies for a new account, they have to fill in their profile again, and then they get an email — and do what?

Engineer: We have to send the email as part of our account verification, it’s a security check. There’s a URL in the email they can click that proves it’s actually their email.

Customer: But… we already have their profile, why would they have to do all of this again?

Engineer: It’s only a first time validation check, after that they have their account and can login.

Customer: Wait, you said every time the customer applies for a new account they have to do this.

Engineer: Right, for any first time user setting up a brand new account. After that, they can login from the portal any time…

Customer: This isn’t making any sense. It’s not what we’ve been talking about. After a customer is in the system, we should never make them put in any information we already have. There’s no need to ask them for their name or their email, we already have that.

Engineer: Uh, no, if they’re signing up we have set up their user account…

That’s a real conversation, reproduced as best I could manage from memory.

Part of the difficulty here is obvious: Two people coming at a problem from different sides, using the same words to communicate different meanings. But there’s a bigger context. In this case I’m relaying a conversation where each person isn’t hearing the other and frustration is growing. In this case, it’s pretty obvious. What about when the problem isn’t so easy to discern?

Let’s dig a little deeper.

In the story above, we have a customer using the word “account” to mean a loan security — that is, a bank loan account, with a unique number, that has been funded. The engineer in the conversation is using the same word, “account,” to mean a bank customer’s login credentials.

If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.

Anytime you'd like to read more, you can upgrade to a paid subscription.

What’s a word mean?

We have one person using “finance talk” and another using “security talk,” and these vocabularies give words different meanings. As long as they keep using the same words to mean different things, there will be confusion.

But this is not just about different vocabularies and synonyms. There are plenty of words with multiple meanings that can lead to confusion, but even more subtle and insidious is context. Not only can words have multiple meanings, those meanings change depending on the context in which we use them. There is a time and place where “account” very clearly and unambiguously means “a loan account.” There are other times when it means “login credentials.” And more! There are also clear, unambiguous settings in which “account” will mean:

1. A securities trading account.

2. A cash management or deposit account.

3. Your bill at a hospital.

4. A merchant or partner transaction ledger.

5. A customer account, differentiated from an administrative account.

6. An administrative account.

7. Any credential that lets you access a system, in general.

In fact, according to Merriam Webster, there are 372 different synonyms and antonyms for the word “account.”

A common mistake when we cross boundaries

Working in technology, we frequently create systems and processes that cross boundaries — finding ourselves in a different context, where words have new meanings. Sometimes, we have to figure out how to blend several contexts.

In our example, we have to move from a context where “account” clearly means a loan account, into another context. If we drag the wrong words with us, we’ll fail to communicate.

Dealing with this complexity can be confusing. Very confusing, not only to the engineer crossing those boundaries but also to our customer — especially if we don’t make those transitions cleanly.

There are a few litmus tests you can ask yourself to see if you could be heading for this kind of confusion:

• Can you describe the business logic in your system to a non-programmer, your customer, who understands how the business works?

• Are you able to do it using terms your customer understands?

• Can you avoid technical jargon, references to code, design patterns, and “engineering speak?”

• When you describe how the system will work (using only business terminology), can your customer spot potential problems in the business logic?

If you find yourself pausing and wondering about any of these, you’re probably in dangerous territory. By that I mean, the potential for subtle miscommunication definitely exists. And where there is subtle miscommunication, you can run into a lot of trouble.

Different contexts = different meaning

Recognizing that crossing boundaries leads to confusion is step number one. Think about all those different ways of using the word “account.” Am I using my loan account to pay for a new purchase? Or do I want to see what my checking account balance is? Maybe I want to sell some stock in my trading account. Creating software is a multi-domain exercise in which context constantly changes.

As we move from one context to another, we’ll talk with different people who have different jobs. They think about and talk about their work using words in different ways versus people in other contexts.

We need a system that lets us communicate back-and-forth with precision. We need a way to avoid ambiguity so we can be sure our intended outcome matches the realized outcome.

Don’t mire the customer in technical weeds

Recognize that technical details don’t matter to our customer and product owner and, more so, that technical details lead to confusion. What actually matters is the business process.

In other words, we need to focus entirely on how people go about their business. The day-to-day activities of people, using the system. This is what matters to our customer, and it’s how they think about and imagine the finished product. In the story above, we’re building a product where customers can apply for short-term loans, using those loans to pay for merchant purchases. From our customer’s perspective, how we achieve that doesn’t really matter — so long as business processes and controls are followed correctly. From the bank customer’s perspective, they care even less. They just want to pay for that Peloton bike they’ve been dreaming about and get on with their day.

Bringing technology into these discussions creates an impedance mismatch, a glitch in the conversation. That mismatch means the listener has to adjust their perspective. They’re forced to replace meanings of words they use day-to-day with new meanings. Learn new technical terms they don’t really care about (and probably won’t remember). Translating, constantly, when talking with an engineer… and that is a path to failed communication and unhappy customers.

Too often, I’ve seen engineers make the customer do the heavy lifting in a conversation, expecting them to learn complicated and confusing technical details. Customers don’t have the requisite technical background so that usually leads to problems.

And that’s the root of the problem — establishing a shared, common way of talking about a complicated product. A product that isn’t physicalized. We aren’t building something solid you can draw out in the sand, touch, feel and get “hands on.”

Instead, we have to talk about intended outcomes, translate those into designs and specifications, then implementation, and ultimately arrive at our realized outcome. Each one of these steps offers potential miscommunication, requiring translation of artifacts into something new, something more complex — hopefully accurate complexity, but how can it be accurate if we aren’t using the right words?

All of that happens in an intangible, intellectual space where each person imagines the solution. Without really good discipline around communication and language, everyone is free to imagine a different outcome. That seed of miscommunication means they get an outcome that’s different from what they expected.

Unintended consequences

Creating real understanding between people is challenging. Using the right vernacular is like adding oil to the mechanism of communication. But using the wrong vernacular is like throwing sand into the machine.

Without the right tools, we create ambiguity in our conversations, our designs, even our implementation. It’s not hard to see how misunderstandings can creep into conversation, then artifacts, then the product itself. It’s the root cause of a lot of mistakes in many projects:

1. Misunderstandings about form, fit, and function lead to misalignment between team members and stakeholders.

2. Carelessly used words turn into design flaws or shortcomings.

3. Technical errors are implemented in code, leading to a higher cost to correct when designs are revisited.

4. Broken trust, feelings of a disconnect between customer and team, leads to a poor working relationship.

5. Failed expectations turns into arguments, stress over delivery, budget overruns, and contention of delivery methods.

6. All of this turns into longer delivery cycles and higher costs.

Fortunately, there’s a proven solution that eliminates all of the ambiguity by focusing in on our design language. In fact, it’s been written about and referenced by just about every thought leader in the technology space — yet, teams rarely take the time to do it right.

So, what’s the magic bullet that solves all these problems?

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!