Avian Impact:
Live Bird Research Platform for Field Scientists
Avian Impact is a mobile research platform that helps field monitors collect, manage, and analyze bird collision data. Used by 150+ monitors across 3 universities, with Cornell Lab of Ornithology partnership expanding to 50+ research groups nationally in 2026.
Product Designer
My Role
1 Founder
1 Product Designer (Me)
6 Software Engineers
Team
Jun 2025 โ Present
Duration
User Research
Multi-Role System
Interaction Design
Accessibility
Key Contribution
01 Real-World Impact
A great number of birds are killed by window collisions every year in the U.S. alone.
365 Million ~ 10 Billion
Every year, up to 10 billion birds die from window collisions -- surfaces they simply cannot see. The scale is documented, the cause is understood. What's missing is the infrastructure to do something about it. โจโจ
Researchers at Cornell Lab of Ornithology, the world's leading bird research institution, have described existing data collection as "piecemeal, with insufficient sampling at too few locations and times," making it nearly impossible to identify high-risk buildings, track patterns across sites, or make the case for policy change.
02 System Overview
WHERE WE ARE TODAY
3
Universities
Actively using the app
for daily field monitoring
150+
Active Monitors
Researchers, students
& citizen scientists
4,300+
Collision Records
Per university program,
per month
Launched in fall 2024 at the University of Washington, supported by the UW Campus Sustainability Fund, Avian Impact is the first mobile app built specifically for bird collision monitoring -- replacing paper-based fieldwork with real-time, structured data collection.
WHAT COMES NEXT
Avian Impact is now partnering with Cornell Lab of Ornithology. Through this collaboration, 50+ Cornell-affiliated research project groups are expected to onboard in 2026 -- expanding from 3 university programs today to a national research network.
Addressing bird collisions at scale requires more than collecting data โ it requires a system that can grow with its users, make that data meaningful, and help people act on what they learn. My design work focused on three areas across this system โ each addressing a different layer of what makes it work at scale.
03 Admin System โ Scaling for Institutions
Requirement Context
Originally, every aspect of team setup was handled manually โ new users emailed our founder, who configured accounts and set permissions directly in the backend. There was no in-app flow for creating projects, managing teams, or onboarding new members.
As more projects keep joining Avian Impact, this became a bottleneck. Every new team meant more emails, more manual configuration, and more founder time. We needed a system that lets research teams onboard and operate entirely on their own.
Final Design - designed for scaling and automation
New
Previous
Key Design Decisions
How monitors join a project
Getting monitors into the right project meant our team manually configuring accounts and permissions in the backend every single time. There was no in-app flow -- just emails and manual work that didn't scale.
The goal was: admins should be able to invite members directly, and the rest should happen automatically -- no backend intervention, no extra steps for anyone.
My first instinct was to let monitors browse and join projects themselves. But after talking with users, it was clear: monitors don't seek out projects -- they're recruited by admins before they ever open the app. So I flipped it. Admins invite members during project setup, triggering an automatic notification and whitelist entry. When monitors sign up, they're recognized and added instantly.
Admin Perspective
๐คฏ
1 Admin typically need to add 10 to 40 monitors at once โ entering emails one by one on a mobile app is tedious and error-prone.
๐ง
I noticed that admins always come prepared with a member list already. The problem wasn't collecting emails โ it was getting them in efficiently.
๐
After several rounds with the dev team, I designed the "Paste from clipboard" button. Admins copy their existing list, paste it once, and the system automatically parses individual emails by detecting commas and other separators โ turning a tedious 40-step process into a single action, with instant validation built in.
Monitor Perspective
๐
Once an admin sets up a project and adds members, monitors receive an invitation email, they simply sign up with that same email address to join.
๐คฏ
The risk was silent failure: if a monitor registered with a different email, they'd complete sign-up, land on their profile, and have no idea why they weren't in any project.
๐
I realized the fix had to happen before registration was complete . So I designed a real-time email check during sign-up: the moment a monitor enters their email, the system checks it against the whitelist and surfaces a small green indicator if it matches. One quiet signal at exactly the right moment.
Admin project creation
Our admins are mostly non-technical users โ professors and research leads who just want to get their project running. The key design challenge was breaking down a complex setup process into something simple and approachable. I restructured the project creation flow into 3 clear steps, each focused on one thing at a time.
Designing for multiple user states
We needed to guide users through different stages of their journey โ signing up, subscribing, setting up a project, or picking back up if they dropped off halfway. But the founder didn't want to touch the three existing Home screen buttons, and the team had no bandwidth to modify the profile page. There was no dedicated space for any of this.
I proposed a banner section at the top of the Home screen. It could sit above the existing UI without disrupting anything โ prominent enough to get noticed, flexible enough to change with each user's stage. I explored multiple styles and layouts across several iterations, and the team voted on the final direction. The result kept the founder's design intact while giving every user exactly what they needed to see at that moment.
Banner exploration & Team vote
Final design โ 4 states, 4 messages
User
Guest
Monitor
Citizen Scientist
Admin
Admin
Banner Status
Signed Up
โ
โ
โ
โ
Subscribed
โ
โ
โ
โ
Setup
โ
โ
โ
โ
04 Map & Filter โ Exploring Field Data
Requirement Context
Since 2022, field research data had been accumulating โ but inside the app, it all lived in a single long list. For teams with years of records across three different report types, finding a specific observation meant scrolling through everything. A filter and map view weren't just nice to have โ they were the only way to make the data actually navigable in the app.
One more constraint from the dev team: the map and the existing list view needed to share the same filter system โ no duplicate work. So whatever I designed needed to work across both.
Final Design - designed for visual data exploration
New
Previous
Key Design Decisions
Map pin system & accessibility
The original map used a single red pin for all data โ but as the platform grew to support more distinct report types, users had no way to tell them apart. During user research, I also discovered that many of our monitors are red-green color blind, and most of our data sits right on green campuses, making red pins nearly invisible against Google Maps' background.
To address these, I made two design decisions: first, I replaced red with colors that are distinguishable for color blind users; second, I gave each report type its own unique icon shape. Together, the new design makes every pin identifiable by both color and icon โ making the map not only more visually clear, but more accessible for all users.
Filtering for field context
As the map grew to support multiple filters, I noticed report types were fundamentally different from the rest โ each representing a distinct research dimension that researchers rarely needed to see all at once. Mixing them made the map noisy and hard to read. So I pulled them out of the filter panel and treated them as toggleable map layers, letting researchers focus on exactly one at a time.
Besides, I designed a "Distance from You" radius slider to help researchers quickly narrow down data around their current location โ useful when they're actively in the field and want to see what's been recorded nearby.
