Software codesign between end users and developers to enhance utility for biodiversity conservation

Abstract

Creating software tools that address the needs of a wide range of decision-makers requires the inclusion of differing perspectives throughout the development process. Software tools for biodiversity conservation often fall short in this regard, partly because broad decision-maker needs may exceed the toolkits of single research groups or even institutions. We show that participatory, collaborative codesign enhances the utility of software tools for better decision-making in biodiversity conservation planning, as demonstrated by our experiences developing a set of integrated tools in Colombia. Specifically, we undertook an interdisciplinary, multi-institutional collaboration of ecological modelers, software engineers, and a diverse profile of potential end users, including decision-makers, conservation practitioners, and biodiversity experts. We leveraged and modified common paradigms of software production, including codesign and agile development, to facilitate collaboration through all stages (including conceptualization, development, testing, and feedback) to ensure the accessibility and applicability of the new tools to inform decision-making for biodiversity conservation planning.

Keywords: applied ecology; biodiversity; biogeography; conservation; informatics.

Figure 1.

Steps in our flexible implementation of the core steps of agile software development to achieve codesign of extensions of Wallace EcoMod and BioModelos for biodiversity conservation users. Software developers (the orange line) and end users (the blue line) iteratively interact (see the line intersections) and engage more intensely (see the loops) or exchange leadership of engagements (the thicker lines) during the process, showing more flexibility in how and when end users are engaged than in typical agile frameworks. In addition, we found that only certain elements specified in typical agile software development methodologies were necessary, especially those related to regular inclusion of and communication with users (steps B, D, and G). In contrast, following a formalized agile framework (such as scrum, with concerted sprints for development of particular tasks) was not needed. The wisps in step H represent how the software can have utility for additional users by being included in a subsequent round of development.

Figure 2.

User-visioning exercise (left) and discussion (right) during a user consultation workshop in Bogotá, Colombia, in 2019.