Besides organizing content in a way that matches how users are looking for it (by goal rather than internal company department name, for example), as an information architect, I also focus on using labels that are clear to users.
“Clear to users” may sound subjective and difficult to quantify, but there are some key methods to identify if a label makes sense to users or not.
When I say label, I’m being deliberately generous with the word choice, and referring to different types of items:
- the title of a website page
- the title of a section in a mobile app screen
- a new feature
- a category that groups similar items together
- any word that appears in a digital interface really
Labels affect user understanding, which affects user satisfaction with the product. The last thing you want is to make your users feel incompetent, yet that’s exactly what some products do. How satisfied a user is impacts whether they purchase again/renew a subscription/donate to a campaign/choose an educational program at one school over another. You get the gist: no matter which industry you’re in and what goals you have, you’ll benefit by ensuring your customers face intuitive designs that are clear to them.
Now that we’ve defined what a label is in the Little Language Models universe and how labels impact businesses, I’ll share five methods I use to tell if the labels in a product make sense to users.
- Internal search
- Search engines
- Support tickets
- Content testing
- Documentation hackathons
1 – Internal product search
I can see what people are searching for within a product, whether that’s a website (through Google Analytics), an app (through Amplitude), or a documentation portal (through GitBook).
When I look at internal product search data, the phrases that people have typed in the search box help me identify user language. These search phrases are how users refer to product information or features “in the wild.”
I use search phrases to identify mismatches between natural user language and current product language. For example, within an editing interface on a writing platform, I notice tens of searches for Content blocks. It’s possible within analytics platforms to see when the user started the search (what page they were on), where they went next, if they refined their search terms, where their scroll stopped, and generally, follow the user’s path and their interactions with a product. Through this analytics data, I notice a pattern. Most of the people who looked for Content blocks went on to use the currently-called Enhancement components, which offers the ability to add custom blocks like the estimated reading time, the table of contents, or a summary to an article. Knowing how users refer to the feature helps ensure we’re incorporating their mental models into the product, making it clearer and easier to navigate.
2 – Search engines
There are different ways to reach a page: typing it in a search engine, clicking on an AI recommendation, clicking on a link you were sent by a friend, scanning a QR code (this is a safe zone to hate on QR code menus).
I can see the most common terms people searched for that brought them to a page. I can also see which terms brought them to which pages. It’s also possible to tell if the product is doing a good job at matching users’ search intent by reviewing impression and click data (the number of people who clicked after viewing a search result divided by the number of people who viewed the result) and exit rates (the number of people who left after viewing the result – very roughly speaking, high exit rates are preferred for support/answer-focused pages and a cause for worry for conversion-focused pages like checkout).
Through Google Trends, I can see what people in general are searching for and even compare two different terms’ usage. For example, under Words to avoid, the UK government manual mentions that search engine data show that many more people use “Brexit” than “EU exit.” So, they tell their government practitioners to say what users are already saying.
Again, knowing how users refer to something helps ensure we’re incorporating their mental models into the product, making it clearer and easier to navigate. Identifying which pages may not be meeting users’ intent, exploring why, and making those changes makes for a clearer, smoother experience.
3 – Support tickets
Most customer support tools offer manual and automated groupings for tickets, making it easier to organize them, answer them promptly, and spot patterns.
For example, Help Scout, a CS tool, suggests different topics could be covered by an arbitrary tag like “billing issue.”
- The billing system was down.
- The customer’s card is expired.
- The customer’s bank rejected the payment attempt.
Help Scout suggests coming up with bigger groups like billing, then breaking it down into categories you know will be used often, like:
- Payment failed.
- Change payment details.
- Cancel/change subscription.
Talking to someone from the CS team can help tremendously to understand themes, frequently asked questions, and common frustrations. I can also see within tags and categories for a more quantitative look into impactful areas to focus on.
Maybe there are too many words, or the most important information they’re looking for is buried at the end of the page in a 12px font, or maybe the explanation in the live app is different and much more convoluted than the one users get directly from a support representative. Knowing what users are frequently asking or frustrated about helps ensure we’re writing clear instructions, making the product clearer to navigate.
4 – Content testing
I can pay people to tell me what’s wrong with my design! More specifically, I can pay people to see which labels make sense to them, how they look for information within the design, and where they expect information to be.
For example, just 8 user tests transformed the funding process for thousands of PhD students. About 4 hours and $250 in recruitment and tools costs gave us invaluable, actionable feedback on page structure and language. I created two versions of the fellowship program page and tested them with carefully screened participants (Master’s Degree requirement). Four participants tested each version, completing tasks like:
- Finding the application deadline
- Determining eligibility requirements
- Understanding what to include in an application
- Assessing eligibility for unrelated fields (Applied Statistics)
Participants rated task difficulty (1–5 scale) and explained their reasoning, revealing where they expected information and why they got stuck. If you’re interested in key findings and changes made, check out the entire content testing case study.
In What is the ROI of user research for content? I’ve shared the patterns I’ve noticed to help you determine if, when, and how much research to conduct for meaningful results. Remember: The research goal should be simple enough to explain to colleagues in the office kitchen. Suggesting user research as a generic activity without tying it to a specific business context or user need is unlikely to be effective.
5 – Documentation hackathons
I’ve written a guide about the dos and don’ts of building a business glossary, but for a quick recap, here’s where to start.
- Start with an unstructured brain dump. Get as many terms on paper as possible. Don’t worry about their meaning or usage frequency at this stage.
- Review your latest communications in Slack and email. Have you used any acronyms or terms that you’re not 100% sure make sense to people outside your immediate team? Write them down.
- Identify your most frequently used documents. If you’re in sales, those might be pitch decks, proposals, and outreach templates. Read through them carefully, or better yet, hand them over to someone in another field and ask them to highlight acronyms and unclear terms.
- Create small groups with team members from other disciplines, where everyone has to explain their duties and an example of a day in their life, and others note mentions of acronyms or terms they didn’t quite understand.
I’ve also written about how to build a taxonomy that increases conversions. A taxonomy is a list of terms related to a product. It can often be the result of a docs hackathon. Some common taxonomy goals I hear include standardizing terms used in a platform, serving more relevant content to users based on their goals, and reducing the time it takes to design new features/pages. There’s a template, and as Francesca Marano said, who doesn’t love a template?!
“Excellent guide (with templates and who doesn’t love a template?) to put into practice *today* in the organizations we are part of.
In my last work we had two APIs. They were called in at least 5 different ways. Every conversation about one or the other was preceded by a clarification.
How much time is wasted in organizations when you don’t have a shared language? Too much.“
These are the 5 key methods I use to identify if labels match user language in digital products.
If you’re shipping content faster than you’re organizing it, labeling issues will start appearing like mushrooms after the rain, confusing users, overwhelming support teams, and damaging brand perception. Avoid and fix them by using the methods above.
AI Policy: I personally write each draft and final copy on this website. All content reflects my own thinking, ideas, style, and craft. I do not use AI such as ChatGPT or other LLMs to generate articles. Occasionally, I ask AI (such as Formalizer or Equativ) to summarize or re-state my own ideas and may restructure sections based on the response.
