Part 1: Digital Principles Guiding Our Work
In this first part of a two-part series, we present the core digital principles that guide Hikaya's work when developing digital solutions for NGOs. We cover four foundational principles: designing with the user, defining system boundaries, defining common data, and building with scale in mind. Part 2 covers integration, MVPs, the system-vs-procedure decision, and the DFV evaluation matrix.
The Principles for Digital Development provide a common basis for international development and humanitarian practitioners applying digital technology to their work. Regardless of which technologies you use to build digital systems, establishing clear principles helps guide decisions and keep teams aligned.
At Hikaya, we follow an agile approach to system development, one that aims to produce a digital solution that meets user requirements and remains cost-effective. We endorse the Principles for Digital Development and have expanded on them in areas we find true to our work.
This post covers designing with the user, defining system boundaries, defining common data, and building with scale in mind.
Key Takeaways
- Every digital solution should start with the user. Co-create with the people who will use the system as well as those who commission it
- Clearly define system boundaries to manage expectations and avoid mission creep that makes tools fragile and overspecified
- Establish common data standards so information flows across departments as a single source of truth
- Build with scale in mind. What works for one country office should be designed to adapt to others without a complete rebuild
- New systems should integrate with existing tools in the ecosystem instead of operating in silos
- Define a Minimum Viable Product (MVP) and get it into users' hands quickly. Real-world feedback informs the next version
- Not every requirement needs code. Sometimes a Standard Operating Procedure is more practical than a technical solution
- Use the Desirability vs. Feasibility vs. Viability Matrix to prioritize what to build first and where to invest limited resources
1. Design with the user
Working closely with users helps ensure their feedback drives system development. Whatever we build, whether a whole new tool or a feature for an existing one, requires meaningful input and genuine demand from the people who will use it. Designing for needs that users themselves don't feel they have is unlikely to pay off.
This is especially true in NGO project management, where field staff closest to communities often have different priorities than headquarters. Their constraints (connectivity, device access, workload) should shape the solution from day one. For a deeper look at this in practice, see our post on building digital solutions iteratively.
From the field
On a project with a global humanitarian organization, we discovered that field staff in three countries had developed completely different workarounds for the same reporting gap. By involving them early in the design process, we built a single solution that addressed all three contexts, something headquarters alone may not have conceived.
2. Define system boundaries
Every system introduced should have a clear scope: what it can do, what it can't, and who it's for. Having these parameters in place helps evaluate whether existing solutions already meet your needs or whether it makes more sense to build from scratch.
From the field
Clients often request to extend a mobile data collection tool beyond its original intent (collecting data points that are later cleaned, analyzed, and reported elsewhere) to include form creation, data management, email distribution, visualization, and more. Eventually, they're looking for a universal solution. The origin of this mission creep is often the comfort of familiarity: users push to (or beyond) the limits of any system they already know.
At Hikaya, our job is to optimize the tools you have for the functions they can meaningfully provide, while capturing input about other desired features for later stages of development, whether that means extending existing tools or recommending other systems that better meet those needs.
Watch out
Mission creep is a common reason digital projects struggle in the NGO sector. A data collection tool that tries to also be a dashboard, a CRM, and a reporting engine may do none of those things well. Define what your system does, and what it doesn't.
3. Define common data
For an organization to benefit from harmonized data, you need to define what data is standard and how it can serve as a single source of truth while remaining compatible with all systems that access it.
This is where data management solutions become important. When country offices each define their own indicators, formats, and collection methods, the result is fragmented data that can be hard to aggregate for organizational learning or donor reporting.
Key insight
Establishing common data standards (shared indicator definitions, consistent disaggregation categories, unified naming conventions) lays the groundwork for cross-program analysis and a functioning indicator tracking system.
4. Build with scale in mind
Well-defined systems need to be built with scale in mind. Ill-defined systems tend to be fragile: an accumulation of bespoke features may render them overspecified to the unconventional needs of a single project. When systems are introduced at a global level, they need to be evaluated for scalability and sustainability in terms of both technical and financial feasibility. This means thinking through how requirements will change when a new market is added or the user base grows significantly.
Consider a monitoring and evaluation (M&E) system built to capture data unique to one project: a field for the project name, start and end dates, and specific indicators. This tool might collate everything in a single form that feeds into a reporting system. You can't simply take this system and expand it to another country. You have to think about adapting to changing requirements, and even sensitive political questions.
Perhaps your project started in Tanzania and you don't want that team to see data from another country. You need to ensure not only that data collection is harmonized across countries but also that access control is part of the features you develop. Even within a country, it might be necessary to partition data access, for example in a conflict zone where teams working with different groups need to keep their data separate for the safety of users and beneficiaries.
Key insight
Scalability in the humanitarian sector is a technical question and also a question of access control, data sensitivity, and the political realities of each context where your system will be used.
When evaluating whether a system is ready to scale, ask: what changes when we add a new country, a new team, or a new set of requirements?
Tip
Before expanding a system to a new context, map the differences in data sensitivity, access control needs, and regulatory requirements. The governance side of scaling can take as much effort as the technical side.
In our part 2 of the digital principles blog series, we'll look at the remaining principles in detail.
At Hikaya, we help NGOs and nonprofits worldwide turn these principles into working systems, from initial user research through scalable, standards-based solutions your team owns long-term.
If your organization is grappling with system boundaries, data standards, or scaling a tool across contexts, let's talk through it. Or explore how we've applied these principles in our work.
