Part 2: Digital Principles Guiding Our Work
This second part of our digital principles series covers the remaining four principles: integrating with existing systems, defining a minimum viable product (MVP), deciding between technical solutions and procedures, and evaluating features using the Desirability vs. Feasibility vs. Viability matrix. Together, these principles help NGOs develop digital solutions that are practical, cost-effective, and adapted to real-world constraints.
In part 1 of this series, we covered how designing with the user, defining system boundaries, defining common data, and building with scale in mind contribute to better digital products. Building on those foundations (especially the idea of scalability), this post explores how integration, MVPs, the choice between systems and procedures, and the desirability/feasibility/viability framework help ensure you develop the right digital solution for your organization.
Key Takeaways
- New digital systems must be interoperable with existing tools. Siloed systems can create security risks and inefficiency
- Define a Minimum Viable Product (MVP) and get it into users' hands quickly for real-world feedback
- Not every requirement needs a technical solution. Sometimes a Standard Operating Procedure (SOP) is more practical
- Use the Desirability, Feasibility, Viability matrix to prioritize which features to build first
- Start simple, learn from usage, and iterate toward more sophisticated solutions
5. Integrate with existing systems in the ecosystem
When a new digital system is introduced, it should be interoperable with the existing ecosystem instead of operating in a silo. We often work with organizations that have separate systems for each department: finance uses one tool, HR another, and project teams have their own entirely. Information passes manually between departments, with the risk of failure or miscommunication at every handoff. Integrated data management solutions allow for partial or complete automation of this process: a project team can pull budget information directly from an up-to-date version maintained by finance.
Beyond efficiency, there are practical security reasons to pursue integrated systems.
Watch out
When a staff member leaves and your systems aren't integrated, every system administrator must independently remember to revoke access. One missed system can leave sensitive data exposed. A single sign-on solution mitigates this: one administrator can revoke all access with a single action.
6. Define a Minimum Viable Product and develop in iterations
To build a functional system in the shortest time, define the critical "must haves" and leave secondary requirements for later. This allows systems to develop rapidly and get into users' hands as fast as possible so they can provide valuable feedback.
As we discuss in Finding a better way to build digital solutions for NGOs, we find it more useful to think about a first iteration (almost like a first draft) than to immediately conceive of a final solution. Experience using these initial systems informs the design of a more complete solution over several iteration cycles. The aim is to get an MVP out that is functional, gather feedback, and use that to inform later stages.
A practical test for whether you've found your MVP:
Tip
Define your MVP by asking: "What is the smallest thing we can build that a user can actually use to do their job?" If the answer requires more than 2-3 core features, you're probably not at the minimum yet.
In our experience, working with the bare minimum and building on real-world feedback tends to produce better end products than systems that spend months in conceptualization only to be released with little regard for how they'll be used. Over-engineered systems can be harder to fix and are at greater risk of being abandoned by the people they were built for. The longer a system stays in development without user contact, the more assumptions accumulate, and the harder it becomes to course-correct.
7. Decide whether a requirement should be solved with a technical solution versus a procedure
Not every requirement needs a technical solution. Assess requirements based on complexity and decide whether code or a Standard Operating Procedure (SOP) is the better fit. Automation is appealing, but we engage with technology on the basis of actual needs and practical use cases.
Our clients often ask how far they can push technical solutions. Our job is to help them decide whether it's worthwhile to design a system that not only collects data through a form but also pushes it through to a real-time dashboard. The tools exist, but in our experience, starting small with procedures alongside well-defined technical tools tends to lead to better long-term results.
A simple SOP can replace a catch-all technical solution while allowing the team to learn through iteration. The end product takes longer to reach, but it can be more useful, less fragile, and avoid many of the errors that come from designing in a silo.
From the field
A head office struggles with fragmented data submitted by country offices. In theory, technical solutions could process and analyze this automatically, but that would require imposing a unified format across all countries, which is a huge first step. Instead, they institute a procedure: staff manually compile datasets and feed them into a business intelligence (BI) tool. This helps clarify the true commonalities, so that when they do standardize data collection later, the changes are more likely to make sense and stick.
8. Evaluate features using the Desirability vs. Feasibility vs. Viability Matrix
Determining what is desirable, feasible, and viable (DFV) helps us decide how to address requirements that add value and are cost effective. As we describe in our post on designing the right M&E system, distinguishing between these three characteristics helps you decide what features should be a priority and how they should be integrated.
Clarity about what is desirable from a user's perspective should guide development. Once you've established desirability, you can prioritize based on assessments of feasibility (can we build and maintain it?) and viability (does it align with organizational strategy?). Integrating all three can lead to a smoother rollout and a stronger end product.
Key insight
One reason the DFV matrix helps is that it brings different stakeholders to the same table: users define desirability, technical teams assess feasibility, and leadership evaluates viability. The conversation itself has value alongside the outcome.
To get the most out of this framework, make it participatory rather than prescriptive:
Tip
Run a DFV assessment as a collaborative workshop, not a top-down exercise. When field staff, technical teams, and leadership each rate the same feature independently, the gaps between their perspectives can show where alignment is needed.
At Hikaya, we help NGOs and nonprofits worldwide move from digital principles to working products, integrating with what you already have, scoping realistic MVPs, and evaluating features through a lens of desirability, feasibility, and viability.
If you're deciding what to build next or how to connect existing tools, start a conversation with us. You can also see these principles in action in our work.
