User Profiles & Social Graph
Let users present themselves, follow each other, and control visibility — with vanity URLs, verification, and privacy controls that scale.
Options
Profile Visibility Model*
Social Graph Model*
Profile Customization
Moderation & Trust
Decision Points
Public profile pages or private-only?
If yes
Plan for indexing, moderation, abuse reporting, and takedown flows. Public profiles are a marketing surface and a liability at the same time.
If no
Tenant-scoped or private-only profiles avoid most of the moderation cost. Right default for B2B SaaS.
Username uniqueness global or per-tenant?
If yes
Global uniqueness — required for public profiles, vanity URLs, and cross-tenant mentions. Reserve system-y words and handle squatting early.
If no
Per-tenant usernames — simpler for B2B, but no vanity URL is possible and cross-tenant references need opaque IDs.
Avatar uploads, Gravatar, or generated defaults?
If yes
Support uploads with size caps and EXIF stripping, Gravatar as a fallback for dev audiences, generated defaults for everyone else. Never show blank avatars.
If no
Generated defaults only — fine for lean MVPs, but users expect to upload eventually.
Per-field privacy controls on profile?
If yes
Three visibility levels maximum (public, connections, private) per field. Every query that renders profile fields must check audience — grows query surface.
If no
A single whole-profile visibility setting keeps the model simple; most users never touch per-field controls anyway.
Follow graph asymmetric (follow) or mutual (friend)?
If yes
Asymmetric follow — simpler, enables audience building, fits content-forward products. Plan block/mute from day one.
If no
Mutual friend — fits real-identity communities. Design pending/accepted states, invitations, and rejection flows.
Block and mute capabilities?
If yes
Block hides profile/content/DMs bidirectionally and cuts off all surfaces; mute is one-way silence. Non-optional once a social graph exists.
If no
Only acceptable when there is no social graph. Without block/mute, the first abuse incident becomes an emergency.
Profile customization (banner, bio, external links)?
If yes
Ship bio + links first; banners are a creator-platform affordance. Cap link count and use rel="nofollow ugc" on public profiles to prevent SEO abuse.
If no
Avatar + display name only. Perfectly fine for internal or workspace-scoped profiles.
Verified-identity badges?
If yes
Only meaningful when the badge represents real verification (domain, ID, or external signal). Document exactly what it proves.
If no
No badges is clearer than a vague badge. Do not ship paid "verification" — it destroys trust across all other badges.
Show public activity on profile?
If yes
Surface public posts/contributions/followed accounts, with a per-field toggle. Users will want granular control over what their profile advertises.
If no
Profile stays a static card — simpler, less signal, less moderation surface.
Vanity slugs for profile URLs?
If yes
Decide global vs. tenant-scoped upfront. Reserve system names, implement a release/grace-period on rename, and block impersonation of common handles.
If no
Opaque IDs — safer against phishing and squatting, but every shared profile URL looks ugly.
Profile edit history visible to the user?
If yes
Cheap durable log of recent edits, visible only to the owner. Useful for account-compromise recovery.
If no
Most users never look — skip until you have a specific use case.
Profiles indexable by search engines (SEO)?
If yes
Render server-side, set canonical URLs, and generate a sitemap. Expect crawlers from day one and budget for abuse-driven takedowns.
If no
noindex on profile pages. Correct for tenant-scoped or private products.
Profile view analytics for the user?
If yes
Professional platforms (LinkedIn-style) benefit. Disclose view tracking prominently — users view-tracked without consent is a trust hit.
If no
Default off, especially on consumer social. View tracking is almost always regretted on social products.
Pronouns and identity fields on profile?
If yes
Free-text pronouns (not a closed enum), optional identity fields, first-class status — not a "profile settings afterthought" pane.
If no
Only acceptable for products with no social dimension. On anything with humans interacting, leaving this out reads as hostile.
Profile deletion: preserve or remove authored content?
If yes
Preserve content with an anonymized "[deleted user]" authorship. Protects thread integrity but requires clear disclosure at deletion time.
If no
Full hard-delete with cascading content removal. Aligns with GDPR "right to be forgotten" but breaks conversations the user participated in.
Tradeoffs
SEO and discovery upside paid for by ongoing moderation, abuse, and takedown cost
Enables audience building but introduces harassment vectors — block/mute becomes non-optional
Creates phishing risk from stale slugs being reclaimed — requires reserved-name list and grace periods
Every surface that reads a profile now needs an audience check — query complexity grows
Dependencies
Implementation Examples
Email-keyed avatar service — useful fallback for dev-audience products before shipping uploads.
Hosted follow graph and feed infrastructure with asymmetric follow primitives out of the box.
Drop-in profile management with avatars, identity, and multi-field editing for B2B apps.
Reference for public, indexable profiles with customization, activity surfacing, and vanity slugs.