WildMon
2026
CHORUS
A 0>1 bioacoustic monitoring platform enabling communities across Latin America to conduct AI analysis without relying on external expertise
TL:DR
Problem
Protected areas across Latin America are protected on paper but not monitored in practice — leaving reserves with no way to know if they’re actually meeting their conservation goals.
Without the tools or expertise to monitor their own land, reserves depend on scarce outside experts for a slow, bottlenecked process, making it difficult to guide management decisions or make the case for conservation financing.
Solution
A 0-to-1 platform that lets both experts and non-experts run the entire monitoring workflow themselves — from adding a recording site to seeing validated results on a dashboard.
Role
Solo Product Designer
Timeline
7 months
Platform
Web application
Partners
WildMon, Audubon, Bezos Earth Fund
What is bioacoustics monitoring anyway?
Bioacoustic monitoring identifies which species live in an ecosystem by analyzing the sounds they make, rather than relying on sightings. It matters because most wildlife is hard to observe directly, while sound offers a way to track biodiversity continuously and at scale.
Record
Audio recorders are deployed in reserves around the world, capturing sound continuously for weeks or months.
Analyze
The recordings are processed by species-recognition models trained to identify calls in the audio.
Output
The result is a record of which species were detected, and when and where - data that can then be visualized, reported, or acted on however a given project needs.
User Journey: Running an bioacoustics monitoring project
I conducted qualitative interviews with scientists and project managers from WildMon, as well as with our partner Audubon to map out the current processes and pain points when running a project.
Running a biodiversity monitoring project relied on external experts, and left community collaborators disconnected from the results of their field collection work.
Future state
The goal was to create a platform that would enable local collaborators to be involved in all stages of the pipeline - allowing them to run biodiversity monitoring projects on their own, without relying on external expertise.
The Roadmap
This project focused on designing, building and shipping the MVP
Importing sites
Importing sites is where the biggest data-quality risk enters the platform — everything downstream depends on getting coordinates right.
The Problem
We had no control over how coordinates were captured.
The Approach
We built the importer around the existing CSV export of apps used in the field, and introduced guardrails to prevent problematic coordinates from entering the project at all.
Initial design
An interactive review & confirm modal let users spot warnings and fix errors on the spot.
Duplicate coordinates and existing site names surfaced as warnings; invalid coordinates were blocked outright.
Contraint
Functionality tested well with users, but engineering feasibility ruled out inline correction for this release.
Iteration
We compormised to reduce functionality for the MVP
Users would be alerted to warnings and errors, but had to make corrections in a CSV and re-upload it, rather than fixing them on the spot.
The problem
Usability testing scored well on both, but surfaced two issues:
01 Everyone downloaded the report right after seeing errors, before ever reaching the warnings screen.
02 It wasn't clear "download report" meant a CSV — some assumed they'd have to reopen their original file and hunt for the problems themselves.
Final MVP design
Where we landed
Errors and warnings are introduced on the same screen, and button CTA clarifies that report is a CSV.
Building a species list
For the AI to detect species in a recording, someone first has to tell it what to listen for.
A list of potential species could be generated in 3 ways:
01 Region of interest
An occurrence database could pull up species that have been detected in a certain radius around each site
02 Search
Manually search and add species to the list.
03 CSV Import
Import an existing species list.
Initial design
Automated list generation by region of interest.
The team was focused on automating whatever was possible. Here it meant starting the generation flow by asking user what animal group they were looking to detect (to determine appropriate taxonomy and occurance database), and then automatically generating the species list by region of interest.
The risk
While this would serve most non experts - it added unecessary friction for expert users
Those who wanted to manually select what species to search for, or had a CSV list to import, had to first delete the generated list, and then populate species from their preferred method.
For those who were actually interested in the region of interest generated list - there was no clarity on how the list was generated.
A product pivot
Reducing MVP scope
Due to tight project deadlines, a decision was made to only enable eBird as a taxonomy option for the MVP.
With the removal of the taxonomy question, and the principle of “automate whenever possible”, the plan was simple: drop the taxonomy screen, and instantly generate the species list for the user (still based on region of interest).
But… this caused a major problem
Dropping the question didn’t just remove a step — it removed the one moment a status system I’d already built depended on to know when a list had gone stale.
Final MVP design
Where we landed
Asking the user for their preference upfront
I pushed for a solution that would solve both problems: bring the question back — not about taxonomy anymore, but about how someone wants to build their list in the first place.
The outcome:
A path that better served all user groups, as users with different list generation preferences had their own path,
A trigger that could notify the user when their list had gone stale.
Users who chose the region-of-interest method could understand how their list was generated — closing the transparency gap experts had run into earlier.
Validation Strategies
For every species, a human has to manually validate all the clips detected by the AI to ensure they are true presence of the species. Validation was the most manual-effort step in the pipeline — up to three weeks of full-time review on large projects.
The current state
This was a section in the pipeline that already had an interface, but it had some problems…
Validation strategies (filters) were hidden under a “sort” label
Filters were used constantly, but they were ephemeral with no permanence.
The current progress tracker was useless
The tracker measured against every detection, but validators were never validating all detections. Strategy filters did not reflect the results in the tracker.
Non-experts had no way to know which validation strategy actually fit their goal.
The current state only served expert users. Choosing a strategy meant already understanding what each one was optimized for.
User Needs
WIldMon’s own biodiversity scientists were the ones most familiar with the current interface. I conducted informal qualitative interview with 3 scientist to understand their process and pain points in depth.
01
Non-expert validators needed to focus their effort on the detections that actually mattered.
02
Project coordinators needed a way to track progress to manage time and resources.
03
Validators needed to work toward two strategies at once — one validating for model training while another validated for species inventory, on the same project.
Validation Strategies
For every species, a human has to manually validate all the clips detected by the AI to ensure they are true presence of the species. Validation was the most manual-effort step in the pipeline — up to three weeks of full-time review on large projects.
The current state
This was a section in the pipeline that already had an interface, but it had some problems…
Validation strategies (filters) were hidden under a “sort” label
Filters were used constantly, but they were ephemeral with no permanence.
The current progress tracker was useless
The tracker measured against every detection, but validators were never validating all detections. Strategy filters did not reflect the results in the tracker.
Non-experts had no way to know which validation strategy actually fit their goal.
The current state only served expert users. Choosing a strategy meant already understanding what each one was optimized for.
Validation strategies (filters) were hidden under a “sort” label
Filters were used constantly, but they were ephemeral with no permanence.
The current progress tracker was useless
The tracker measured against every detection, but validators were never validating all detections. Strategy filters did not reflect the results in the tracker.
Non-experts had no way to know which validation strategy actually fit their goal.
The current state only served expert users. Choosing a strategy meant already understanding what each one was optimized for.
User Needs
WIldMon’s own biodiversity scientists were the ones most familiar with the current interface. I conducted informal qualitative interview with 3 scientist to understand their process and pain points in depth.
01
Non-expert validators needed to focus their effort on the detections that actually mattered.
02
Project coordinators needed a way to track progress to manage time and resources.
03
Validators needed to work toward two strategies at once — one validating for model training while another validated for species inventory, on the same project.
The strategy
It’s unnecessary to validate all detections
Depending on the goal of the project, validators might only need to validate the top n detections of each species for each site, or for each day. If a user is interested in training a model, they would need to validate n detections across each confidence band.
Validators weren’t reviewing random clips, they followed a specific strategy based on their project goals
My idea was to remove filters that were goal related from the page and turn them into something structural and persistent: a named validation strategy that didn’t just filter the detections on the page, but explicitly scoped what “complete” meant.
We turned ephemeral filters into a named, persistent validation strategy.
“Best per site” became a strategy instead of a filter — giving the tracker a defined scope to measure against, and giving non-experts a named, chooseable path toward the detections worth their time.
Strategies could be personally set, but admin-recommended.
TBD text here
Initial design
Project admins add strategies that reflect their project goals directly to the project. Validators will only have acces to these strategies.
The problem
Validators had no flexibility to explore strategies outside what an admin had added.
Too much reliance on admin configuration.
Iteration
We opened access to every strategy, let validators create their own, and let admins signal the project's goals to guide validators to the ideal validation methods.
The problem
the same modal had to serve both first-time setup and later swaps — its copy only worked for one.
The modal's heading talked about configuring goals, but its CTA read "Apply strategy" — a mismatch that left it unclear whether you were changing your personal strategy or the project's shared goal.
The "Swap" entry point that opened this modal never hinted goals could be set there at all. Splitting these into two interfaces fixed the confusion, but cost more dev time than the team could take on.
Final MVP design
Where we landed
The fix was structural, not just cosmetic: split the panel into two tabs.
Strategies lets anyone switch their own view instantly, with an explicit note that it doesn't affect what other users see.
Project goals is admin-only, requires an explicit save, and marks the team's recommended default. Same underlying data, two interfaces — because they were never really the same action.
Current state
A title here
WildMon (internal users)
(copy TBD)Show a visual of the current state. Reference the user research figjam of the user journey, with pain point summarized. Explain that currently, WildMon was already conducting this analysis internally. Some steps had an interface with lots of pain points already captured. Other steps had no UI.
TBD
Solution Overview Videos
Discovery
User Research
Heading here
Talk about not having access to external users, but conducting in depth interviews with WildMon employees who were the expert users of the platform, and gathering feedback provided by the team over the last few months
User Journey
Talk about not having access to external users, but conducting in depth interviews with WildMon employees who were the expert users of the platform, and gathering feedback provided by the team over the last few months
Explore more
Hi, I’m Anne,
a product designer who makes complicated, high-stakes tools make sense.
I’ve designed across industries, from banking to biodiversity conservation. Diving into an unfamiliar domain is what excites me.