Choose NGO website features around real tasks

An NGO website’s first release should make approved organisational information, programmes, reports and contact routes easy to find and maintain. Add donations, application workflows, dashboards or member access when a real user need, an operating owner and a support plan justify them.

The right feature list depends on the organisation. Use the priorities below to prepare a brief, then check the evidence and permissions behind the content with the NGO donor-trust content guide.

Start with the essential publishing features

Organisation and governance pages
Publish approved identity, leadership, governance and contact information. Give each page an owner and a review date.
Programme pages
Use consistent fields for objectives, geography, dates, status, responsible contact and related evidence. Keep proposed work distinct from active programmes.
Report library
Provide meaningful titles, dates, reporting periods, summaries and clearly labelled downloads. Add filtering when the number of documents makes it useful.
News and approved stories
Support a manageable publishing workflow with image descriptions and the agreed approval steps. Avoid making every staff member a site administrator.
Contact and enquiry routes
Direct visitors to the appropriate team. Make validation, consent where required, receipt handling and failure messages part of the form specification.

Scope operational features separately

These can be useful, but their value depends on the process behind the interface.

  • Donations: agree payment-provider requirements, confirmation, reconciliation, failed-payment handling and support ownership.
  • Applications or registrations: define required information, eligibility, approvals, access, retention and how applicants are told the outcome.
  • Public dashboards: agree the indicators, approved sources, update schedule and what happens when data is late or incorrect. A public visual should not expose restricted source records.
  • Private portals: define user roles, account support and the separation between public content and restricted records.
  • Multilingual publishing: identify actual audiences, translation reviewers and the process for keeping each version current.

Discuss data exchange with existing tools through the systems integration service. A website specification should identify those dependencies before development starts.

Make mobile and editing needs testable

Describe what users and staff must be able to do, rather than relying on labels such as “responsive” or “easy to use.” Ask a representative reader to find a programme report on a phone. Ask an editor to replace a document and send a story for approval.

  • Navigation and forms work with touch and keyboard input.
  • Important content remains readable without sideways page scrolling.
  • Images have useful descriptions where they communicate information.
  • Reports have clear labels and an alternative summary when the download is large.
  • Editors can perform their agreed tasks without sharing administrator credentials.
  • The support owner can follow the agreed backup, recovery and escalation procedure.

Prioritise the first release

For every proposed feature, write down the user task, content or data owner, dependency and acceptance test. Place it in one of three groups: necessary for launch, useful after launch or deferred until the organisation can operate it.

Illustrative example: a report library may be ready for launch because approved documents and an editor already exist. A public dashboard may belong in a later phase because indicator definitions, data access and refresh ownership still need agreement. This is a planning example, not a description of a Watabe client project.

Check the proposed launch list with the people who will use and maintain it. Ask a programme officer to find the latest approved report, a visitor to identify the correct contact, and an editor to correct an outdated programme date. Record the steps, any missing information and the person responsible for resolving each problem. These small task checks reveal whether the proposed features support daily work and help the team choose practical improvements for the next release.

Include handover and ongoing costs in the brief

Record who owns the domain, hosting, content and relevant accounts; what training is included; which licences recur; and how changes are requested after launch. Define the difference between correcting an agreed launch defect and commissioning a new feature.

Use the website cost guide to compare the initial build and recurring charges. Explore website design and development when you are ready to request a proposal for the agreed priorities.