Formal or Casual? Getting the Language Right

We all know our interfaces should talk in the language of our users. But what if that language doesn’t serve your business goals?

This happens more often than you might think. And every time it does, the business needs to make some tough calls. But often they’re not sure how to make the right decisions, and half-baked compromise-copy is the disappointing result.

Let’s look at an example that illustrates these problems, and talk about how your business can avoid falling into the trap of making poor compromises, rather than astute choices, about your interface text.

The test results we didn’t want to know

Recently, I was in a team tasked with redesigning an email support interface for non-technical users. The popular internal jargon around this system included words like “submit” for what users do to flag a problem with the support service, and “ticket” to refer to the request itself. The people who solve the support queries also refer to “tickets” as “calls”, and have a small but pithy vocabulary of other system-specific terms that they use, but which are unknown to customers.

The brief for the redesign focused on making the system clearer and simpler for customers to use, and was part of a repositioning of the business as customer-centric, helpful, friendly, and transparent.

Accordingly, we developed clearer language around the system and its functions (which wasn’t exactly hard to do), mocked up some interfaces, and did some user testing of the copy.

Here’s where we hit trouble. The users, educated over years to use the current system, associated the formality of the language with formality of process. More casual language made them wonder: is my request still going to the right place?

If that sounds crazy, imagine you’re doing your tax. You open the form and it has just three questions:

• How much money did you earn this year?
• What’s the total of your deductions?
• When you take your deductions away from what you earned, how much is left?

You’d probably wonder what they were smoking in the nation’s capital. Here in Australia, our tax forms come with an FAQ and glossary, since so much of the language that’s used is unfamiliar to ordinary citizens. It’s formal. It corresponds to complex processes. And while we struggle with that each financial year, I suspect we are also, in some degree, reassured that the Tax Office is so formal. They use specific language so there’s no room for confusion, and they can get each person’s tax assessment right.

Similarly for the users of the support form we were working on, casual language suggested a more casual approach to solving their problems. Other interface characteristics compounded this issue, but the language caused its own set of problems with the tested users.

In this case, friendlier language implied a less professional attitude on the part of the organization.

Decision time

This is an extremely common issue with interface text.

Many business owners implicitly hold this belief about their own offerings, which is why so little content is actually written in plain English—business owners believe, “We’ll sound more professional and skilled if we bamboozle users with the appropriate ‘lingo’.”

But it’s less common to have users demanding more formal, complex language in an interface through which they are, after all, simply trying to get help.

So the business needed to make a decision. It wanted to reposition itself as a user-friendly organization. Its users wanted jargon. It wanted to be transparent. Its users seemed happy with at least two different words for the same thing (“call” and “ticket”), neither of which actually described the thing itself.

At heart, where the organisation wanted to be seen as innovative but on the level, the users wanted to see it as a process-driven authority, because that was the reason they believed things got done.

Now, you could argue that since the users had spoken, the business should listen to them and stick with the language they knew and loved. But there area a few problems with this approach:

• The purpose of the project was to help reposition the brand. That implies change, and a shift in the way users think about the brand. Do you dilute your improved market position because your audience likes the old one? Or do you look for ways to make that change, but make it easier on users?
• The project intended to make the brand more accessible to new customers in future. The testing involved only current users. Once you’ve put in effort to learn how to use a system, it makes sense that you’d be reticent to let that learning go. But for new customers who’d never used the old system, the new approach may be much more accessible. Again, you don’t want to disaffect your existing users, but if you’re looking to expand your audience over time, will you restrict your business to being driven by current customers?
• Ultimately, will you curtail your business’s evolution based on the preferences of the users you have today?

To most of us, these questions seem an anathema. Aren’t users the exact people from whom we’re supposed to be deriving the insights that will drive our business growth? Who wants to damage their brand loyalty and authority with an unpopular change? If the current approach is preferred—and proven—then who are we to tell users how they should be using our systems?

Remember what I said about tough decisions? These are those.

How to choose

I’ll be honest with you: in my experience, startups are much less likely to make these tough calls, let alone make them well, than are more mature businesses.

It’s easy to see why: startups are less stable, have less of a history, and face more dire consequences of failure on pretty much any front. The people who are making the decisions—usually the CEOs or founders, who often have little exposure to or experience in communications strategy—are extremely risk-averse. And ultimately, with their own backsides on the line, as well as those of their team members and investors, they’re not confident to simply give a direction and let “creatives” like writers, designers, and usability experts, work out how best to implement it.

At the moment, the support organisation I’m working with believes they want to implement the new, plain-language interfaces. We’ll see if that pans out, but there are a number of things we can do to help hone down the options here.

The first is to find some budget to test the new screens with potential users. The second is to let the creatives come up with a middle ground (perhaps instead of “submitting tickets”, users could “report problems”—although businesses tend to be hesitant to use “negative” words like “problem”), and test that with current and prospective users. Another is to create two versions of the interface, A/B test them, and possibly survey users about their experiences afterward.

The worst-case scenario is that nervous founders lock themselves in a room with the mockups for four hours, try to hammer out their own vocabulary, ask a passing developer to give her opinion, run it past their brothers-in-law at a weekend BBQ, and eventually implement something that no one’s happy with—them and their users least of all.

Which approach does your business take when user testing suggests your brand direction (interface text, design, and so on) goes against the grain for users? I’d love to hear about it in the comments.