A nonprofit website should help people understand the organisation and reach the right next step. Someone looking for a service may need a different route from a volunteer, supporter or potential partner. Define those needs before deciding that the homepage should focus on one particular action.
This planning guide is written by No Brainer Creative, an Auckland agency offering website design for NZ organisations and businesses. It explains how to prepare a useful brief. It does not rank platforms or present unverified charity-project outcomes.
Start with the people the website serves
Ask the organisation’s team which questions people need answered and which requests are difficult to route. Review the information you already have, including support enquiries and feedback, rather than assuming every visitor wants to donate. Agree what the website should make easier and who owns each response.
Use clear labels for distinct actions. A person seeking help should be able to find service information without working through a fundraising pitch. A volunteer should understand the opportunity and how to express interest. A supporter should know which approved route to use and what happens after they act.
| Visitor need | Information to prepare | Check the next step |
|---|---|---|
| Find a service or get help | What is offered, who it is for, relevant locations and contact arrangements. | The person can identify the appropriate route and the team knows who receives the request. |
| Volunteer | Current opportunities, expectations and the initial information the coordinator needs. | An expression of interest reaches the intended recipient with an accurate confirmation. |
| Support the organisation | The purpose and approved ways to contribute. | The link opens the correct destination and the confirmation matches the actual action. |
| Assess the organisation | Accurate identity, current contact information and approved reports or stories. | Important information is findable, readable and dated where that matters. |
Define the donation or supporter journey
If online donations are part of the scope, identify the provider, account owner and options the organisation has approved. Ask the provider to confirm what the proposed setup supports. Explain the destination clearly when a link takes the visitor to a separate site.
An external page and an embedded form are options to assess with the actual setup. Neither is automatically a better choice. Review the information shown before the visitor acts, the currency and available options, the expected confirmation and the team’s process for handling questions.
Plan any payment or notification tests with the organisation and provider so operational effects are expected. A donation-button click is not proof of a completed donation. Keep those measures separate and document any reporting gaps between the website and the provider.
Make volunteer and contact forms useful to the team
Agree what is needed at the first enquiry and which details can wait for a conversation. Label the form so the visitor understands whether they are expressing interest, applying for an opportunity or asking a question. Make the confirmation match that step.
Identify the receiving inbox or system and the person responsible for follow-up. If a coordinator checks requests during particular hours, describe the process accurately rather than promising an immediate response. Test receipt and the reply route before launch, with clearly identified internal submissions excluded from genuine enquiry totals.
Prepare content the organisation can approve
Explain the work in clear language and keep service information current. Give published outcomes a defined period and source. A figure should help readers understand the work rather than serve as an unexplained headline. Use approved stories and images with the appropriate permission.
Where the organisation publishes annual reports or other documents, provide descriptive links and useful context such as the title and period. A concise web summary can help readers find the relevant information while keeping the full approved document available. Do not assume that every reader prefers the same format.
Include accessibility in the actual requirements
The W3C Web Accessibility Initiative’s design guidance covers readable contrast, clear navigation, associated form labels, feedback and different viewport sizes. Use these principles to plan representative checks rather than adding accessibility as a final visual adjustment.
Check that someone using a keyboard can identify and operate the main controls. Review form instructions and errors, the text size and how the page behaves when the viewport changes. Include suitable alternatives for images or media where the content needs them. Agree specialist review within the project scope when it is required; a short checklist is not a complete accessibility assessment.
Choose a platform your editors can use
List the routine tasks the team needs to do: changing an event date, updating service information, adding an approved story or replacing a report. Ask to see those tasks completed with representative content before accepting the handover.
A configured theme, an existing website or custom development may each meet the brief. Compare the actual requirements, the editing process, dependencies and maintenance responsibilities. A platform label does not establish whether the result will be useful or easy to manage.
Separate the initial build from hosting, software, provider charges and ongoing support. Confirm who owns the accounts and content, who approves updates and what happens when a staff member or volunteer hands over responsibility. Set the delivery date from the agreed scope and content readiness.
Verify useful actions before measuring outcomes
Choose representative tasks across the main visitor routes. Test the service-information journey, the volunteer or contact form and any external supporter destination. Record what was checked, the expected result and who approved it.
After launch, keep website visits, contact submissions, suitable volunteer requests and completed actions reported by another system separate. Review the questions and requests with the team that handles them. A website change should not be credited with a fundraising or service outcome unless the available evidence supports that conclusion.
Bring a brief with clear responsibilities
Use our website brief guide and blank worksheet to record audiences, essential pages, existing systems, content owners and launch checks. Ask providers to explain the work included and the responsibilities that remain with the organisation.
Nonprofit website questions
What should a nonprofit website prioritise?
Start with the people the organisation serves and the actions it needs to support. Finding help, volunteering, donating and understanding the organisation may each need a clear route. Agree priorities from the actual mission and audience rather than assuming donations always come first.
Can an external donation page be suitable?
It can be part of the agreed journey. Make the destination and purpose clear, confirm that it is the organisation’s approved provider and test the mobile handover and expected confirmation. A different visual design alone does not prove that the route will fail.
Do we need a custom website or a particular platform?
Compare the requirements with what the current setup, a configured theme or custom work can support. Consider editing tasks, integrations, accessibility checks and maintenance responsibilities. No approach automatically raises more donations or pays for itself.
Can volunteers maintain the website?
Identify the actual editors and test the routine tasks they will do, such as updating an event, editing service information or replacing an approved report. Agree training, ownership and handover arrangements. Do not assume that every volunteer has the same time or technical experience.
What content helps explain the organisation’s work?
Use accurate service information, current contact details and approved reports or stories. Give any published outcome a clear period and definition. Use suitable permissions for stories and images, and keep important information understandable outside a long document.
Which accessibility checks belong in the brief?
Include clear navigation, descriptive form labels, readable contrast, keyboard access and understandable feedback. Review representative tasks on different screen sizes and with the users the organisation needs to serve. Agree the scope of specialist review where required.
How should we measure whether the website is useful?
Separate information use, volunteer enquiries, donation-link clicks and completed actions reported by the relevant system. Keep internal tests out of totals. Record gaps when activity moves to another provider and review the quality of requests with the team handling them.
Discuss your nonprofit website requirements with No Brainer. Share the current website and the visitor journey you want to improve so the scope can be planned around the organisationβs needs.