How to Design an M&E System for NGOs: A Practical Framework
Adapted from: Amp Lamp
At Hikaya, we help NGOs design and build the right M&E system for their needs by applying concepts from software engineering and UX to the task. Our framework for prioritizing features is the Desirability vs. Feasibility vs. Viability Matrix: it clarifies tradeoffs when developing an indicator tracking system or any digital tool by weighing what users want, what's technically possible, and what aligns with organizational strategy.
Key Takeaways
- Use the Desirability, Feasibility, Viability matrix to prioritize features in your M&E system
- Desirability: consult field staff, not just head office, to understand what users actually need
- Feasibility: assess whether you have the in-house technical capacity to build and maintain the solution
- Viability: ensure the feature aligns with organizational strategy and long-term goals
- The best M&E systems find the overlap between all three factors, delivering the most value for your investment
Why This Matters for NGOs
Nonprofits face constant constraints: limited financial and human resources, and varying levels of in-house technical capacity. These factors directly shape whether a digital solution is desirable, feasible, and viable for any given organization.
We use the matrix as the foundation for our engagements. By rating features on a simple binary scale (high or low on each dimension) we quickly identify what belongs on the development roadmap and what doesn't.
Watch out
A system designed without field staff input is a system at risk of abandonment. The people closest to implementation see constraints that headquarters never will. Design with the user, not just for the user.
Our Approach
We work collaboratively with team members at all levels, from field staff to leadership, to surface the most pressing priorities. The goal: ensure development work remains cost-effective, adds the most value for users, and is deployable in the short term so we can iterate. Starting small and gathering real-world feedback consistently leads to better outcomes than trying to build the perfect system from day one (see our article on iteration for more on this approach).
Desirability
Desirability is driven by input from users and the product owner. If a feature is in popular demand by the people who will actually use it, it should be prioritized.
A practical example: field staff are often asked to report on global key performance indicators (KPIs) in a standard format. Head office may need beneficiary data disaggregated by sex and age group. If head office dominates the conversation, the development roadmap may unduly prioritize features that collect this information. But those administering the project on the ground might have completely different concerns. They may not urgently need or even be able to use disaggregated data in their daily work.
In this case, the feature is desirable from head office's perspective but not necessarily from field staff's. It should remain on the product roadmap, but it might make sense to de-prioritize it in favor of addressing more urgent, fundamental needs that field teams actually feel.
Feasibility
Feasibility examines your current resources and existing system compatibility. It asks a straightforward question: can you actually do this?
Where desirability tells you whether a feature will get used, and viability helps you decide if you should build it, feasibility is more binary. Either you have the in-house technical capacity to build and maintain something, or you don't. This includes whether the feature is compatible with your current operating environment: your existing data management solutions, infrastructure, and team skills.
Feasibility is often the most honest assessment in the matrix.
Key insight
It doesn't matter how desirable or strategically viable a feature is. If you can't build it or maintain it with your current team and resources, it won't serve your organization.
Viability
Viability is driven by organizational leadership and product owners. It answers: should we build this, given our broader strategy?
Tradeoffs are inevitable. A forward-thinking organization might prioritize features that serve longer-term needs over immediate ones. Where desirability and feasibility tend to surface the perspectives of staff closer to implementation, viability focuses on strategic considerations: the kind that require executive decisions about where to invest.
Taking viability into account helps your organization think through whether what you're developing for Uganda might also work in Kenya and Tanzania (our post on digital principles expands on building with scale in mind). It also helps answer questions about who will fund and promote the solution. Ultimately, viability helps you shape your product to maximize impact and get the most longevity out of your investment.
Example: Integration between two existing systems
To see how this works in practice, consider a common scenario: a data integration between two existing systems.
| Factors | High vs. Low |
|---|---|
| Desirability — is this feature in popular demand by users? | High — your end-users will save significant effort no longer having to export data and manually import it into the new system. |
| Feasibility — do you have the resources to build and maintain this? | High — it's no great effort to create the integration; however, maintaining it will require ongoing effort that might outweigh the time it saves. |
| Viability — does this align with organizational strategy? | Low — you're switching to a new reporting format next year. At that point, the integration becomes moot because all programs will move to a new data collection system. |
Taking these three factors into account, you might decide against an integration that, at first glance, seems like a great idea. The decision should come from carefully analyzing benefits against all three characteristics, in a process that engages staff at all levels and especially considers the needs, resources, and constraints of end-users.
Whether it's a major project or a small feature, there are always tradeoffs to analyze. Almost everything is doable in theory. Whether it makes sense in practice is another question. When you find the best overlap between all three factors, you get the most value for your time, effort, and investment.
Tip
Before committing to any feature, rate it on a simple binary scale: high or low desirability, high or low feasibility, high or low viability. If any factor is low, pause and ask whether the investment is justified or whether resources are better spent elsewhere.
Here's how this played out in one of our engagements:
From the field
We worked with an NGO that wanted to integrate their data collection tool with their reporting platform. The integration was highly desirable (saving hours of manual work) and feasible (technically straightforward). But it scored low on viability because they were migrating to a new reporting system within the year. By applying the matrix, they avoided investing in a feature that would have been obsolete within months.
At Hikaya, we help NGOs and nonprofits worldwide design M&E systems that balance what users need, what's technically achievable, and what fits your strategy, so you invest in features that last.
If you're prioritizing your M&E roadmap or evaluating whether a feature is worth the build, let's work through it together. See how we've helped other organizations in our work.