How to test a product name before launch

Test the moments where a name has to work

A product name looks different in a polished presentation than it sounds during a hurried introduction. Before committing to a launch, test a few ordinary moments: hearing the name, typing it, reading it aloud, and explaining which product it belongs to. The goal is to notice friction while changes are still manageable. A small test gives a team concrete observations to discuss; it does not predict the entire market’s response.

Start by writing down the intended audience and the contexts in which people will encounter the name. A product sold through demonstrations may be spoken often. A tool shared through invitations may be read before it is ever said aloud. A community service may depend on members telling colleagues about it. Those differences should shape the test instead of forcing every name through the same abstract popularity vote.

Separate the questions

There are several things you might want to learn. Can someone hear the name and type the spelling you intend? Can someone read it and say it in a way the team can recognize? Does the name beside a short description lead to the intended category? Can someone find the address in a realistic message? Treat these as separate questions because a name can work well in one situation and poorly in another.

Avoid asking only, “Do you like it?” A participant can dislike a name and still use it accurately, or enjoy a name while repeatedly confusing it with another one. Preference is worth recording at the end, but observed errors should have their own place in the notes. The team needs to understand what happened before discussing whether it matters.

Prepare a consistent little test

Use one short script for each task. For a listening task, say the name once in a sentence with the same amount of context each time. Ask the participant to type the address they would try. For a reading task, show the name in plain text and ask them to say it aloud. For a context task, place it beside the same product description you intend to use at launch.

The GOV.UK guide to moderated usability testing recommends clear, neutral tasks and warns against giving away the answer. Applied here, that means withholding spelling hints and explanations until the participant has responded. This is an adaptation of a general research principle, not a validated scoring system for names. The sample tasks and decision rules below are an illustrative plan a team can adjust.

Choose people who resemble likely customers and have not already heard the naming discussion. Teammates who have seen the shortlist for weeks are poor substitutes for unfamiliar readers. Ask about language and relevant professional context so that the notes can distinguish an isolated misunderstanding from a question the intended audience may share. Participation should be voluntary, and any recording should be explained beforehand.

Try the listening task first

Imagine testing an invented name for a client approval tool. The researcher says, “Your designer will send the approval request through [name]. Where would you expect to go online?” The participant types an address without seeing the written name. Record the exact response, including any extra letters or guessed suffix. Do not silently correct it in the notes.

After the initial response, ask what the person heard. A participant may have heard the intended sound but chosen a different spelling. Another may have misunderstood the sound itself. Those are different problems. The first suggests a spelling burden; the second may reflect the audio context, pronunciation, or similarity to another word. Repeating the same test in a quieter setting can help examine a suspected recording problem, but keep the original observation.

If the real product will often be introduced in noisy rooms or short calls, include one realistic example of that context. Avoid making the task artificially difficult just to create errors. The purpose is to model a plausible customer experience, with enough consistency that the team can compare results.

Read, recognize, and retrieve

Next, show the name in a simple product invitation. Ask the participant to read the product name aloud and describe what they think the invitation is asking them to do. This reveals whether the name and the surrounding copy work together. If the person misunderstands the action because the invitation is vague, record that as a copy problem rather than blaming the name automatically.

A separate retrieval task can happen after another brief activity. Ask which product name appeared in the invitation and how the person would return to it. Keep the delay similar between sessions. This gives a limited observation of recall within the session. It should not be presented as proof of long-term memorability or used to claim that a name will be remembered by a broad audience.

When comparing several candidates, change their order between participants. If everyone sees the preferred candidate first with the best-looking design, the comparison is tangled with presentation. Plain, consistent materials make it easier to see which questions belong to the name and which belong to the styling.

Decide what would make you pause

Write provisional decision rules before reviewing the responses. For example, a team might pause if multiple unfamiliar participants independently produce the same wrong spelling after hearing the name. It might investigate further if readers repeatedly associate it with a different product already familiar to them. These are prompts for follow-up, not universal numerical standards.

Consider the consequences of each error. If a name is mostly encountered as a clickable link, a spoken spelling problem may be less central than it would be for a telephone referral service. It still deserves attention. A customer who forwards the product to a colleague may introduce it in a new context. The team should be able to explain why it accepts a particular tradeoff and where clearer supporting copy could help.

Keep a simple table with task, exact response, observed difficulty, possible explanation, and next check. Put “unknown” in the explanation column when appropriate. A researcher’s guess should not become a fact merely because it sits in a spreadsheet. If the same error appears several times, review the original notes before deciding whether to alter the name, the pronunciation guidance, or the surrounding message.

Turn observations into the next round

Suppose two participants type an extra letter, one asks which product category the name belongs to, and everyone finds the invitation link. The next round could test a clearer spoken introduction and a more specific product description. It should preserve the task that already worked so the team can see whether the revision creates a new problem. Avoid changing the name, logo, description, and task script simultaneously if the goal is to learn which change helped.

A good outcome is a short decision memo: the audience tested, the contexts used, the observed errors, the unresolved questions, and the reason for the next step. That memo lets a team compare evidence with its own judgment. It also prevents a handful of friendly comments from becoming an unsupported claim that a name has been validated.

For Nodu.com or any other candidate, bring the name into the actual sentence a customer will hear and the actual message they will receive. Recruit unfamiliar readers, run the tasks without coaching, and preserve their exact responses. The resulting evidence will be modest, but it will be much more useful than another round of internal voting.