·6 min read

nonprofit website redesign in ottawa: a practical guide

why nonprofits stay stuck with outdated sites longer than businesses do

a small business with a bad website loses customers and notices on the bottom line. a nonprofit with a bad website loses something harder to measure: a donor who gave up on the form, a volunteer who couldn't find the sign-up page, a funder who wondered whether anyone is minding the store.

the redesign keeps slipping for predictable reasons:

  • budgets run on grant cycles. website money rarely sits in a line item of its own, so it gets pushed behind programs every quarter.
  • the tech stack is whoever was willing. a board member's nephew built it, or a volunteer set it up on a plugin stack nobody else understands.
  • no single owner. when the site belongs to everyone, nobody has the job of fixing it.

the cost compounds quietly. every year, the site gets harder to change, so changes get put off, so the site drifts further from what the organization actually does. a good redesign breaks that loop. it isn't just a new coat of paint.

what to keep and what to rebuild

you don't need to burn it all down. before committing to a full rebuild, spend a few hours auditing honestly. a spreadsheet is enough.

  1. list every page. crawl the site or export the page list from your CMS. include old news posts, event pages and PDFs.
  2. mark each page keep, merge, or cut. keep pages people actually visit and that are still accurate. merge thin pages that cover one topic. cut anything out of date, such as events from 2019 or programs that no longer run.
  3. note what's broken structurally. can a first-time visitor find "donate", "volunteer" and "contact" within two clicks? does the navigation reflect how your community thinks, or how your org chart looks?
  4. check the transactional paths. walk through donating, registering for an event and signing up as a volunteer, on your phone, as a stranger would.

the pattern we see is that the content is often worth keeping while the structure and the transactional flows are what need rebuilding. an audit tells you which situation you're in before you spend money.

tip: open your analytics and sort pages by visits over the last 12 months. if a page has almost no traffic and no strategic reason to exist, it's a candidate to cut, not to redesign.

donation and event pages that don't fight your CMS

donation and ticketing pages are where most nonprofit sites feel the pain. they're typically bolted on through a plugin or an embedded third-party form, styled differently from the rest of the site, and brittle whenever the CMS updates.

transactional flows work better when they're treated as a first-class part of the application, not a bolted-on plugin. money has to move correctly, receipts have to land, and failures have to be handled gracefully — the same standard any serious payment flow is held to. that standard applies directly to a donation or ticketing page:

  • keep the form short. amount, name, email, confirm. every extra field costs completed gifts.
  • make recurring giving a clear option, not a hidden checkbox.
  • let the processor do the sensitive work. card data should go to Stripe, not through your server.
  • send a clear receipt with the details your organization needs for its own records.
  • test the failure paths: declined cards, double-clicks, a closed tab midway through.

for events, the same rules apply: capacity limits, a confirmation that arrives right away, and a page that works on a phone held in one hand in a lobby.

the point isn't to add features. it's that payments should be a dependable part of the site and not a plugin you cross your fingers about on every update.

publishing without a developer on staff

the most common promise in a redesign is "you'll be able to update it yourselves." the most common outcome is that you can, technically, but nobody dares.

what makes self-serve publishing actually work is structure:

  • content types, not blank pages. a "news post", an "event" and a "program" each have fixed fields, so staff fill in a form instead of designing a layout.
  • a locked design. editors change words and images, not fonts and spacing, so a routine update can't break a page.
  • a short path from draft to live. ideally someone writes, someone reviews, and it publishes without a developer in the loop.

the same content-pipeline thinking applies here: content goes in through a defined shape, gets checked, and comes out as a consistent page. a nonprofit doesn't need heavy automation to benefit from that principle. if publishing takes more than a few minutes of effort, it stops happening.

accessibility and mobile basics funders and boards care about

"we care about accessibility" is a promise. "the site meets WCAG 2.1 AA and here's how we checked" is a standard. boards and funders increasingly ask for the second, and for organizations serving the public, it's the right bar regardless.

the checkable basics:

  • colour contrast of at least 4.5:1 for body text against its background.
  • keyboard navigation: every link, button and form field reachable and usable without a mouse, with a visible focus indicator.
  • alt text on meaningful images, and empty alt on decorative ones.
  • labelled form fields, including the donation form, with clear error messages.
  • a logical heading structure so screen reader users can navigate by section.
  • readable on a phone: no horizontal scrolling, tap targets large enough to hit, text that doesn't need pinch-zoom.

you can check most of these yourself with a browser's built-in accessibility tools and by trying to tab through your own donation form. an automated scan won't catch everything, but it will catch the embarrassing things fast.

what a redesign costs and how long it takes in Ottawa

two honest answers: it depends on scope, and it's usually faster than organizations expect.

what drives the cost is not the number of pages. it's the number of different kinds of things the site has to do: a simple informational site is a smaller project than one with donations, event registration, a member area and a publishing workflow. a good agency scopes that against a fixed price after a conversation, rather than billing open-ended hours.

at nanushi we work on a project basis, with the scope and price agreed before work starts. you can see how that's structured on how we work. timelines are measured in weeks, not months, and the thing that most often stretches them is content: getting copy, photos and sign-offs from busy staff and volunteers.

a few things shorten a project:

  • one named decision-maker on your side.
  • an audit done up front, so scope is clear.
  • content gathered in parallel with the build, not after it.
  • a clear idea of what "done" means, including who will update the site afterward.

if you're an Ottawa nonprofit weighing a redesign, the first step costs nothing: run the audit above, and you'll know whether you need a rebuild, a fix, or just a plan.

ready to start building real apps with a team of passionate developers? join nanushi today and level up your mobile development skills.