There are two stances you can take toward language in your website or app: prescriptive or descriptive. Which you choose influences the system’s understandability and findability.

The terms come from linguistics. I heard about them in a radio show (or was it a podcast?) many years ago. The gist was that there are two approaches to writing dictionaries:

  • Prescriptive approaches entail a small group of experts laying out the “correct” terminology for a language, following prescribed patterns and rules.
  • Descriptive approaches also have a small group calling the shots, but rather than dictate the rules, they learn how people use the language. Then, they codify how it works in practice.

Some languages (e.g., French, Spanish) have official entities that define standard usage. (The Académie Française and Real Academia de la Lengua, respectively.) Others, such as English, are more flexible. Consider the Oxford Word of the Year, which celebrates how English evolves. In contrast, the Académie Française discourages the use of foreign words in French. For example, they suggest using mél in place of the English word email.

These approaches represent different perspectives on culture. The prescriptive approach aims to preserve the language’s purity as it evolves. The descriptive approach, on the other hand, aims to clarify actual usage. (At least this is how I understood it back when I heard the program. I’m not a linguist, so please reach out if I got any of this wrong.)

Ok, back to information architecture. When you define an app’s navigation structure, section headings in a website, or taxonomy terms in a faceted search filter, you’re using language to communicate. You must make choices about which terms to use.

Ideally, you’ll use terms your users understand. You do research to learn what people call the different parts of your system. Then, you test those labels to see if they clearly convey intent and hang together as a set. This is akin to the descriptive approach: you’re trying to learn how people think and talk about your conceptual domain, and then reflect that language back to them.

But as I said, this is an ideal – and there are some cases where it won’t work. For example, you may be introducing a novel feature, something that has no clear name. Using an existing term might confuse users or give them the wrong idea. Or maybe your org wants to promote a branded name.

I’ve often seen this in product menus that list a company’s offerings. If the products are well-known, then using branded labels is ok. For example, I expect most relevant users know the difference between Photoshop and Illustrator. But if the products aren’t well known, the brand names won’t help users choose.

In that case, you have options. You could add a small phrase under each brand name to clarify what they are. Or you could look for a more generic name to use in menus (and show the brand name in the product’s page.) Or you could plow ahead with the more prescriptive approach: simply using the branded label in the menus, leaving it up to the users to discover the differences between them.

While this comes at the expense of understandability and usability, it gets users to start thinking in your terms – i.e., literally using your language to describe the space. It’s a risky approach, but one that can be employed strategically.

Which is to say, both approaches have their uses. I must confess to preferring the descriptive approach. I always opt for clarity, particularly in navigation menus. In many cases, branded options aren’t clear. But that doesn’t mean they’re flat out wrong.

You can think of architectures as being on a continuum between fully prescriptive and fully descriptive. Few exist at either extreme. Ideally, yours will be closer to descriptive. But it’s ok to allow a few less clear terms to sneak in – so long as users have enough context to understand what they’re looking at.