How to Conduct User Testing on a Nonprofit Website | Socialectric

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.

Question 1: How many people do we need to test with?

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.

Question 2: Can we use analytics instead of user testing?

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.

Question 3: Should we test before or after a website redesign?

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.

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.