How to approach one of the first strategic decisions you'll make on any new online community project
You’ve just pulled the trigger and purchased your online community platform. You haven’t invited members yet, but you’re excited—you’re staring at the “empty canvas” of your community platform’s administrator view. You start to click around, adding stuff, naming stuff. You may not realize it yet, but you’ve now entered community architect mode.
Whether you’re an online community entrepreneur or a full-time community manager at a big brand, community architecture is often one of the first important strategic decisions you’ll actually implement as part of a new community project. And yet, the practice and pitfalls of community architecture are wildly under-discussed. Perhaps it’s because “community architecture” is tough to Google without getting articles about city planning or big metal buildings, or perhaps it’s because the specifics of different online community projects make this topic feel hard to generalize.
Whatever it is, it’s time we start talking more about online community architecture (SEO be damned!). In this blog post, I’ll focus on talking through community architecture conceptually, and then shift toward sharing some platform-agnostic best practices, examples, and notes on how to adapt your community architecture over time.
What is online community architecture? (And, a note on content hierarchies)
There’s a good case that the term “community architecture” can encompass pretty much everything in the technical and operational backend of online community work—from choosing a community platform, to configuring it, to setting up integrations with other tools within your community stack.
While I think that’s largely true, for the purpose of this blog post, I’m going to take a narrower approach—I’ll be talking about community architecture mostly as the set-up decisions you make within your community platform. In other words, the user experience you customize for your members based on the decisions available in your chosen platform.
Now is probably a good time to mention that the specifics of community architecture will vary significantly from platform to platform, because of the capabilities and limitations of each tool. For example, Slack doesn’t let you customize much outside of how many channels you introduce into your sidebar and what you name them; whereas more complex enterprise platforms (like Khoros or Insided) may let you customize your top level navigation, host multiple community “home pages,” and vary the format of each page depending on its usage (blog, knowledge base, discussion, etc).
The most useful way I’ve found to think about how community architecture will vary from platform to platform is through the idea of “content hierarchies.” When I say “content hierarchies,” I’m talking about how your chosen community platform nests, organizes, and ranks content. Think about it like a nesting doll: what is the “outer layer” or biggest container for content in your community platform? What’s the smallest? What opportunities for branching and differentiation exist along the way?
Some community platforms have very simple content hierarchies. For example, Facebook Groups content hierarchy looks something like this: Group > Post > Multi-level comment threads. Because this hierarchy is so flat, there aren’t a ton of decisions for the community builder to make about architecture—most Facebook Groups are going to be physically "set up" roughly the same way. Slack’s content hierarchy introduces slightly more complexity: Workspace > Channel Group > Channel > Post > Single-level comment threads. Most of the decisions that differentiate different Slack workspaces architecture from one another happen at the channel level.
Most purpose-built community platforms have more complex content hierarchies than that, not only because of added “layers,” but because of branching options within those layers. For example, the creator-focussed platform Circle has a pretty similar content hierarchy to Slack (Community > Space Group > Space > Topic > Multi-level comment threads), but allows community builders to configure the “Space” level with branching options—community builders can choose forums, calendars, and card-based layouts for spaces.
Generally speaking, the more complex the content hierarchy, the more “decisions” are available for the community builder as they configure their community architecture. And although community architecture varies from platform to platform because of this, generally I’ve found that there are some principles and best practices that translate well across platforms. Let’s dig into those now.
Principle 1: Less is more
The first, and most broadly applicable, principle of community architecture is to resist the urge to over-design. (This urge will be strong—I’m telling you, resist it!).
I think this urge often comes from the desire to “fill the blank page” —when you’re staring at an empty community platform that doesn’t have members filling it with activity yet, a simple community architecture can make the overall space feel sort of flimsy or incomplete. But remember—what's missing is not more complexity in your architecture, it's member activity.
Perhaps counterintuitively, more densely-designed communities can actually lead to more inactivity. Why? I think there are a few key reasons—
Overwhelming your members with options: The more “options” you design into your community experience, the more friction you introduce into your early members’ experience with your community platform. Avoid elongating the decisions they have to make by giving them too many options.
Guessing the wrong “important topics”: Before you launch your community to members, you probably have a loose idea of what they’ll talk about within the space. And your guess might be close to the truth—but even the best community builders are not psychics. Until members are actually in our spaces, it tends to be pretty hard to accurately anticipate what they will want to talk about the most. Because of that, we generally want to keep our community architecture simple and broad enough at first that it’s able to accommodate different possible realities when we actually open the doors—from there, we can adapt to our community members’ demonstrated interests rather than anticipating them.
Artificially splitting the conversation: Any time you introduce a new “room” in your community, you are breaking down the conversation and thus raising the bar for the community to feel lively. Think about your community like it’s a house party—if you’re only inviting ten people, you want them all in one room. If you send those ten people out into ten different rooms, there’s going to be no interaction because of sheer numbers. Make common-sense decisions about how to split your conversation based on the actual size of your community and adapt as you grow.
While “rules of thumb” always have limitations, a good way to keep yourself honest and on track is to limit yourself to 5-10 visible “choices” for your community members, whatever that means on your specific community platform. So for example, in Slack, that would mean no more than 5-10 channels, in a more complex platform that might mean no more than 5-10 different places to click into on your community’s home page (including top-level navigation and whatever else is visible on the page).
Principle 2: Break up the conversation based on how, not what
Now that I’ve told you not to over-complicate your community architecture by introducing too many different options, you’re probably wondering what to actually prioritize into your build. A good way to think about that is to think about breaking down your community into different spaces based on how your community members will interact and not what your community members will be discussing.
Let’s think about this again in the context of a physical space. If I’m inviting people over to my house for dinner, I’m definitely not going to make them introduce themselves in one room, then come into the kitchen if they want to talk about their kids, and then make some of my guests go into another room if they decide they want to talk about work. That just doesn’t make sense, and what’s more, it actually prevents my members from interacting with each other. So, why do we reproduce this farce in online communities so often by creating sidebar navigations that list out all the potential topics for discussion in the community? There is often no compelling reason, even in online communities, to suggest people go into different rooms to discuss different topics.
A more sensible way to think about where conversations need to be broken up, that’s not topic, is format. In a physical space, the analogy might be—if half of my guests are drinking wine from expensive stemware and half of my guests are playing Twister, I might send the Twister players into another room so they don’t elbow-knock a glass of Chablis.
In a community setting, an equivalent to an “elbow knock” might be two different formats of conversation that feel like they’re pushing and pulling at one another: for example, open ended conversations about best practice might feel like they don’t belong in the same “room” as folks sharing and asking questions about job postings, because the latter often needs to go in a specific format and the former might “bury” important listing and make them hard to search.
So, instead of trying to anticipate every single topic your community members could discuss and having that dictate your architecture, consider the different ways community members will interact and which ones can coexist in the same space, or might need their own. This distinction will generally yield a simpler architecture than trying to build based on topic.
Principle 3: Use simple and obvious nomenclature
The final, and perhaps most controversial, best practice I have to share is about nomenclature, or what you name your various discussion spaces and navigation tabs within your community architecture. I see a lot of community builders who are drawn to incredibly brand-specific nomenclature for their various community spaces: for example, a mountain-climbing community calling their discussion space “base camp” and their resource libraries “gear kit,” or a professional community calling their discussion space “water cooler” and their onboarding area “Human Resources.”
While these kinds of branded naming conventions can be tempting, I tend to suggest that folks avoid them because they add unnecessary complexity and friction to your members’ early experiences with your community. You want your members to be able to quickly understand where to go in your community to begin interacting, without spending unnecessary time reading explainers, parsing translations, or clicking around to try to understand what’s happening where. To me, the antidote to this is to use simple, obvious nomenclature—i.e., name the main discussion space something like “conversation” or “discussion.”
I do think there's a case for making very scant use of "insider language" in your community, as long as it doesn't dominate your build or make the architecture overly confusing. My colleague Bri Leever makes that case well here in a post on LinkedIn:
Examples of community architecture in different platforms
To help understand how different online communities apply community architecture best practices, let’s take a look at a few examples.
Example 1 — The Community Center on Circle
First, let’s take a look at my client community, The Community Center (available to my 1:1 clients and On-Demand Coaching clients).
This community is hosted on Circle. Notice that it employs fewer than 10 options in the left hand sidebar (the primary option for customization in Circle), contains no ‘topic-based’ discussion areas, and employs no branded nomenclature that couldn’t translate easily to another community with another topic.
I also did a video walk-through of my community that explores architecture best practices a while back that you can check out here:
Example 2 — The Community Community on Slack
Next, let’s take a look at a professional community I’m part of, The Community Community. It’s a Slack community for senior-level professional community builders.
This community shows a great example of how architecture starts simple and then expands over time. Notice that it largely contains topic-agnostic channels that focus on how and not what members communicate about (i.e., announcements, general, events, etc). However, over time as discussions grew and themes emerged, it added channels about specific topics that were busy enough to warrant their own channels: "vendor talk" and "executive communication." Nonetheless, the community maintains under ten options for new members and makes topic-based discussions optional.
Example 3 — The Hearth on Heartbeat.chat
Lastly, let’s take a look at the customer community for community platform Heartbeat.chat (hosted on the same).
Heartbeat has a slightly different content hierarchy than the examples listed above, and makes use of it to organize their community based on what members are doing (i.e., “how”—get help vs. get inspired). They also make use of an opt-in-based interest group system that allows you to keep your own sidebar clean while giving you options to connect over more niche topics.
(For users of Discord—a colleague of mine in the community industry, Matt Cool, shared this article which features some screenshots of a Discord architecture as well).
Closing thoughts & adapting your architecture over time
I hope you’ve found this post helpful! Whenever I talk about community architecture, I always like to leave with the reminder that great community architecture may be your first, but it’s not your only chance to show members what happens in your community and to model great interactions. Great community architecture will do little without being paired with a good engagement plan and onboarding plan, and vice versa.
It’s also worth noting that community architecture can and should adapt to your community as it grows. Like I noted in the example with The Community Community, as communities become bigger and conversations start to play out, you may feel the need to start to introduce more complexity, or topic-based channels, that seem to fly in the face of some of these best practices. The good news that most purpose-built community platforms have tools you can use to continue to mitigate overwhelm for your members even as you grow. Make use of tools and strategies like:
Introducing tiered or persona-based community experiences: In other words, as your community grows, make it so different members see different things based on their persona (level, interests, etc).
Introduce locked, invite-only, or opt-in based experiences: Like we saw in the Heartbeat.chat example, whenever you do introduce topic or niche groups to your community experience, keep them on an opt-in basis so that they don’t crowd the architecture for new members.
“Promote” or “demote” your content hierarchies: As communities grow, sometimes there is a need to reassess what type of content is scoped to what content hierarchy level. This tends to be especially true with communities that host lots of content and resource libraries. Where it may initially be appropriate to have different spaces for different types of resources that are visible from your top level navigation, you may reach a point of expansion where that becomes overwhelming. Introducing macro categories on your top-level nav like “resources,” and then pushing the more specific resources down a level (into posts, or linked out to a separately organization resource library) can help you avoid overcrowding your architecture as your resources grow.
—
Want to take any of this a step further?
I hope this post has been helpful for you and given you a strong start to thinking through your community architecture. That said, I understand that this can be complicated , and sometimes you need a hand to help put it all into practice. The reality is that no matter how comprehensive a post I try to make, there will still be lingering questions that apply to specific projects.
I work with clients every day as a strategic coach for online community projects, and community architecture is one of the most common topics my clients want to discuss. If you would like to work together 1:1, you can learn more about how I work and get in touch here.
For folks who want to deepen their community work but don't have the budget to work with me 1:1, I also offer an online program called the On-Demand Coaching Core Bundle—it distills the most common topics I work with my 1:1 clients on into a self-paced format with videos, my most in-depth templates, coaching scenarios, and a client community with bi-weekly group coaching. All of that comes for a one-time purchase of $500 USD, less than the cost of 2 1:1 coaching sessions with me. You can learn more about that here or enroll now below:
You're also always welcome to shoot me an email at noeleflowers@gmail.com if you have questions, suggestions for what I should add to this or other blog posts, or anything else you'd like to discuss. I love hearing from readers—thanks again for being one!
Comments