Part 2: Digital principles that guide our work

In our last look at digital principles that guide our work in part 1 of this blog series, we explained how designing with the user, defining system boundaries, defining common data, and building with scale in mind contribute to better digital products. Picking up where we left off, and especially building on the idea of scalability, we’ll explore in this post how integrating with existing systems, defining a minimum viable product (MVP), deciding between systems and procedures, and evaluating desirability/feasibility/viability can help ensure you develop the best digital product for your organization.

5. Integrate with existing systems in the ecosystem

When a new digital system is introduced, it must be interoperable with the existing ecosystem, not operating in a silo. Often, we work with organizations that have separate systems for each department: finance and accounting may use different systems than HR and the project teams may have their own systems and tools completely separate from those as well. Information and data must pass manually from department to department, with the concomitant risk of failure or miscommunication along the way. Integrated systems allow for the partial or complete automation of this process: in a harmonized system, a project team might be able to pull its budget information directly from an up-to-date version that comes from the finance team.

Beyond efficiency gains, there are other very practical reasons to pursue a strategy of holistic, integrated systems. Imagine that a staff member with access to sensitive information (or, really, access to any information at all) leaves the organization. In an un-harmonized digital ecosystem, it’s incumbent upon the system administrator of every individual system to ensure that that staff member’s access to the different systems and tools is deactivated. There are so many security risks engendered by an approach that requires different individuals working in different silos to remember to deactivate the departed staff member’s access. Failure in this endeavor could leave the individual with access to sensitive HR or financial data until someone notices the oversight, which is not a guarantee. With a single sign-on solution in place, the problem is drastically mitigated: one super-user such as HR has the power to take away access with the click of a button when a staff member leaves the organization. Harmonized systems are very often safer systems.

6. Define a Minimum Viable Product and develop in iterations

To ensure a functional system is built in the shortest amount of time, it is important to define requirements that are critical “must haves” and leave secondary requirements to a later date. This allows systems to develop rapidly and to get it in the hands of users as fast as possible so they can continue to provide valuable feedback. As discussed in our post, Finding a better way to build digital solutions for NGOs, it’s often more useful to think about a first iteration, almost like a first draft, of a solution rather than immediately trying to conceive of a final one. Experience using these initial systems will inform the design of a more final solution over several iteration cycles. The overriding imperative at the beginning of any development process should be to get an MVP out that is functional, gather feedback from users, and use that to inform later stages.

Working with the bare minimum and building on feedback from real-world use almost always results in better end products than those that spent a lot of time in the conceptualization and development stages and that are then released to users with little regard for the potential consequences and much greater effort required to fix over-engineered, ill-adapted systems.

7. Decide whether a requirement should be solved with a technical solution versus a procedure

It is important to identify requirements and assess them based on complexity to decide whether they should be solved as a technical solution or a Standard Operating Procedure (SOP). Technology is great and automation is on the tip of everyone’s tongue these days; however, it is important to engage with technology in a grounded way on the basis of actual needs and practical use cases and not simply on the grounds that more technology is always better.

Typically, our clients will ask us how far we can push technical solutions. Our job, in keeping with our principle of narrowly defining systems, ensuring their scalability, and evaluating the feasibility and viability of new features, is to help them think through whether it really is worthwhile to design a system that can, say, not only collect data through a form but also push it all the way through to a dashboard that updates and visualizes in real time. There are certainly technical solutions that will allow for this; however, often we find that starting small and implementing procedures that go hand-in-hand with specific, narrowly-defined, well-designed technical solutions leads to better longer-term results. A simple SOP can take the place of a catch-all technical solution in a way that allows for learning in the process of iteration such that the end product, while it may take longer to develop, is ultimately more useful, less fragile, and free of the kinds of errors that come from the conceptualization of a system in a vacuum separate from its day-to-day use by end users.

A good example of this might be a head office that struggles with manually working with idiosyncratic data submitted by country offices. In theory, there are technical solutions that could allow them to process and analyze the data automatically. However, doing this would require the country offices to submit all the data in a unified format, meaning all data fields would need to be shared. This may or may not make sense, but in either case it’s a huge first step to make right off the bat. Instead, you could think about instituting a procedure whereby staff in the head office manually compile data sets from all countries and then feed them into a business intelligence (BI) tool. This process will help clarify what the true commonalities are and ensure that, in a later iteration, any changes made to the data collection and collation processes that happen in-country make sense and don’t have to be changed again as they might need to in a situation where a common format is blindly imposed from the outset.

8. Evaluate features using the Desirability vs. Feasibility vs. Viability Matrix

Determining what is desirable, feasible, and viable can help us decide on how to address requirements that add the most value to our users and are the most cost effective. As described in our post, Designing the right system to build, distinguishing between these three characteristics can help 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 the development of new products and their associated features.

Once you’ve established what is desirable, you can prioritize what to develop based on assessments of the feasibility and viability of such features. Ultimately, a process that integrates considerations based on this three-way matrix will result in a smoother roll-out and a stronger end-product.

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.