Metrics Design Philosophy¶

Our metrics design philosophy has been developed and tested through many years building solutions for clients and internal initiatives alike. It is based on a variety of different frameworks, from the Open Standards for the Practice of Conservation to Systems Thinking to Human-Centered Design (see list of inspirations below).

To be honest, very little in this philosophy is new. What is unique about it, however, is its synthesis of these various frameworks. Human-centered design typically assumes you already have your solution, and are simply adding a new feature. Open Standards/Systems Thinking are focused on identifying the right place to intervene - but are, in my opinion, lacking in specifics as to how to design and implement a successful solution. Bringing the concepts within these processes together creates a more holistic, and hopefully impactful, approach to conservation.

So how is it unique?¶

There's a few key characteristics of this philosophy that make it unique.

People-first: This philosophy is unapologetically people-centric. We seek to change people's behavior to achieve our conservation targets. We do that by solving people's problems or creating new opportunities for people. If changing human behavior isn't at the core of your problem or central to the success of your strategy, this isn't the right process for you.
Evidence-driven: Prepare to test every assumption! We seek evidence from the very beginning of the process - we do not wait until we've implemented the program to start testing our assumptions. Importantly, we do not even entertain solutions until we have strong evidence that the problem exists and that solving it will help achieve our conservation target. And we never commit to our solution unless we see results in the real world.
Inside-out: If you're used to spending years developing the perfect program, creating a monitoring plan, and then seeing what happens, this might be disorienting. Instead, we'll start with the most core functionality - the smallest solution we could build while still meeting the need - and use that to test our assumptions. Once we have some positive evidence that our solution is working for our intended users, we'll build the next piece. We'll greatly reduce the chances of wasting our time (or even making the problem worse) if we fail fast and fail small, as some like to say. Once we've found success, we iterate and scale up.

The Process¶

We've codified our philosophy into a seven step process. Each step is described in more detail on the pages linked through here. Also, note that there are templates, additional guidance, and other resources available in Additional Resources, many of which are referenced within these linked pages.