13 min read

How to write user-facing platform policies

T&S Insider’s practical, step-by-step guide to writing community guidelines that actually work

I'm Alice Hunsberger. Trust & Safety Insider is my weekly rundown on the topics, industry trends and workplace strategies that Trust & Safety professionals need to know about to do their job.

This week, I continue my "How-To" series with a guide to writing user-facing platform policies. You can read the first — on evaluating T&S vendors — with an EiM membership.

In my many years in T&S, I've worn a lot of hats, but policy continues to be an area I'm extremely passionate about. Not only is it the foundation upon which operations and automation sit, but it's a way to express platform values and ideals to users.

In today's guide, I'll walk you through what a good policy looks like, mistakes to avoid, and hidden considerations you may not have thought of. Note that I focus on the user-facing side of policies/community guidelines, not how to operationalise those policies (maybe that's a guide for another day).

I'd love to hear from you if you found this helpful, or if you have suggestions for what to write about next. Here we go! — Alice


SpoNSOR EVERYTHING IN MODERATION AND SEE YOUR BRAND HERE

Get in front of the smartest, most engaged audience in Trust & Safety. Sponsoring Everything in Moderation puts your brand directly in the inboxes of policy experts, technologists, and researchers shaping the future of internet safety and platform governance. New sponsors get a discount before the end of February.

FIND OUT MORE ABOUT SPONSORSHIP

My guide to creating really good platform policies

Community guidelines are one of the most important documents a platform will ever publish. They set the tone for the entire userbase, communicate the values of the platform, and give users the framework they need to have a good experience. They're also documents that nobody reads until something goes wrong.

I've been writing community guidelines for most of my career in Trust and Safety, first at OkCupid and then at Grindr, where I was the only person doing it for years. Now, at Musubi, I spend a lot of time helping platforms take their existing written policies and operationalise them in ways that LLMs can enforce. That experience has sharpened my view on what makes a policy work and what makes it fail in ways that aren't always obvious until you're in the middle of it.

This guide reflects that perspective. It's aimed at T&S practitioners across the full range of platform sizes, and the advice scales accordingly. Not every step here requires months of research and a roster of external stakeholders, but it’s great if you do have those resources. What matters is that you do some version of each step, even if you're doing it in a week rather than a quarter.

Where writing platform policies fall down

The fundamental problem with most platform or community guidelines is that they're written for the wrong reasons and targeted at the wrong people.

The reasons are typically one of the following:

  • To protect the platform legally.
  • To make enforcement easier.
  • To give communications teams something to point to when a bad press cycle hits.

While these are all real needs, they tend to yield documents full of passive-voice legalese and long lists of prohibited behaviours, framed as though the person reading them is a potential bad actor.

That speaks to the issue of who’s reading these guidelines. The people who typically read platform or community guidelines are those trying to understand the rules so they can follow them, or those who sent a report and want to confirm that what they saw actually violates a policy. People who plan to harass users or run scam accounts or violate the guidelines in some way are rarely consulting your guidelines first to make sure they're staying within bounds of what’s acceptable. The people reading your guidelines are, for the most part, trying to understand the rules so they can follow them, or they've just filed a report and want to confirm that what they saw actually violates a policy. Your guidelines should be written for those people.

There are a few other tensions that make policy writing hard:

  • Specificity vs vagueness (by intention): If your policies are too vague, users don't understand the rules and your enforcement is inconsistent with no written standard to anchor them. If they're too specific, sophisticated bad actors will reverse-engineer them to stay just below the line, and you'll struggle to address new harms that weren't anticipated when the document was written. The right level of detail requires genuine judgment rather than a template.
  • Specificity vs vagueness (by accident): Words like "egregious," "excessive," and "inappropriate" appear constantly in community guidelines and do almost no work. At Musubi, part of what I do is help platforms translate their written policies into something an LLM can actually apply at scale. LLMs don't handle vague language well at all. When you're forced to answer questions like "what does 'excessive' actually mean in this context?" you realise you should have answered them the first time around. That clarity benefits everyone, including your users.
  • Regional vs global: If you're running a global platform, you're constantly navigating the fact that social norms differ significantly across regions and communities. A policy that feels neutral and obvious in one cultural context may be confusing or harmful in another. Most platforms default to global policies for practical reasons, but it's worth being clear-eyed about the tradeoffs.
  • Theoretical vs enforceable: It’s easy to write “ideal” policies that can’t actually be enforced effectively at scale. A policy you can't enforce consistently and fairly isn't actually a policy. It's a document that creates expectations you can't meet, which is often worse than having no written policy at all. Users will notice the inconsistency and lose trust faster than if the rule had never been stated.

What good platform policy looks like

You'll know your policies are working when:

Get access to the rest of this edition of EiM and 200+ others by becoming a paying member