2026
CHORUS
CHORUS is A 0→1 platform for discovering and monitoring wildlife through audio recordings, assisted by AI. Designed for both biodiversity scientists and non-expert community members.
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.
Challenge
WildMon was hired to build a platform to scale community monitoring across Colombia, Peru, and Bolivia.
But WildMon's own experts needed it too. Their existing pipeline was only partly built, with an interface for some stages and none for others.
Solution
A 0→1 platform that lets both experts and non-experts run the whole monitoring workflow themselves. From importing site coordinates and audio, to seeing validated results on a dashboard.
Role
Solo Product Designer (Contract)
Timeline
7 months
Platform
Web application
Org
WildMon
Partners
Audubon, Bezos Earth Fund
What is bioacoustics monitoring?
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.
1 Record
Audio recorders are deployed in reserves around the world, capturing sound continuously for weeks or months.
2 Analyze
The recordings are processed by species-recognition AI models trained to identify calls in the audio.
3 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 5 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 monitoring project.
The Roadmap
This project focused on designing, building and shipping the MVP
Feature 1
Importing site coordinates
Each time a recorder is deployed at a site, the site's coordinates are logged. They tie its recordings to a location and decide which species the AI listens for, which site a detection is credited to, where results appear on a map, and where the recorder is placed again if the study runs a second round. Since they're captured in the field, they have to be imported into the platform.
The Problem
Importing sites is where the biggest data-quality risk enters the platform. Field data collection was out of scope, so we had no control over how coordinates were captured. If bad data entered the pipeline, it would derail the quality of the downstream data.
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 platform at all.
1st Iteration
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 editing for the MVP.
2nd Iteration
We compromised 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.
Usability testing
Usability testing 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.
Where we landed
Errors and warnings are introduced on the same screen, and the CTA clarifies that report is a CSV download.
Feature 2
Building a species list
A single reserve can hold hundreds of species, and many sound alike, so the AI needs a list of the ones that could plausibly be there. The list narrows its search and lets the platform filter out detections that don't belong, which cuts false positives.
For the AI to detect species in a recording, someone first has to tell it what to listen for.
Context
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.
Feature 3
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.
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. “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 path toward the detections worth their time.
1st Iteration
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.
2nd Iteration
A single modal handled both first-time setup and later swaps, with a toggle marking each strategy as a project goal.
The problem
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.
Final Design
Admin View
Two tabs in one panel — a personal Strategies view, and an admin-only Project Goals tab — replacing the blocking entry with a lightweight default state.
Validator view
Setting a project goal is a lightweight tag, confirmed instantly with a toast. Swapping your own active strategy is heavier, since it drives real recalculation — so that action keeps an explicit confirm step. Clicking “set project goal” from anywhere also jumps straight to that tab, rather than asking the admin to find it themselves.