Grant management systems have a reputation for being awful, and it's earned. I've reviewed half a dozen of them over the past year. Every single one treated the grant process as a data entry exercise. Fill in the form. Upload the documents. Wait. Get a decision via email three months later. No visibility, no progress tracking, no sense that a human was on the other end. We just built one that works differently.
What You Need to Know
- Grant management systems typically fail because they're designed around the administrator's process, not the applicant's experience
- Multi-country grant programmes add complexity that off-the-shelf systems don't handle well: time zones, languages, local requirements, and varying review workflows
- The grant process is a relationship, not a transaction. The system should reflect that
- The biggest design win is visibility. Applicants who can see where their application is and what happens next trust the system
The Brief
An international sports organisation came to IDESIGN with a familiar problem. They manage grant funding across multiple countries in the Pacific region. The existing process ran on email, spreadsheets, and institutional memory. Applications arrived as email attachments. Reviews happened in shared documents. Decisions were tracked in a spreadsheet that one person maintained and everyone else asked about.
It worked when the programme was small. As the funding grew and the countries multiplied, it was breaking. Applications were getting lost. Review timelines were inconsistent. Reporting to funders was a manual exercise that took weeks.
They wanted a system. What they needed was a rethinking of how the grant process works when it crosses borders.
The Applicant Experience
Most grant systems are designed from the administrator's perspective. What data do we need? What documents are required? What are the compliance checks? This makes sense administratively, but it produces forms that feel like tax returns.
We started from the applicant's side. Who are these people? They're programme managers, coaches, community leaders across the Pacific. Some have strong internet connections, others don't. Some are comfortable with digital forms, others aren't. All of them are busy doing the actual work that the grant funds support.
Progressive disclosure. Instead of a 12-page form that demands everything upfront, we broke the application into stages. Basic information first. Then the detailed proposal. Then the budget and supporting documents. Each stage saves automatically. Applicants can leave and come back without losing work.
Plain language. Every field label was rewritten from administrative language to conversational language. Not "Provide a detailed description of the proposed programme outcomes and measurable indicators" but "What will this funding help you achieve? How will you know it worked?"
Status visibility. Once submitted, the applicant can see exactly where their application is. Received. Under review. Additional information requested. Decision pending. Approved or declined. No more emails asking "did you get my application?" No more silence for three months.
The moment we showed the prototype status tracker to the team, they got quiet. Then someone said, "Our applicants have never been able to see this before." That's when we knew we were on the right track.
Rainui Teihotua
Chief Creative Officer
The Reviewer Experience
Reviewers in a multi-country programme have different contexts. A reviewer in Fiji has different knowledge than a reviewer in Tonga. The system needs to support local context without creating inconsistency.
Structured review criteria. Each application is reviewed against the same criteria, with scoring and comments. This creates consistency across reviewers and countries. But the criteria are designed to capture nuance, not just checkboxes. "How well does this align with local priorities?" requires a written response, not a number.
Workload distribution. Applications are assigned to reviewers based on country and expertise. Each reviewer sees their queue, their deadlines, and their completed reviews. No shared spreadsheet, no email chains.
Conflict of interest management. In small communities, reviewers often know applicants personally. The system flags potential conflicts and allows reviewers to recuse themselves. This was a requirement that would have been impossible to manage consistently with the old email-based process.
The Multi-Country Challenge
The hardest part of this project wasn't the code. It was understanding how the same process works differently across countries.
Time zones. Deadlines that are midnight in Auckland are a different date in Samoa. The system handles deadlines in the applicant's local time zone and displays accordingly.
Connectivity. Some applicants work in areas with limited internet. The application form works on slow connections, images are optimised, and long forms auto-save so dropped connections don't lose work. We tested on throttled connections, not just our office WiFi.
Different reporting requirements. Each country has different reporting obligations to local government and funding bodies. The system generates reports in the format each country needs, not a one-size-fits-all template.
What We Learned
Grant management is a design problem, not a data problem. The data is straightforward: applications, reviews, decisions, reports. The design challenge is making a process that spans months, crosses borders, and involves dozens of people feel manageable and transparent.
Three things made the biggest difference:
Visibility wins trust. Every person in the process, applicants, reviewers, administrators, funders, can see exactly what's happening. No black boxes. No waiting without information. Trust in the system comes from transparency.
Save everything, always. Auto-save eliminated the single biggest source of frustration in the old process: lost work. It's a small technical feature with an outsized impact on user confidence.
Design for the edges, not the centre. The applicant with reliable internet and digital literacy doesn't need much help. The applicant working from a community centre on a shared computer with a slow connection does. Designing for the hardest use case makes the easy case effortless.
This was one of the most rewarding projects we've worked on. Not because of the technology, which was conventional, but because the design decisions directly affected whether community programmes across the Pacific get the funding they need. That's the kind of work IDESIGN exists for.