I’ve done this too many times: create a user, type John Doe, add test@example.com, pick some random avatar, repeat.
It works when you need two users. It gets annoying very quickly when you need 20, 100, or a whole company.
And the result usually isn’t very useful anyway.
Placeholder data is often too clean
A UI can look perfectly fine when every user is called John Doe or Test User.
Then you put something closer to real data into it and suddenly names don’t fit, sorting behaves differently, cards become uneven, or some combination of language and characters breaks assumptions you didn’t know you had.
The same applies to company data. Five users with generic job titles don’t tell you much about how the interface will behave with an actual company structure.
You can prepare all of this manually, of course. I’ve done that too. But it’s not exactly the part of development I want to spend time on.
Generate it instead
This is one of the reasons I’m building Name to Avatar.
Instead of maintaining hardcoded arrays of fake users, you can generate synthetic data when you need it.
Names can be generated with attributes such as country, language, gender, and ethnicity. That makes it possible to create datasets that are much less uniform than the usual collection of John Does.
You can use them for prototypes, staging environments, seed data, tests, or anywhere else where you need people-like data without using information about real people.
Names alone are not always enough
If you’re testing something visual, you’ll probably need avatars too.
A list of realistic names next to 20 identical gray circles still doesn’t look much like an actual product.
Name to Avatar can generate an avatar directly from a name string. If you’re working with full synthetic identities, the avatar can also be part of that identity together with the other generated attributes.
That makes things like user cards, team lists, account pages, chat interfaces, and company directories much easier to test with data that actually looks different from row to row.
It also makes staging data easier
The bigger benefit appears when you need more than a few records.
Instead of creating every fake employee manually, you can generate the data through an API and use it directly in a seed script or whatever setup process you already have.
Need another 50 users? Generate them.
Need users from several countries? Generate those instead.
Need to recreate the dataset later? Put the generation into your tooling instead of keeping a hand-maintained pile of placeholder JSON.
The data is synthetic, so you also don’t need to copy real customer records into staging just to make the environment look realistic.
I’d rather spend time fixing the actual product than inventing another fake employee called User 17.
