Website Redesign Checklist for Montana Nonprofits and Community Organizations

Most nonprofit website projects I've seen in Montana don't stall because of design. They stall because the board, the director, and the staff haven't agreed on what the site is for, who writes it, and who gets the final say. This checklist is the work to do first, before you talk to a designer, write any copy, or ask for a proposal. It's the same list I'd walk through with you on a first call.

Start with goals, not design

Who actually needs this website?

Before discussing colors, layouts, or platforms, your organization needs to agree on who the website is actually for. A nonprofit website typically serves several distinct audiences:

• Community members or program participants
• Funders and grant-makers
• Partners and collaborators
• Potential staff or volunteers
• The general public
• Board members

These audiences have different — and sometimes competing — needs. A funder visiting your site wants to understand your impact and financial accountability. A community member looking for services needs to find them quickly, on a phone, without friction. A prospective volunteer wants to know what the commitment looks like and how to get started.

Listing your audiences is not enough. Your team needs to agree on which audiences are the highest priority, because that decision will shape every significant design and content choice that follows.

What actions matter most on this site?

What do you want people to do when they visit your website? This sounds like a simple question. It rarely is.

Common goals include: apply for a program, make a donation, contact the organization, find a resource or service, locate a physical location, or register for an event. Most organizations want all of these things — but without agreement on which actions matter most, design decisions become arguments without shared criteria. One staff member wants the donation button prominent. Another wants the program finder front and center. Without a prioritized answer to this question, both conversations stall.

Decide together. Write it down. Bring it to the project.

What is currently hard to find or missing?

If your organization has an existing website, review its analytics before starting a redesign. Which pages get the most traffic? Where do visitors drop off? What search terms are bringing people to your site?

If analytics aren’t available — or aren’t useful — ask your staff a simpler question: what do people call or email about that the website should already answer? Front-line staff and program coordinators often know exactly what’s missing. That knowledge is worth more than a design trend.

Content clarity and ownership

Content is where most website projects quietly fall apart. Organizations focus on design and functionality, then discover — often weeks into the project — that the content isn’t ready, isn’t accurate, or doesn’t have a clear owner.

Before your redesign begins, work through these questions:

What needs to be updated before the project starts? Carrying outdated content into a new site doesn’t fix the problem — it just gives it a fresh coat of paint. Staff bios, program descriptions, service locations, contact information, and annual reports should be reviewed and updated before a designer ever sees them.

What can be removed or significantly simplified? Most organizational websites accumulate content over time — pages added for a specific grant cycle, a program that no longer exists, or a staff member who left years ago. A redesign is an opportunity to simplify, but only if someone is willing to make those decisions.

Who owns each section of the site? Every section of your website should have a named person or team responsible for keeping it accurate. What happens to sections with no clear owner? That question needs an answer before the project begins, not after launch.

A Montana example: for the Montana Native Growth Fund, a Native-led CDFI on the Fort Belknap Indian Reservation, I built the site on a content editor (Sanity) so staff can update programs and news without calling a developer. A setup like that works best when someone on the team clearly owns those updates.

Will content actually be ready when the designer needs it? Content delays are one of the most common reasons website projects miss their deadlines. If your team is already stretched thin, be honest about that. A realistic content timeline is part of a realistic project plan.

Internal governance and decision-making

This is the section most organizations skip — and the one that causes the most problems.

Website projects involve a lot of decisions: what to say, how to say it, what to show, what to leave out, which feedback to act on, and which to set aside. Without a clear governance structure, those decisions get made slowly, inconsistently, or not at all.

Before your project begins, your organization should be able to answer these questions clearly:

Who has final approval authority? On content decisions. On design decisions. Are those the same person? If the executive director and the board chair have different opinions about the homepage, who decides?

How will disagreements be resolved? Not if — when. Disagreements about organizational websites are normal. The organizations that handle them well have a process. The ones that don’t tend to end up with projects that drag on for months while everyone waits for someone else to make a call.

Who will maintain the site after launch? This is not a small question. Does that person have the access, the tools, and the training to make updates independently? Have they been involved in the project from the beginning, or will they be handed a finished site and expected to figure it out?

What happens when that person leaves? Staff turnover is a reality in every organization. If your website’s maintainability depends entirely on one person’s institutional knowledge, that’s a risk worth addressing before launch.

Undefined governance is one of the most reliable predictors of a website project that stalls, misses its deadlines, or launches a site that becomes unmaintained within a year.

Technical considerations in plain language

