How to Conduct User Testing on a Nonprofit Website
Key takeaways
- Nonprofits typically test websites only internally, with staff who know the organisation too well to simulate a first-time funder, donor or beneficiary encountering the site.
- User testing means observing real people from your stakeholder groups attempting real tasks, not staff sign-off, and it exposes structural failures that are invisible to analytics and internal review.
- Testing with as few as five users uncovers the large majority of usability problems, making the insight per pound spent extraordinary relative to almost any other investment in website quality.
- Tests should focus on the tasks that matter to each stakeholder group: donors finding and completing a donation, funders locating governance documents, and beneficiaries finding programme and eligibility information.
- A test needs only a laptop, a quiet room and an observer who does not help — write each task on a card, watch where people get stuck, and rank findings by how many testers encountered them.
- Nonprofit testing carries ethical duties, including informed consent, avoiding distressing scenarios, and managing power dynamics when participants are beneficiaries or vulnerable.
Summary
Nonprofits almost never test their websites with actual users. They test them internally — with Communications Directors, Executive Directors, and programme staff who all know the organisation intimately and therefore cannot accurately simulate the experience of a funder encountering the site for the first time, a beneficiary looking for service information, or a major donor assessing whether the organisation merits their trust. Internal review catches typos and broken links. It does not catch the structural failures that make the website inaccessible or ineffective for the people it is supposed to serve.User testing reveals the gaps between what the organisation believes the website communicates and what it actually communicates to the audiences that matter. These gaps are specific and actionable: a funder who cannot find the annual report because it is in a location that makes intuitive sense to the person who put it there but not to someone navigating without prior knowledge, a beneficiary who cannot determine whether they are eligible for a service because the programme description is written from the organisation’s perspective, a major donor who loses confidence when the team page is out of date.This post covers the governance case for user testing on nonprofit websites: why it reveals failures that no other form of review can catch, how to design a testing protocol appropriate for the budget and resource available, how to recruit appropriate test participants from the primary stakeholder groups rather than from the organisation’s internal community, what to observe and document during testing sessions, and how to translate testing findings into governance-prioritised recommendations that the Communications Director can act on and the Board can evaluate as evidence of institutional responsiveness to stakeholder needs.
Nonprofit websites are built based on assumptions. The Communications Director assumes donors will find the donation button. The programmes team assumes beneficiaries will understand the eligibility criteria. The Executive Director assumes the homepage communicates the organisation's mission clearly. The designer assumes the navigation makes sense. Nobody tests any of these assumptions with the people who actually use the site.
User testing is the process of observing real people as they attempt to complete real tasks on your website. Not staff members. Not the Board. Not the agency that built it. Actual visitors from your stakeholder groups, using the site the way they would in practice, while someone watches and records what happens.
The findings are almost always surprising. The donation button that everyone assumed was obvious turns out to be invisible on mobile. The programme description that the team spent weeks writing turns out to be incomprehensible to someone who does not already know what the programme does. The governance section that was built for funders turns out to be three clicks too deep for anyone to find it. These failures are invisible to analytics. They are invisible to internal review. They only become visible when you watch someone try to use the site and fail.
Why nonprofits do not test
The most common reason is that nobody thinks of it. Nonprofit website projects follow a familiar sequence: brief, design, build, content, launch. Testing, if it happens at all, means the Communications Director clicking through the staging site and confirming it looks right. That is not user testing. That is sign-off by someone who already knows how the site works.
The second reason is perceived cost. User testing sounds like it requires a research lab, professional moderators, and a large budget. It does not. Jakob Nielsen's foundational research at the Nielsen Norman Group demonstrated that testing with as few as five users will uncover approximately 85% of usability problems. Five conversations. Five tasks. The insight per pound spent is extraordinary compared to almost any other investment in website quality.
The third reason is discomfort. Testing means watching your stakeholders struggle with something your organisation produced. It means discovering that the navigation structure the team debated for weeks does not work. It means finding out that the hero message the Executive Director personally approved does not communicate what anyone thought it communicated. This is uncomfortable. It is also the point. Research across industries shows that organisations investing in systematic usability testing report an average 83% increase in conversion rates. The discomfort of finding problems is dramatically less expensive than the cost of not finding them.
What to test and who to test with
User testing on a nonprofit website should focus on the tasks that matter most to your primary stakeholders. These are not abstract usability metrics. They are specific actions that specific people need to complete.
For donors: can they find the donation page from the homepage within thirty seconds? Can they complete a donation on mobile without confusion? Can they find information about how their donation will be used?
For institutional funders: can they find the governance section? Can they locate the current annual report, accounts, and trustee information? Can they identify the organisation's theory of change or impact data?
For beneficiaries: can they find the programme relevant to their needs? Can they understand eligibility criteria? Can they find contact information or a referral pathway?
Each of these is a testable task. Write the task on a card. Give it to someone from the relevant stakeholder group. Watch them try to complete it. Do not help. Do not explain. Do not prompt. Just watch. What they do, where they get stuck, and what they misunderstand is the data.
Recruit testers from your actual audience. Not staff. Not friends. Not Board members. If you are testing the donor journey, ask a supporter who has not visited the site recently. If you are testing the beneficiary journey, work with a programme partner to identify someone who would realistically need to find information on your site. Five to eight testers per stakeholder group is sufficient. More than that produces diminishing returns.
How to run a test without a budget
A user test does not require software, a lab, or a research team. It requires a laptop, a quiet room, and someone who can observe without intervening.
The format is simple. Introduce the session: explain that you are testing the website, not the person, and that there are no wrong answers. Present the task: "Imagine you want to make a donation to this organisation. Starting from the homepage, show me how you would do that." Observe: watch where they click, where they hesitate, where they scroll past something important, and where they give up. Take notes on what happened, not on what you think they should have done. After the task, ask them what they found easy and what they found confusing.
Record the screen if you can (most laptops can do this natively). The recording is useful for showing the team what happened. Watching a donor struggle to find the donation button on your site is more persuasive than any analytics report.
Run five sessions. Each takes twenty to thirty minutes. At the end you will have a clear list of the most significant usability failures on the site, ranked by how many testers encountered them. If four out of five testers cannot find the governance section, that is a critical finding. If two out of five misunderstand the programmes navigation, that is a significant finding. If one tester had an unusual difficulty, note it but do not redesign around it.
The ethical dimension for nonprofits
Nonprofit user testing introduces ethical considerations that commercial testing does not. If your beneficiaries include vulnerable populations, people in crisis, people with disabilities, or minors, testing with them requires specific safeguards.
Informed consent is essential. Participants must understand what they are being asked to do, that their participation is voluntary, that they can stop at any time, and that their data will not be shared or used to identify them.
Avoid testing scenarios that could cause distress. Asking a beneficiary to navigate a page describing a service they were denied, or a programme they are no longer eligible for, is not appropriate test design.
Consider power dynamics. A beneficiary asked to participate in testing by the organisation that provides their services may not feel free to decline. Use intermediaries where possible and make clear that participation has no effect on their relationship with the organisation.
These considerations should not prevent testing. They should shape how it is conducted. The alternative, building a website for vulnerable populations without ever asking them whether it works, is not ethically neutral either.
What to do with the findings
The test findings should be documented in a short report: what was tested, who tested it, what the tasks were, and what happened. For each finding, state the problem, the number of testers who encountered it, and the recommended fix. Prioritise by severity: issues that prevented task completion are critical, issues that caused confusion are significant, and issues that caused minor friction are noted for future improvement.
Present the findings to whoever has authority over the website. This is where user testing becomes a governance tool. "Three out of five donors could not find the donation button on mobile" is not a design opinion. It is evidence of a stakeholder journey failure that has direct revenue implications. The Communications Director who presents user testing findings has moved from "I think we should change this" to "our users could not complete this task." That is a fundamentally stronger position.
If you want to understand how your website serves, or fails, your primary stakeholders, a Blueprint Audit includes stakeholder journey analysis and identifies the specific points where the site is not delivering what your audiences need.
Frequently asked questions
Five to eight per stakeholder group is enough. Testing with five users identifies approximately 85% of usability problems. If you have three primary stakeholder groups (donors, funders, beneficiaries), fifteen total sessions will give you comprehensive coverage. Even five sessions with a single stakeholder group is vastly better than none.
Analytics tells you what is happening. User testing tells you why. Analytics might show that 70% of visitors leave the programmes page within ten seconds. It will not tell you that they leave because the page opens with a paragraph of jargon that makes no sense to anyone outside the organisation. Both are valuable. Neither replaces the other. If you have to choose, user testing produces more actionable findings per hour invested.
Both. Test the current site before a redesign to identify the specific failures the new site must solve. Test the new site before launch (on staging) to confirm those failures have been resolved and to catch new ones. The worst outcome is a redesigned site that repeats the usability failures of the previous version because nobody tested either one.
