FIELD GUIDE · 5 MIN READ
Test a name in dialogue and on screen
A beautiful name still has to survive a conversation, a narrow menu, and a quick glance.
Test the actual context
A name used once in an opening narration has different demands from a name repeated in a combat-free management game’s task list. Write down the two places where users encounter it most often. For Maela, Echo Registrar, those places might be a contact menu and a spoken request. Design for those contexts first, then preserve the ceremonial form where it adds value.
Use three dialogue tests
Read the name in an introduction, an interruption, and a reference made while the character is absent. “This is Maela.” “Maela, wait.” “Ask the registrar.” These forms can coexist, but the story should establish the link. Read aloud at a comfortable speed. Notice accidental rhymes, adjacent names with similar rhythms, and titles that obscure the person being addressed. These are editorial observations, not proof from a user study.
Check a small viewport
Place the full name in the narrowest real component you plan to ship. Allow wrapping where it remains readable; provide a full visible label elsewhere if truncation is necessary. Do not shrink text indefinitely to preserve a long title. A two-line contact card with Maela on the first line and Echo Registrar on the second is often clearer than one compressed line. Check keyboard focus and zoom along with appearance.
Compare neighboring labels
Put the name beside the entries likely to surround it. Mira, Maela, and Mica have similar visual beginnings even though they are pronounced differently. If players must choose quickly between them, change one. Also compare names with action labels. A companion called Return may read as a button; a place called Settings could be confusing in an interface. The problem belongs to context rather than to the word itself.
Ask a specific question
When another person can review the list, ask “Which entry would you open to contact the registrar?” rather than “Do you like these names?” A preference answer and a recognition answer tell you different things. Record what happened without converting one conversation into a claim about all users. If nobody is available, run your own structured check and label it an editorial test.
Make one change at a time
Change the spelling, short form, or title placement, then repeat the same task. Keep a note of the reason so a later collaborator understands the decision. A practical final check is a screenshot at a phone width, a read-aloud passage, and a list of the nearest competing labels. Save those alongside your naming notes; they are more useful than a folder of unused favorites.
A split-label example
Place “Maela, Echo Registrar” on a phone contact card. Try a single line, a wrapped label, and Maela above a separate role line. Compare the same action in each version: identify the person responsible for an archive request. Keep enough context to distinguish her from another character with a similar given name. A visually elegant card that hides the role may work poorly for this particular task. Preserve the full form in a detail view and keep the repeated short form consistent across the journal and dialogue.
An explicit test record
Write the viewport, text size, neighboring labels, task, and observation in the same note. Include a screenshot if useful. If you change only the title placement, say so; if you also rewrote the surrounding descriptions, do not attribute every improvement to the name. Stop when the concrete ambiguity has been resolved. A practical interface check can guide an editorial choice without being described as a scientific study or a promise of universal accessibility.
PUT IT INTO PRACTICE
Try the method on a fresh name.
Open the related naming toolCreative drafts. Check suitability and existing uses before publication.