Designing Community Guidelines That Guide, Not Forbid — Wording Patterns That Change Behavior

When guidelines don’t work, the issue is the wording, not the items

We frequently hear from community operators that they put guidelines in place but violations don’t drop, no one reads them, and operational judgment keeps wavering. In most cases, the root cause is not a missing item (forbidden conduct, copyright, reporting procedures, etc.). The items are sufficient — the wording itself isn’t doing the work.

Phrases like “forbidden,” “prohibited,” or “shall not under any circumstances” may be legally correct as warning language, but they are weak at changing participant behavior. Participants skim them as “fine print that doesn’t apply to me,” and the existence of the guideline never connects with their actions.

This article focuses exclusively on “how to write” after “what to include” is decided. It covers five principles of wording design and a copy-paste NG/OK comparison set. The items themselves (how to divide terms of use and guidelines, the mandatory sections) and the mechanisms for placing the wording on operational rails (signup-time agreement, violation response, periodic review) are separate layers. This article handles what sits between them: the design of the words themselves.

The idea of “managing guidelines as code” is covered in Expressing Community Operation as Code — Implementing Policy, Moderation, and Invite Flows on Slack. This article zooms into the actual prose you write inside those Markdown documents for terms and codes of conduct.

Principle 1: “Let’s do X” rather than “Don’t do X” — think in forbid/recommend pairs

When you write a line of guideline, make it a habit to draft the same intent in both forbidden and recommended forms. The recommended form is usually shorter, easier to remember, and easier to operationalize.

The forbidden form has two weaknesses. One is that anything not explicitly forbidden gets read as fully permitted. The other is that violation judgment becomes binary (violation / not violation), which rigidifies the threshold for operator intervention. The recommended form preserves a gradient of desirability, allowing the operator’s casual nudge (“a bit more background would probably get you more responses”) to work naturally.

That said, there is an exception where the forbidden form is the right choice. For domains where no gradient should exist — discriminatory speech, illegal acts, direct attacks on others — write them explicitly as forbidden. “Guide rather than forbid” is a principle, not an absolute rule.

Principle 2: Drop to the behavioral level — throw out “politely” and “with restraint”

“Please communicate politely.” “Please post with restraint.” “Treat communication with sincerity.” These sentences say nothing. Abstract words are concrete in the writer’s mind but leave the reader unsure what to do. The result: participants don’t realize they’re violating anything until the moment an operator declares “that wasn’t polite.”

When you spot an abstract word, rewrite it as “specifically, what action?” in one line.

Dropping to the behavioral level has three benefits.

1. Participants can act on it on the spot. “Be polite” leaves them at a loss; “quote before replying” is immediately executable.
2. Operator judgment stabilizes. Interpretations of “not polite” differ by person, but “didn’t quote” lands the same way for anyone reading.
3. You can have a conversation about revision. With abstract words, you can only escalate to “please be more polite.” With behavioral phrasing, you can say specifically “the quote rule isn’t working in three channels.”

Abstract words are beautiful but non-functional. A guideline is not a poem; it’s an instruction manual.

Principle 3: Hand the subject from the operator to the participants

The pattern that slips into guideline writing most unconsciously is sentences with the operator as subject: “We prohibit…,” “Operations reserves the right to…,” “This community requires…” There are scenes where this voice is needed for legal documents, but when the main body of a code of conduct is dominated by it, participants come to perceive “this is the operator’s place and I’m an invited guest.”

Handing the subject to the participants makes the writing markedly closer.

Handing over the subject gives the guideline a different character: not a notice from the operator to participants, but a shared agreement among participants. Combined with Principle 1 (guide rather than forbid) and Principle 2 (behavioral level), the effect compounds.

However, do not hide the fact that the decision-maker on violations is the operator. Make the locus of responsibility clear, as in “we’ll take the judgment from there.” Leaving it vague guarantees fights over “who decides” when trouble hits.

Principle 4: Always add an exception and an example — three lines of examples for every one line of rule

If you write a rule in a single line, the reader stops at “okay, but what does that mean specifically?” For each rule, attach at least one example and ideally one exception. This single move turns a guideline into “something people actually read.”

Example:

Promotion is welcome, in a form that fits the context.

• OK example: “This is an announcement for a study group I’m running. We’ll be covering the topic ◯◯ that’s been discussed in this community.”
• NG example: “[URL] please take a look.” (No background, no relevance shown.)
• Exception: Adding SNS links to your self-introduction in the introduction thread is fine without context.

Adding examples and exceptions does increase the character count of the guideline. But the probability that participants can self-judge “which case is mine?” rises sharply, and the number of questions to operations and the number of violation responses drop as a result. Short rules, thick examples is the writing style that minimizes operational load.

Principle 5: Write violation consequences plainly, not as threats

