Part 1: Digital principles that guide our work

The Principles for Digital Development provide a common basis for international development and humanitarian practitioners in applying digital technology to their work. Regardless of which technologies are being used to build digital systems, it is important that principles are established and can help to guide our work.

Hikaya believes that it is important that an agile approach to system development is followed to ensure the highest likelihood of success in creating a digital solution that meets user requirements and is cost effective. We endorse the Principles of Digital of Development and have expanded upon them in areas we find true to our work.

In this two-part series of posts, we will present to you the principles we follow when developing a digital solution. This post will cover how to design with the user, define system boundaries, define common data, and build with scale in mind. A later post will build on these concepts to introduce further principles that are integral to building good systems.

TL;DR

Here's a summary of the principles we follow when developing a digital solution:

1. Design with the user
2. Define system boundaries
3. Define common data
4. Build with scale in mind
5. Integrate with existing systems in the ecosystem
6. Define a Minimum Viable Product (MVP) and develop in iterations
7. Decide whether a requirement should be solved with a technical solution versus a procedure
8. Evaluate features using the Desirability vs. Feasibility vs. Viability Matrix

1. Design with the user

Working closely with users to understand their needs, we can ensure their feedback is the driving force behind system development. Co-creation is the key here: ultimately, it’s our clients that are the end users. Whatever we build, whether it’s a whole new tool or a feature for an existing one, requires meaningful feedback and, ultimately, demand on their end. There’s no point in designing for needs that the users themselves do not feel they have.

For a more in-depth look at how we design with users, read our blog post on Finding a better way to build digital solutions for NGOs.

2. Define system boundaries

To manage user expectations, every system introduced should have a clear scope and bounds for what it can do and who is its intended user. Having such parameters in place helps evaluate whether there are already solutions out there that respond to your needs or whether it is more useful to build one from scratch. A good example of the need for clearly-defined system boundaries and the danger of mission creep in system design is with mobile data collection. Often, clients will request to extend the use case of mobile data collection from its original intent - collecting data points that are later cleaned, collated, analyzed, stored, and reported elsewhere - to include all of the functionalities associated with the steps after data collection. Eventually, they’re looking for a universal solution that not only collects data, but creates forms, manages data, sends it by email, visualizes the information, and so much more. Often, the origin of such mission creep is the comfort of familiarity: users will try to push to (or beyond) the limit of any system with which they’re already familiar.

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 be an extension of such tools or suggestions for other systems and tools that might better meet those needs.

3. Define common data

In order for the organization to benefit from harmonized data, it is necessary to define what data is standard and how it can be established as a single source of truth while remaining compatible with all systems that need to access it.

4. Build with scale in mind

In line with the idea that systems should be well-defined is the idea that systems must be built with scale in mind. Ill-defined systems are fragile and an accumulation of bespoke features may render them overspecified to the idiosyncratic needs of single projects - or even a portfolio of projects. When systems are introduced at a global level, they need to be evaluated for scalability and sustainability in terms of technical and financial feasibility. This means carefully thinking through how the requirements will change when a new market is added or when the user base increases by a significant amount.

To take geographical expansion as an example, imagine a monitoring and evaluation (M&E) system that has been built specifically to capture data unique to a project: perhaps you have a field to input the project name, a start and end date, and data on specific indicators. This tool might collate this in a single form that submits it to a system that allows for easy reporting. You cannot simply take this system and expand it to another country; instead, you have to think about how to adapt this system to changing requirements and even sensitive political questions. Perhaps your project started in Tanzania and you don’t want that team to see the data of users in another country. In this case, you need to ensure not only that the way data is collected is harmonized across countries but also that access control is a part of the features you develop. Even within a country it might be necessary to partition access to data if, for example in a conflict zone, teams working with different groups need to be able to keep their data separate for the safety and security of users and beneficiaries. Scaling isn’t just about new servers and performance metrics, but about designing systems that take into account the often sensitive nature of the work taking place on the ground.

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 improve their delivery of goods and services to those most in need while making reporting to donors more transparent.

To learn more about our approach, visit our process page or see some of our past work.