A Safe Social Chatspace for the Next Generation

A companion to the case study Designing for the Next Generation: A Slack Product Vision. That post is about how I worked the board. This one is about the product the board pointed at.

The case study walked the method: translate the prompt, ground "next generation" in real research, and refuse to skip the compliance question. This is the other half. If I had been handed the budget instead of the whiteboard, what would I have actually built, and what would have kept me up at night.

The short answer: a social chatspace for younger users, where the hard part is not the features. It is that the moment your audience includes minors, safety stops being a setting and becomes the architecture.

The product, in one line

Younger users making real connections in small social chatspaces. Not another work tool with a fun skin, and not an open feed optimized for strangers and reach. Think shared rooms around an interest, a class, a game, a friend group, where the point is presence and belonging rather than broadcast. The thing Slack-for-work got right was the room. The thing it lost for this audience was the feeling that the room is yours.

Everything below is in service of that one line, and bounded by one fact: some of these users are children.

Safety is the architecture, not a setting

Designing for the next generation means designing for minors, and that reorders the entire build. Safety decisions are not a trust-and-safety backlog you get to later. They are the first product decisions, and they constrain every feature that follows.

The ones I would not compromise on:

• Age assurance up front, not a checkbox. A self-declared birthday is theater. The product needs a real age-assurance step, and it needs to branch hard on the result: an under-13 experience, a teen experience, and an adult experience are different products, not the same product with a toggle.
• Private and small by default. Rooms start closed. Discovery of a minor by a stranger should be effectively impossible. No public profile, no global search that returns a child, no "people you may know" that surfaces a kid to an adult.
• Data minimization as a feature. Collect the least you can. No precise location, no contact-list slurping, no behavioral profile built to sell. For minors this is also the law, but it is good product regardless: the less you hold, the less you can leak.
• Verifiable parental involvement for the youngest tier. For under-13, COPPA is not optional, so parental consent and a parent-visible control surface are part of the MVP, not a fast-follow. The design challenge is making that feel like care rather than surveillance.
• Adult-to-minor contact is the highest-stakes path in the system. Unsolicited contact from an adult to a child is the failure mode that matters most. The architecture should make it structurally hard: no open DMs to minors, no stranger-initiated threads, friend connections that require mutual, parent-aware confirmation in the youngest tier.

If a feature cannot survive these constraints, it does not ship. That is the whole posture, and it is why "Safe" is the first of the four principles, not the fourth.

The four principles, made concrete

In the case study, Safe, Simple, Familiar, and Engaging were the filter every feature had to pass. Here is what each one actually means in the product.

Safe

Beyond the architecture above, safety shows up in the everyday surface. Reporting and blocking are one tap, always visible, and never buried in a menu. Moderation is layered: automated detection for the obvious harms, human review for the ambiguous ones, and a clear, fast path for a kid to say "this made me uncomfortable" without having to explain why. Defaults are protective, and the protective default is the easy one. The safe choice should never be the hard choice.

Simple

"Too enterprise" is, underneath, a complaint about cognitive load. The product wins by doing less. One primary action, not a toolbar. Rooms you can understand at a glance. No settings labyrinth, no notification matrix, no nine-step onboarding. A twelve-year-old should get it in thirty seconds, and so should their parent. Simple is also a safety feature: complexity is where unsafe defaults hide.

Familiar

The magic this generation feels is already living in the products they love. So borrow the patterns they know: short-form and visual over long threads, reactions and presence over read receipts, lightweight and ephemeral over permanent archive, voice and audio as first-class rather than bolted on. Familiar does not mean copying TikTok. It means the interaction grammar should be one they already speak, so the product feels like home instead of homework.

Engaging

Engagement here is presence and play, not a dopamine slot machine. I would deliberately not build infinite-scroll-to-maximize-minutes, because that is exactly the pattern regulators and parents are right to distrust for kids. Instead, engagement comes from being together: knowing your friends are in the room right now, shared activities, small creative tools, status and identity expression. The metric I would optimize is something like "real interactions with people you know," not time-on-app. For this audience, optimizing raw time is both an ethical problem and a product trap.

The tension I would design around, not away

There is a real tension between Safe and Engaging, and pretending otherwise is how products for kids go wrong. The features that drive the most engagement (open discovery, frictionless contact, viral reach) are exactly the ones that endanger minors. You cannot maximize both, so the design has to pick, visibly, every time. My rule: when safety and engagement conflict, safety wins, and we find a different engagement mechanic that lives inside the safe boundary. Presence and play give you a lot of room to do that. Stranger-virality does not earn its risk.

That is also the honest answer to "bring the magic back." The magic for this audience is not reach. It is belonging, and belonging is something you can build safely.

How I would know it worked

A product like this is not validated by growth alone, because growth without safety is a liability dressed as success. So the close-the-loop measures would pair the two:

• Belonging and real connection: rooms with active mutual relationships, repeat presence with the same small group, kids reporting they feel part of something.
• Safety in practice: time-to-action on reports, prevalence of unwanted contact (driven toward zero), and how often the protective default actually held.
• Trust from the adults in the room: parents who understand and approve of what their kid is doing, measured, not assumed.

A version of this that grows fast while those safety numbers slip is not winning. It is accruing a debt that comes due.

Why this is the harder, better half

The case study's lesson was that the strongest move was refusing to skip the compliance question. This post is what that refusal looks like when you actually build: safety as architecture, data minimization as a feature, engagement redefined as belonging instead of minutes, and a willingness to let safety win the tension every single time.

Designing for the next generation is not designing a fun teen app. It is designing a safe place for kids to be together, and treating that as the product, not the disclaimer.

If you want to see this kind of thinking live, bring me a real product problem and watch me whiteboard it end to end: that is the Watch Me Think offer. To practice the method yourself, the Whiteboard Prompt Translator scaffolds the six frames from any prompt.