You don’t need to be a developer to think through these questions. You do need to have answers — or know who in your organization does.

Accessibility. Does your site need to comply with accessibility standards such as WCAG 2.1? Is this a funder requirement, a grant condition, or a legal obligation? Beyond compliance, accessible design benefits community members with disabilities, older adults, and anyone using assistive technology. It’s worth asking who in your community is currently excluded by an inaccessible site.

Mobile usability. Many community members and program participants access websites primarily on mobile devices. If your site isn’t easy to use on a phone, it isn’t easy to use for a significant portion of your audience.

CMS editing needs. Can program staff update content — add an event, change a phone number, post a news item — without involving a developer? If not, that’s a real operational cost. Your content management system should match your team’s actual capacity.

Forms and integrations. What does your site need to connect to? Donation platforms, event registration tools, contact forms, program applications, email lists. Each integration adds complexity. Know what you need before you start.

Privacy. If your organization serves vulnerable populations, collects sensitive information, or works with minors, your website’s privacy practices matter. This includes what data is collected through forms, how it’s stored, and who has access to it.

Hosting and domain ownership. Who actually controls your domain name and hosting account? This is a surprisingly common problem — organizations discover mid-project that a former staff member, a board member’s nephew, or a vendor from five years ago holds the login credentials. Resolve this before the project begins.

Analytics. Can your organization measure what’s actually working on the site? Basic analytics — page views, traffic sources, form completions — are essential for making informed decisions after launch.

Project readiness

Even well-aligned organizations can run into project delays when the practical logistics haven’t been worked out. Before you engage a vendor, be clear on the following:

Budget range. Is your anticipated budget realistic for the scope you’re describing? A five-page informational site and a full platform with program applications, a donor portal, and multilingual content are very different projects. Being honest about budget early saves everyone time.

Funding restrictions. If you’re using grant funds for this project, can those funds be used for website work? What documentation or approval is required? Some funders require pre-approval for technology expenditures. Find out before you commit.

Procurement requirements. Does your organization require a formal RFP process, board approval, or competitive bidding before engaging a vendor? If so, build that into your timeline.

Timeline. Are there hard deadlines connected to a grant reporting period, a program launch, or an organizational event? Hard deadlines are fine — but they need to be communicated clearly and factored into the project scope.

Required approvals. What internal or external approvals does this project need before a vendor can begin work? Board sign-off, funder notification, legal review? Map these out in advance.

Available staff capacity. Who will manage this project internally, and do they have the capacity to do so alongside their existing responsibilities? A website project without a dedicated internal point of contact is a project that will struggle.

Nonprofit Website Redesign Readiness Checklist

Use this checklist to assess your organization’s readiness before beginning a website redesign project.

Goals

• We have identified our primary website audiences and prioritized them.
• We have agreed on the most important actions we want visitors to take.
• We have reviewed current analytics or gathered staff input on what’s missing from the site.

Content

• We have audited existing content and identified what needs to be updated.
• We have identified content that can be removed or significantly simplified.
• Every section of the site has a named content owner.
• We have a realistic plan for having content ready when the project needs it.

Governance

• We have identified who has final approval authority on content and design.
• We have a process for resolving disagreements during the project.
• We have identified who will maintain the site after launch.
• We have a plan for knowledge transfer if that person leaves the organization.

Technical

• We understand our accessibility requirements and obligations.
• We have confirmed the site will be mobile-friendly.
• We know what CMS editing capabilities our staff needs.
• We have identified all required forms, integrations, and third-party tools.
• We have reviewed our privacy obligations given the populations we serve.
• We have confirmed who controls our domain and hosting accounts.
• We have a plan for post-launch analytics.

Project Readiness

• Our budget range is realistic for the scope we’re describing.
• We have confirmed whether grant funds can be used and what approval is required.
• We understand our procurement requirements.
• We have identified any hard deadlines and communicated them.
• We know what approvals are required before a vendor can begin.
• We have identified an internal project lead with adequate capacity.

A practical next step

Working through this checklist before you contact a web professional will save time, reduce friction, and improve the outcome of your project. Organizations that arrive at a first conversation with clear goals, a realistic budget, and a named decision-maker move faster and get better results — not because they’ve done the designer’s job, but because they’ve done their own.

I work with nonprofits, tribal organizations, and community groups across Montana on exactly this kind of project. If you've worked through the list and want to talk about what's next, see web design for Native-owned organizations or Montana web design, or bring the checklist to a call.