When the bottom of a guideline reads “violators will be banned” or “may be deleted without warning,” participants tense up. The existence of violation response is necessary, but the threatening tone has a side effect: it shrinks the healthy participants the most.

The violation-response section starts to function when you separate three things and write each plainly.

1. What happens (fact): “Posts may be deleted.” “Operations may reach out via DM.”
2. Who decides (responsibility): “Decisions are made by the operations team (◯◯ and ◯◯).” “Serious cases are decided by three or more people.”
3. Is there room for appeal (transparency): “If you disagree with a decision, you can request reconsideration via ◯◯ form.”

Replacing “punishment,” “prohibition,” and “permanent ban” with “response,” “request,” and “reconsideration” alone changes the temperature of the text significantly. Keep the rigor of the decision while lowering the temperature of the text. That’s how you make rules work while keeping operator credibility intact.

Inclusive wording — review who “everyone” is excluding

As participants become more diverse, you’ll find spots in your guideline that unintentionally exclude someone through wording. This isn’t a “political correctness” question — it’s a purely operational question of whether someone reading the guideline feels “this is a place for me.”

A review checklist:

• Phrasing that assumes gender: prefer “anyone of any role” over “men and women alike”; “that person” over “he/she”
• Phrasing that assumes age/experience: prefer “regardless of experience” over “you young folks” or “veterans”
• Phrasing that assumes nationality/language: prefer “as the main language” over “as Japanese people” or “everyone in Japanese”
• Phrasing that assumes family structure: prefer “alone or with company” over “with your family” or “with your kids”
• Phrasing that assumes physical ability: prefer “those who are able to” over “stand up” or “those who can see”

You don’t need to rewrite everything. Have multiple people review whether someone you want in your community would read the guideline and feel “I’m being excluded.” That alone sharpens the wording significantly.

Layout and placement choices that get the guideline read

This is a layer apart from wording design, but placement changes how a document is read. The same text, placed badly, may as well not exist.

• Embed it into the join flow: don’t just park it on a separate page — make a “did you read this?” checkbox mandatory at signup
• Use questions as headings: “What do I do when I’m in trouble?” beats “Forbidden Conduct”; “What can I post?” beats “Posting Rules”
• Put a table of contents at the top: even if it reads in three minutes, jumping to the item you care about changes arrival rate
• Put the update date and changelog at the top: knowing “which version am I reading” raises trust
• Pin the link in channels: pin a single URL to the guideline rather than pinning the body text

These connect to the “deliver as a documentation site” idea covered in Expressing Community Operation as Code. Once the wording is in shape, design the delivery side as a continuous piece. That’s the proper flow.

Summary — wording design is the community’s first impression

For a new participant, the first “operator’s voice” they encounter is, in most cases, the guideline. The temperature of the wording is read as the temperature of the operations team.

The five principles, one last time:

1. “Let’s do X” rather than “Don’t do X” — make the recommended form the default
2. Drop abstract words to the behavioral level — throw out “politely”
3. Hand the subject from the operator to the participants — agreement, not notice
4. Three lines of examples for every one line of rule — thicken examples and exceptions
5. Write violation responses plainly, not as threats

These are individual writing techniques, but the underlying idea is one: a guideline is not for “making people comply” — it’s for “letting participants decide their own actions.” Expose the operator’s thinking process in words, and let participants use it. Reframed this way, a guideline shifts from a management tool to the community’s culture itself.

A rewritten guideline starts functioning only once it is placed on operational rails — agreement at signup, escalation flow for violations, and periodic review. Wording design and operational design are two wheels of the same cart.

If you’d like accompaniment on designing your community’s guidelines, please consider Rokuse’s community support service.

Related articles

Expressing Community Operation in Code — Implementation Patterns for Policy, Moderation, and Invite Flows on Slack

We explain implementation patterns for declaratively managing operational policy, moderation, and invite flows in code on top of Slack. We show concrete file structures, automation designs, and a phased adoption path for moving from person-dependent operation to a reproducible system.

rokuse.com/en/blog/community/community-as-code-slack

Why Community Operations Need Context Design First

Before adding more initiatives, define the context, paths, and operating rhythm your community needs. This article explains, from a practitioner's perspective, why context design comes first.

rokuse.com/en/blog/community/why-community-needs-context-design

Three Things to Decide Before Launching a Corporate Community

We unpack the root cause of why "communities started on a vague impulse" fail, and explain the three things to nail down before launch — purpose, audience, and business connection.

rokuse.com/en/blog/community/before-starting-corporate-community

How to Choose Community KPIs and Tips for Running Them — Five Representative Indicators and Their Pitfalls

We organize the KPIs to track in community operation across five views — scale, activity, relationships, business contribution, and operational health — and explain how to choose them and the pitfalls to watch in operation.

rokuse.com/en/blog/community/community-kpi-guide