Device profiles, not user accounts: keeping demographics out of a family game¶

When I started designing the profile screen for this board game platform, the first thing I did was rip up the design.

The mockup I'd inherited had everything you'd expect from any modern app: a profile photo, a display name, pronouns ("he/him", "she/her", "they/them", custom). A bio field. An age. A location. The little trail of social-platform conventions that have crept into every product on the internet, regardless of whether the product is, you know, a social platform.

This product is a board game for the family living room. It is not a social platform. It does not need to know your pronouns. It does not need to know your age. It does not need a photo of your face, and it definitely doesn't need to upload a photo of your face anywhere.

So I deleted all of it.

What a profile is¶

A profile in this product is device-shaped, not person-shaped. It belongs to the device the family hands to a kid. It has exactly four fields:

Screen name. A display name. Freely editable. Not "real name." Not "first name and last name." Just whatever you want to be called when it's your turn.
Two-letter initials. Customizable. Not auto-derived from the screen name. If your screen name is "Captain Awesome" and you want your initials to be "QQ", that's allowed. The initials show up on small UI elements where the screen name doesn't fit.
A preferred game color. Chosen by the device's owner. Not auto-hashed from the name. Used as a default when joining a game with color-coded seats.
An avatar. Picked from a permission-gated preset gallery. Never uploadable. Never user-supplied. The gallery is curated; users select.

That's the profile. There is no fifth field hiding in a settings sub-menu.

What a profile is not¶

This is the part that sounds reasonable but is the actual point of the post. Here's the explicit list of things this product does not have, and will not have, anywhere -- not in schemas, not in models, not in UI mockups, not in specs, not as a "TODO for later":

No pronouns. Not he/him, not she/her, not they/them, not custom. The product has no field for pronouns because the product never needs to refer to a specific person.
No real names. No "first name" / "last name." No "legal name." No "what should we call you on receipts?" There are no receipts.
No gender or sex.
No age, birthday, or date-of-birth.
No race, ethnicity, or nationality.
No language-as-identity. (Language preferences for the UI, sure -- that's about the device, not the person. There's no field for "your native language.")
No location. Not country, not zip code, not "for tax purposes."
No profile photo upload. No "URL to a photo." No "we'll fetch your Gravatar."
No bio field. No status message. No "tell us about yourself."
No in-game chat. No DMs. No whispers. No emote spam. The product is not a chat app and never grows a chat panel "for fun." The stronger argument here isn't "you're in the same room, talk to each other" -- the platform supports remote play too. The argument is that the people playing this game already know each other. They're family or close friends who decided to sit down for a round together. If they want to trash-talk during a remote game, they have FaceTime, SMS, Discord, a phone call, or any of the dozen other channels they already use to reach each other. The product does not need to bolt on a worse copy of those tools, and it is not going to insert itself between people who already have each other's numbers.
No friend list. No "add player." No follow / unfollow. No friend requests. The product has no concept of a social graph. The set of people you played with last Saturday is the set of people you played with last Saturday; the product does not turn it into a list it owns and surfaces. The people you play with are already in your contacts -- that's how the invite reached them in the first place.
No presence indicators across rooms. No "Sam is online," no green dots, no "your friend just started a game." The only presence the product cares about is "who is in this game right now," and that information stays inside that game. If you want to know whether your sister is free to play, text her.
No "find a player" / "locate a device." No public profile search, no nearby-players discovery, no shareable user ID someone can paste into another device to ping you. Devices are reachable by being invited into a specific room by code or QR -- and that invite arrives over the inviter's normal communication channel (text, group chat, "hey come play"), not through the product. That is the entire surface area for one device reaching another.
No real-world location, ever. No "share location," no geofenced features, no "find a game near you." The product has no business knowing where any device is on Earth.

A reasonable product manager from a social platform reads that list and says "but pronouns are easy and polite and people want the option." The product manager is right that adding pronouns is easy and polite. The product manager is wrong about whether it belongs in this product. This is a board game played by people who already know each other -- whether they're sharing a couch or playing remotely from three different time zones -- and people who already know each other do not need the game to be the wire connecting them.

What "device profile" means¶

The framing matters. The phrasing in this product is "this device" and "this profile" -- not "your account," not "your identity." There is no sign-up step. There is no email address required. There is no "log in." There is no password.

When a family unboxes this and sets it up, what they do is hand a phone to whoever is going to use it most, that person sets a screen name, picks an avatar, picks a color, and the device is ready. If a different person grabs the phone next time, they can edit the screen name. The profile travels with the device, not with a person.

For families with multiple devices, each device has its own profile. The TV doesn't have a profile. The phones do. There are no "user accounts" linking devices together. There's a "move to another device" flow that copies the local device state to a new device -- but that copies device state, not person credentials, and it works because the device knows itself, not because it knows you.

