Design a community website around the member’s journey: understand its purpose, find the right space, join through a clear route and make a useful first contribution. Define membership, content visibility and moderation responsibilities separately. A sign-up form is only one part of the experience; the site also needs understandable boundaries and participation choices.
Start by writing what members will do together. A practical community brief might focus on exchanging knowledge, discussing a shared interest or coordinating an association’s activities. Choose categories and entry points that support that purpose. Keep the first version understandable enough that a newcomer can recognise where to begin without a private explanation from the site administrator.
How should joining differ from viewing content?
Discourse groups can be closed, request-based or freely joinable. The Discourse group guide provides useful documented choices for a community membership example. Decide which route fits each proposed group and who owns it. An open discussion space and an approved-member working group may need different joining experiences within the same website.
Discourse group visibility does not itself grant access to category content. This visibility distinction should shape the requirements. Record whether visitors may discover that a group exists, inspect its member list or read its associated content. Those are separate decisions. A group listed in a directory is not evidence that its discussions have the intended public or restricted access.
Write the expected experience for a visitor, a signed-in non-member and an approved member. Ask each test participant to locate the same category and explain what they can do there. Include direct links in the access test rather than relying only on whether a navigation item appears.
Who should own membership requests?
A request-based Discourse group needs at least one group owner. Discourse group owners receive membership requests with an acceptance or rejection link. The documented request route makes ownership a concrete configuration question. Name the people responsible for membership decisions and the information they need. Keep the application form proportionate to the community’s purpose instead of collecting details merely because fields are available.
Tell applicants what the next step is using facts the organisation can support. Avoid inventing an approval deadline. Write the criteria and exception route through the community’s own governance process, then ask the administrator to show how the proposed software implements the required decision.
Include the unsuccessful request in the design discussion. The person should be able to understand the recorded outcome and any available next step that the organisation actually provides. Keep internal reviewer notes separate from the applicant-facing message, with a permission test for the intended audience.
| Participant state | Question the design should answer | Proposed test |
|---|---|---|
| Visitor | What is this community for? | Find purpose and public participation guidance |
| Signed-in non-member | How do I join this group? | Locate the appropriate joining route |
| Applicant | Who holds my request? | Inspect the configured owner workflow |
| Approved member | Where can I contribute? | Open the intended category and action |
| Volunteer moderator | What responsibility has been granted? | Compare role and effective permissions |
| Departing member | What changes when I leave? | Recheck the intended access boundary |
How should participation and moderation roles be designed?
The Discourse moderation guide recommends welcoming new members. The moderation guide places a welcome within the moderator’s work. Design a useful first contribution prompt alongside the technical joining route. For a knowledge-sharing community, that might ask a member to describe a question or introduce a relevant interest. Treat it as a proposed participation device, not a requirement to disclose personal information.
Discourse Trust Level 3 can allow members to edit titles and change topic categories. Discourse users can be manually promoted to Trust Level 4 with global editing privileges on visible content. These documented trust-level privileges show why helpful participation and editing authority deserve explicit consideration. Record who may contribute, reorganise discussions and edit content. Do not assume that membership of an interest group and responsibility for moderation are the same thing.
Discourse describes its Staff category as restricted to administrators and moderators. Use the documented staff-space example to discuss where administrators and moderators maintain the operating rules. Keep that internal coordination brief here; the website design task is to make roles and boundaries intelligible to members. Detailed incident handling belongs in the community’s moderation procedure.
The Discourse Lounge category is no longer created by default on new sites. Confirm the actual configured spaces rather than building navigation around an assumed default. Give every category a purpose, intended audience and owner. A large category list can look comprehensive while leaving a newcomer unsure where their first question belongs.
Original journey worksheet: a public discussion and a member working group
This hypothetical exercise concerns a fictional gardening community. It has a public questions area and a request-based planning group for volunteers. The purpose is to test discovery, membership and participation without representing a real organisation or claiming any special eligibility rule.
Purpose card. Write a one-sentence description of each area. The public questions area helps visitors understand the topic and find relevant discussion. The planning group supports a defined volunteer activity. Ask a test newcomer to explain the difference using the website’s own navigation and introductory text.
Discovery card. Use a signed-out visitor account to inspect the homepage, group directory and representative category link. Record what is visible, what is restricted and whether the next step is understandable. Keep the expected visibility written beside the observed result. A category hidden from the menu still needs a direct-link check.
Request card. Use an approved test account to request membership of the planning group. Ask the designated owner to locate the request, review the fictional information and record a decision. Inspect the applicant’s experience afterwards. A completed internal decision is insufficient if the applicant cannot recognise their current state or intended next action.
Contribution card. Ask the approved test member to find the planning space and make the agreed sample contribution. Record the available actions and compare them with the design matrix. Repeat with a signed-in non-member. This checks the content boundary separately from whether both accounts can discover the group’s directory entry.
Volunteer card. Give a separate test participant the proposed volunteer role through the configured process. Ask them to identify their responsibilities and show the actions they can actually perform. Keep ordinary membership distinct from any additional editing or moderation privileges. Record an unexpected permission as an unresolved configuration issue.
Departure card. Discourse can show a Leave button when free departure is enabled. Use this documented departure option only where it matches the community’s intended configuration. In the rehearsal, have a test member leave and then revisit the planning area through an existing link. Record the resulting access and the explanation shown to the member.
Handover card. Give the matrix and observations to an administrator who did not create the test setup. Ask them to explain the joining route, content boundaries and role owners. If they need hidden knowledge to maintain the design, improve the instructions before treating the community structure as ready for rollout.
What should the final community website brief contain?
Retain the community purpose, category map, membership routes, visibility choices and participation prompts. Add a named owner for membership decisions and for maintaining the moderation guidance. Keep any unimplemented requirement visible in the brief rather than claiming that a platform’s group feature automatically provides the complete experience.
Connect the worksheet to your website development requirements and any business systems planning. To discuss the design, get started with the participation matrix and the journey observations. That provides a practical foundation for a community whose members can understand where they belong and what they can do next.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.