Turning courses, communities and conversations into one navigable system
Designing the information architecture for a community-led learning experience that brings content, conversation and engagement into one model — then translates that model differently across desktop, native mobile and mobile web.
Where it started: the same content, with no relationship between the parts. Nothing here is missing — it is simply unplaced.
Some product visuals have been simplified or reconstructed to protect confidential platform and customer information. Space and community names are synthetic.
Learning was happening in one product. Community was happening somewhere else.
External tools solved a real communication need. The problem was not that educators chose them — it was that the learner had to keep switching context to stay in one course.
Community could not become another destination beside the LMS.
If courses, feeds, discussions, events and chat stayed separate products, adding “Community” to the navigation would only create one more place to understand. The product needed a model that could contain them.
Structured learning objects
Ongoing learner interaction
Events, polls, gamification, live activity
The question wasn’t “how does Discord look?” It was “what job is each navigation pattern doing?”
The community is not a page. It is a container for learning activity.
Many content types. One organising model.
The model wraps existing products, newsfeed and community activity into spaces, rather than placing “Community” beside courses as another isolated module.
One level of grouping was enough.
A space group contains spaces, and nothing nests further. Enough hierarchy to organise; not enough to create navigation archaeology.
Nothing nests further. That is the rule, not a current limitation.
Where something appears depends on who can enter it.
Access is not a permission detail bolted onto the menu. It decides which architecture a given learner can actually see.
Responsive IA does not mean shrinking desktop navigation.
One information model, three navigation contracts. Switch between them — the nodes never change, only where they live and how you reach them.
Where it started: the same content, with no relationship between the parts. Nothing here is missing — it is simply unplaced.
What each contract actually looks like.
The same groups and spaces, hung three ways. Architecture is still the argument; this is what it lands as.
Desktop could keep the structure visible.
Persistent left navigation for groups and spaces, admin-configured destinations along the top, the current space on the canvas, and global system actions always in the corner. Several layers of navigation can be true at once.
Mobile needed a destination for the structure itself.
The sidebar becomes a Spaces page — accordions, one level of grouping, admin-defined order preserved. The top navigation becomes chips on home, and system items become fixed homes.
Familiar UI can carry the wrong mental model.
Borrow the interaction familiarity without borrowing the wrong mental model.
A persistent vertical rail reads as “switch community or server” to anyone who has used Discord.
Discover or jump to promoted destinations. So it gets a different visual treatment, and does not teach the wrong expectation.
Mobile web solved the same IA with a different navigation contract.
A drawer holds everything an admin can configure. A bottom bar holds four things that never move. There is no space tab — all space browsing lives in the drawer.
Four items, in that order, on every school.
Customization should change content, not destroy predictability.
Admins can customize web navigation. If mobile destinations moved around according to each admin’s configuration, mobile IA would become unpredictable per school. So the mapping is deterministic.
Course, Events, Store, space groups and custom destinations. All of it moves into the drawer.
Feed, Notifications, Search and Profile. Thumb reachable, always visible, stable regardless of configuration.
Navigation visibility follows the interaction mode, not the screen.
Moving between peers keeps the bottom navigation. Entering a focused task hands the screen to back navigation. That rule replaced a screen-by-screen list of exceptions.
Two learners, one architecture, different visible product.
Access rules personalise the architecture without changing the model underneath — which is why access had to be designed with the IA, not after it.
The new architecture had to wrap what already existed.
Courses, newsfeed, community and live products kept their capabilities. What changed was their navigational relationship to each other.
Cross-platform consistency does not mean visual sameness.
One extreme is easy to document and fits nothing. The other is native everywhere and teaches a different product on each device.
One content model. Three navigation systems.
Courses, community activity, events, conversations and system destinations were organised into one space-based information model, with explicit mappings for desktop, native mobile and mobile-responsive web. No adoption or retention figure is claimed here.
Same information model. Different navigation contract.
Each platform states its own contract, and none of them re-teaches the product.
What this changed in how I think about information architecture.
IA is a model of the product, not a menu.
Responsive design can keep the mental model while changing the navigation completely.
Customization needs deterministic boundaries, or every customer gets a different product.
Access rules change the architecture a user can see.
What I’d test next
- Usability-test whether the native rail is mistaken for community switching
- Measure success finding a space across desktop, native and mobile web
- Evaluate navigation comprehension for heavily customized schools
- Accessibility audit for drawers, accordions, focus order and mobile navigation
This project taught me that responsive information architecture does not mean shrinking desktop navigation — it means keeping one information model and letting each platform state its own navigation contract.