The forbidden framings: "user account," "sign up," "registration," "create account," "log in" / "sign in" (in the personhood sense), "your identity." Anywhere any of those words appear in a spec, mockup, or PR, it's a flag to stop and rewrite. The phrasing is "this device," "this profile," "move to another device."

Why the bias is the bug¶

If you ask a coding agent to design a profile screen for a game, it will autocomplete from millions of training examples of social-platform profile screens. It will add pronouns because pronouns are polite. It will add a bio because bios are personable. It will add a profile photo because photos are friendly. None of those decisions are wrong given the training data. They're wrong given this product.

This isn't a knock on AI specifically -- it would happen with a human designer too, because the human designer also got their idea of "what a profile screen looks like" from the same body of products. The training data of the entire industry is "person-shaped profile screens." When you ask anyone, human or AI, to build a profile screen, that's what you get.

The way you defeat this is not to be a better designer. The way you defeat it is to write down the rule explicitly and check every mockup, every spec, every ticket against the rule. When a draft drifts toward person-shaped fields -- which it will, every time -- you stop and flag it rather than autocompleting the pattern. The list above isn't aspirational. It's the actual rule, checked against every artifact this project produces.

The behavioral preferences exception¶

There's a category of preferences that do belong on a device profile: the ones that describe the device's behavior, not the person.

Notifications on/off.
Haptics on/off.
Reduce motion on/off.
Theme: light / dark / system.
Sound on/off, volume.

These are fine, because they're describing how this device behaves, not who this person is. The phrasing test is: "does this field exist to serve the device's behavior, or does it exist to identify the user?" Behavioral preferences serve the device. Pronouns identify the user. The line is sharp once you start looking for it.

Why this is load-bearing¶

This isn't an aesthetic choice or a "nice-to-have privacy posture." Four concrete reasons:

Liability. Every demographic field collected is a regulatory and breach-disclosure surface. The product has no need for any of them, so collecting them creates downside risk for zero upside.
Posture. This product is, eventually, going to be in classrooms. The classroom partner conversation goes very differently when the answer to "what does the platform collect about students?" is "nothing." Not "nothing identifiable." Not "nothing personal." Just nothing.
Drift. Once you have a pronouns field, someone will want to add a "preferred name" field. Then a "school name" field for the classroom version. Then a parent-email field "for parent reports." Each addition is individually defensible and the cumulative result is a social platform you didn't mean to build. The fence stays where it is because the only way to stop the drift is to refuse the first step.
Uncluttered and kid-safe by design, not by settings. This is the deepest one. The product is for families -- meaning kids will use it, in living rooms and in classrooms, on devices their parents handed them. The way most products handle "kid-safe" is to ship the unsafe version and add a settings panel: a "family mode" toggle, a parental-controls page, a "safe chat" filter, an "approve friend requests" workflow. That model is broken. Settings get missed on fresh installs, defaults get the wrong way around, kids find the toggle and flip it, and the product manager who added the feature was always more excited about the feature than the gate. Configurable safety is a euphemism for "unsafe-by-default with a switch." The fix is not to ship the unsafe version and gate it; it is to not ship it. That is why this product has no chat panel with a profanity filter -- it has no chat panel. No friend list with parent approval -- no friend list. No presence indicators with a privacy toggle -- no presence. The only mode is the safe one, for everyone, on every device, and there is no settings page that can change that, because there is nothing on the settings page that could change it. An eight-year-old picking up a phone at a friend's house gets the same product a forty-year-old gets at home. That is what "by design, not by settings" means.

The handoff pattern¶

The one move that looks like a "user account" feature, and is allowed: the "move to another device" flow.

The flow: you tap a button, the device shows a one-time pairing code, you enter that code on the new device, the new device receives the local state (screen name, avatar, color, behavioral preferences). The old device's profile is now on the new device.

This is permitted because it's copying device state, not person credentials. There's no central server account being moved. There's no "log in on the new device." There's a peer-to-peer state copy with a one-time code, and the code expires in 60 seconds.

The mental model is "I'm getting a new phone, I want my game to keep its avatar," not "I'm logging into my account on a new device." The technical implementation respects that distinction because the user-facing framing matters and shapes everything downstream.

What to take away¶

If you're building a product right now, ask a hard question of every field on every form: does the product's job require this, or am I autocompleting the pattern? If it's the second one, the field shouldn't exist. The default of "every product is a social platform with a profile and pronouns" is a default you can opt out of, and the cost of opting out is much lower than the cost of opting in and trying to delete it later.

The product I'm building is a board game. People around a dining room table playing a board game can already see each other and know each other's names. The product does not need to know what they look like.