Your association website probably has an About section, a Membership section, a Programs section, and an Events section. One box for every department on the org chart. The problem is that members do not think in departments. They show up with a task: renew, register, find a CE credit, reach a human. This post shows how to rebuild your association website information architecture around member tasks instead of internal structure.
Why your org chart is the worst possible sitemap
The org chart is an honest map of how your staff thinks. It is a terrible map of how your members search.
The org chart is an honest map of how your staff thinks. It is a terrible map of how your members search.
Department-based navigation is inside-out thinking. The menu reflects how the organization is arranged internally. It does not reflect how members behave when they land on the site. Nielsen Norman Group names this the foundational error in website architecture: you are not your user. Your communications director knows that CE credits live under Professional Development. Your average member does not.
Here is the concrete failure. A member needs to find their CE transcript. On most association websites, that page could live under “Education,” “Professional Development,” “Certification,” or “Member Resources.” Every department boundary the member has to learn is a tax on a task they already wanted to complete. That tax shows up as support tickets, abandoned renewals, and event revenue left behind because the registration path was buried three levels inside the Programs section.
An association site is not a typical business website. A commercial site organizes content around a product line with a defined customer journey. An association serves members at five or six lifecycle stages simultaneously: prospect, new member, renewing member, chapter leader, lapsed. The same navigation has to work for all of them. Department logic cannot handle that.
Fixing this is part of our broader association website strategy. Not a cosmetic fix. Not a menu reorganization that keeps the same buckets and shuffles the labels. A structural change: replace department logic with task logic.
How to rebuild association website information architecture around members
The six steps below are a sequence, not a menu of options. Run them in order.
Step 1: Map the real member tasks before you touch the menu
Start by listing the top 15-20 things members actually come to the site to do. Renew. Register for an event. Find a CE credit. Update a chapter roster. Download a member benefit. Reach a staff person. Pull this list from AMS support tickets, site search logs, and the renewal and help inbox. Not from a staff brainstorm.
The reason to start from tasks is that navigation should encode what members do, not what departments want to surface. Start from the existing menu and you inherit the org chart. Start from tasks and you build the member’s mental model into the navigation structure. This is the only model that matters when someone lands on the homepage with something to accomplish.
The common mistake: asking departments what they want on the site. Every department says “us, prominently.” You end up back where you started.
Step 2: Run a card sort to learn how members group those tasks
Take each task from Step 1 and put it on a card. Run an open card sort with 15-20 real members. Let them create their own groups and name those groups in their own words.
Card sorting is generative. It does not tell you how members should organize tasks. It tells you how they already do organize them.
Card sorting does not tell you how members should organize tasks. It tells you how they already do organize them.
The words members use to name the groups are almost never the words on your staff directory. “Benefits” might become “Things I Get as a Member.” “Professional Development” might become “Courses and Credits.” Optimal Workshop and Digital.gov both publish open-source card-sort guides if you are running one for the first time. The point is not the tool. It is who is in the room: members, not staff.
The mistake to avoid: running a closed card sort that uses your existing department names as predefined buckets. That confirms the structure you are trying to escape. Open or hybrid only.
Step 3: Draft a task-based top-level navigation of 5-7 items
Collapse the card-sort results into 5-7 top-level labels written as member outcomes. “Join & Renew.” “Events & Learning.” “Member Resources.” “Advocacy.” “About.” Use a mega-menu for depth. Do not add more top-level items to handle breadth of content.
Five to seven is a ceiling, not a preference. Kanopi’s research on high-performing association websites and Wired Impact’s nonprofit navigation studies both find that short, action-oriented top-level structures outperform long menu bars for task completion. When the top level is short and the labels name what members do, members find what they need.
This is also where how we approach association website design becomes concrete. The visual execution of member-centered navigation requires the IA to be right first. No amount of visual hierarchy fixes a menu organized for staff rather than members.
The mistake: 9-12 top-level items because each department insisted on visibility at the top level. The org chart wins again. Hold the 5-7 ceiling. That is a governance decision, not a design preference, and it requires someone with authority to enforce it.
Step 4: Validate the new tree with tree testing before you build it
Take the proposed navigation tree with labels only (no design yet). Run a tree test. Give real members a specific task (“find how many CE credits you have”) and measure whether they navigate to the correct destination using only the labels.
Card sorting generates the IA. Tree testing proves it works. Nielsen Norman Group documents this distinction directly: card sorting is generative, tree testing is evaluative. Run them in sequence. Neither replaces the other, and skipping tree testing is how associations spend six months building a navigation their members still cannot use.
The common mistake is launching on staff consensus instead of member validation. The failures surface in production as bounce rates and support tickets. The tree test is faster and much cheaper than that.
Step 5: Wire the AMS in so navigation can adapt to who is logged in
Integrate the AMS with the CMS via REST API and SSO so a logged-in member sees their renewal status, CE transcript, and upcoming registrations without re-authenticating. Build a personalized member dashboard as a first-class navigation destination. Do not bury it as an afterthought in a dropdown.
Task-based IA improves the generic experience. AMS integration makes it personal. A lapsed member and an active chapter leader need different first screens. The site can serve both only if it knows which one it is talking to.
I have seen association websites with solid static IA fail at exactly this step. The SSO works. The member logs in. But the dashboard still links out to generic department pages, so the personalization ends at the authentication screen. Test the full task path before you call the integration done. Verify not just whether login succeeds, but whether the member experience actually changes after login. i4a and New Target both document integration patterns for the major AMS platforms. SSO is not a phase-two feature. A redesign that ignores the AMS handoff just builds a better-organized org chart.
Step 6: Name pages for member journeys, not internal owners
Rename every page label to the task it serves. “Office of Professional Development” becomes “Earn & Track CE Credits.” “Membership Services Department” becomes “Join & Renew.” Map every label to a stage in the member journey: prospect, new member, renewing member, volunteer.
Labels are the smallest unit of IA. They are also where org-chart language seeps back in after launch. A committee chair lobbies to add their committee’s name to a page. A staff director renames a breadcrumb to reflect their department title. Within 18 months the task-based structure is half-buried under org-chart language again.
The fix is a rule, not a design decision: every page label must answer the question “what does a member do here?” If the label answers “which department owns this?” instead, rename it.
The argument you will hear for keeping department names: “the board calls it that.” The board is not your primary website user.
Where member-centric IA quietly reverts to the org chart
Getting the IA right at launch is one problem. Keeping it right afterward is a different one, and most guides skip it entirely. Here are the four failure modes I see most often.
Governance creep at launch plus six months. Each department lobbies to add “their” page back to the top navigation. A new committee forms and someone decides it deserves a top-level item. Within a year you have 11 menu items. The fix: assign one person as IA owner, establish a rule that adding a top-level item requires removing one, and hold the line on both counts. No exceptions.
The AMS handoff that looks integrated but is not. SSO works. The member logs in. But the logged-in dashboard still links out to generic department pages, so personalization ends at the authentication step. “Does SSO work?” and “does the member experience actually change after login?” are different questions. Test the full task path before you call it done.
Card sort run on staff instead of members. Convenient. Worthless. Staff already share the org-chart mental model you are trying to break. They sort tasks into department-shaped buckets without realizing they are doing it. Run the card sort on members, or do not run it at all.
Search treated as a substitute for IA. “Members can just search” is what teams say when they have given up on the navigation. Search is a fallback for when structure fails. It is not a replacement for it. Good IA reduces the searches that should never have been necessary. If members routinely search for “member login” or “how to renew,” that is an IA problem, not a search problem.
When the IA is too fragmented to retrofit on the existing site, the structural solution is an association website redesign that builds the navigation from member tasks up, not from the org chart down. This pattern of skipping IA work and migrating the old structure to a new design is one of the clearest explanations for why so many association redesigns fail. The problems that made the old site unusable travel intact to the new one.
Frequently Asked Questions
What is information architecture for an association website?
Association website information architecture is the underlying structure that determines how pages are organized, labeled, and connected so members can navigate from intent to task completion. It is the hierarchy, the navigation model, and the page labels together. This is not the visual design, but the structural logic underneath it. Getting the IA right before design work starts determines whether the navigation serves members or serves departments.
Why shouldn’t an association website be organized by department?
Because members do not know or care how your organization is structured internally. They arrive with a task: renew, find a CE credit, register for an event. They have no knowledge of which committee or department owns which page. Department organization is efficient for staff who already share the mental model. For members who do not, every department boundary is a navigation obstacle. The navigation should encode what members do, not how staff are arranged.
How many top-level navigation items should an association website have?
Five to seven. Research on association and nonprofit website navigation consistently finds that a short, action-oriented top-level structure outperforms longer menu bars for task completion. Use a mega-menu to handle depth behind those items rather than adding more top-level entries. More than seven top-level items usually means a department won the negotiation at the member’s expense.
What is the difference between card sorting and tree testing?
Card sorting is generative. You use it to discover how members group and name tasks, which gives you the material for a navigation structure. Tree testing is evaluative. You use it to verify that a proposed structure works under real member tasks. Run them in sequence: card sort first to build the structure, tree test to validate it before you build anything. One without the other leaves half the question unanswered.
How does AMS integration improve website navigation for members?
When the AMS and CMS share data in real time, a logged-in member’s experience reflects their actual status: renewal due date, CE credits earned, upcoming registrations, chapter role. Instead of a generic static menu, the member sees navigation relevant to where they are in the member journey. Without AMS integration, task-based IA delivers a better generic experience. With it, the experience becomes personal.
How long does it take to restructure an association website’s information architecture?
The research phase (member task mapping, card sorting, tree testing) typically runs six to eight weeks with access to a participant pool and someone facilitating the sessions. Restructuring the navigation in the CMS once the IA is validated takes days, not weeks. The timeline is dominated by the research, not the implementation. Skipping the research to save time produces a faster launch and a slower member experience.
Do we need to redesign the whole site to fix the information architecture?
Not necessarily. If the CMS supports relabeling and reorganizing pages without a full rebuild, you can apply a new IA to an existing site. The risk: the current design was built to reinforce the current IA, and some of those design decisions will resist the new structure. A full association website redesign gives you clean architecture from the start. A navigation retrofit is better than doing nothing, but expect friction at the seams.
Before you spend a redesign budget recreating the org chart in a new skin, audit your IA against member tasks first. If the navigation you are planning still answers “which department owns this?” more often than “what does a member do here?”, the redesign will not solve what it set out to solve.