An association website is not a marketing site with a login bolted on. It is the front end of a membership business: joining and renewal, dues and invoicing, member directories, chapters and committees, events and continuing education, a job board, and content that is public for some readers and gated for others. Most of the cost and nearly all of the risk in these projects sits in the systems behind the pages rather than in the design, which is why associations so often accept a beautiful proposal and then spend a year fighting the integration. This page describes what the work actually contains, what drives the price, the accessibility obligations that apply, and how to compare agencies on evidence.
The membership system decides the project
Before anything visual is discussed, one question governs the whole engagement: what association management system holds your members, and how will the website talk to it? Some systems come with their own website builder, which is cheap and constrains design heavily. Some expose a modern interface that a competent developer can build against cleanly. Some expose almost nothing, and the honest answer is a nightly synchronisation with a compromise on what members see in real time. That choice determines whether single sign on works, whether renewal happens on the website or in a separate portal, and whether the directory is live or a stale copy. Ask every candidate agency which systems they have integrated, by name, and to describe a specific problem they hit. An agency that has never named a system in the conversation has not scoped your project.
Accessibility is a duty, not a feature line
Associations frequently serve members in ways that engage accessibility obligations, and public facing membership organisations are a common target for complaints. The Department of Justice publishes guidance on web accessibility and the Americans with Disabilities Act which explains that inaccessible web content can prevent people with disabilities from accessing goods and services, and points to recognised technical standards as the practical way to meet the obligation. For a buyer the important part is procedural: accessibility built into templates during a project costs a fraction of a remediation done afterwards. Put it in the specification, ask which standard and level the agency builds to, ask who tests and how (automated tools alone are not sufficient), and ask for the accessibility statement to be part of the delivery rather than something you write later.
What moves the price, and how to compare quotes
Five things drive an association web quote: the number of integrations, the depth of the membership functionality, content migration volume, whether events and education are transacted on the site, and how much of the content someone has to rewrite. Design hours are rarely the biggest line even though they dominate the pitch. Ask each candidate to split the estimate into discovery, design, build, integration, content migration and post launch support, and compare those lines rather than totals. Two proposals with the same number can hide a threefold difference in integration hours, and the one that underquotes that line is the one that produces change orders in month five. Ask also what the annual cost of ownership looks like, since these sites need continuous maintenance and someone has to be paid to do it.
Search, speed and the members who never log in
Most association sites are judged internally on the member experience and externally on nothing at all, which wastes their largest audience. Non members searching for a credential, a standard, a directory of practitioners or an event are exactly the people you want to convert into members, and gating everything makes you invisible to them. A sensible model keeps genuinely valuable public content indexable, gates the parts that carry real member value, and keeps page speed acceptable, which the Core Web Vitals metrics documented by web.dev measure in a way you can hold an agency to. This is where a web design engagement and search services overlap, and it is worth agreeing in the specification who is responsible for redirects, titles and site structure at launch rather than discovering afterwards that nobody was.
Questions people ask about association website design
Should we redesign the site or replace the membership system first?
Almost always the system first, or at least decide it first. Building a website against a system you are about to replace guarantees rework, and the constraints of the system shape what the site can do. If both are due, run one discovery covering both and sequence the system, then the site, with the same team aware of both.
How long does an association website project take?
Six to twelve months is typical once membership integration, content migration and volunteer governance are involved, and the governance is frequently the slow part. Board and committee review cycles add weeks that no agency controls. Ask for a schedule that names your decision points and who must approve each one, and treat any proposal that ignores your approval process as optimistic.
How much content should be public?
Enough that a prospective member can see the value before joining, and enough that search engines can find you at all. A common working split keeps advocacy, standards summaries, event listings, directories and introductory education public, and gates full standards documents, archives, member data and continuing education credit. Review the split with a member value lens rather than a reflex to gate everything.
Who should own the site after launch?
You should own the code repository, the hosting account, the domain, the analytics property and the content, with the agency added as a user. Agree a maintenance arrangement covering security updates, dependency updates and a monthly block of change time. Association sites decay faster than most because staff turnover is high and nobody inherits the passwords.