Back to News & Insights
Web Development September 21, 2026 · 6 min read

Designing a Better Baby Name Search: What I Learned About Search UX, Unicode, and Relevance

A baby-name database sounds like a straightforward CRUD problem. Store a name. Store its meaning....

Designing a Better Baby Name Search: What I Learned About Search UX, Unicode, and Relevance

That was roughly how I looked at it when I started working on the naming side of Nurturepedia.

They don't always type the exact spelling. They search by meaning. They try different spellings. They mix cultural preferences. They want names from a particular origin or religion. Sometimes they know the sound they want but have no idea how the name is spelled.

At that point, "searching a database of names" becomes a much more interesting engineering problem.

This article walks through some of the technical and UX lessons I've learned while building a better baby-name discovery experience. Search starts with the data model

{ name: "Amélie", normalizedName: "amelie", gender: "girl", meanings: ["work", "industrious"], origins: ["French"], religions: ["Christianity", "Neutral"], alternateSpellings: ["Amelie"], countries: ["France", "Canada", "United States"] }

That separation becomes particularly useful when your dataset contains names with accents, diacritics, alternate spellings, or characters from different writing systems. Unicode can quietly break a search experience

JavaScript developers eventually run into an annoying fact: two strings can look identical but contain different Unicode representations.

For example, a character such as é can be represented using a single code point or as a base character followed by a combining accent.

JavaScript's String.prototype.normalize() exists specifically to deal with these different Unicode representations.

const normalized = value .normalize("NFKD") .replace(/\p{Diacritic}/gu, "") .toLowerCase();

MDN documents the distinction between canonical and compatibility normalization, and compatibility normalization can be useful for search-oriented processing in appropriate situations.

The important caveat is that I would never replace the original display value with the normalized value.

That small architectural decision prevents a lot of problems later. Exact matching isn't enough

This is where search becomes a relevance problem rather than a simple database lookup.

Exact name match ↓ Exact normalized match ↓ Prefix match ↓ Alternate spelling ↓ Meaning match ↓ Broader relevance

The exact scoring strategy depends on the application, but the principle is important:

A search engine should understand what the user probably meant, not just what text happens to exist in the database.

MongoDB Search provides tools specifically for relevance-oriented search, including autocomplete, compound queries, filtering, faceting, and scoring.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation