
StrayCare App
StrayCare App
Replacing scattered rescue messages with a shared coordination workflow
Replacing scattered rescue messages with a shared coordination workflow
I designed and prototyped a rescue coordination app that helped volunteers report cases, assign ownership, and track progress in one place.
I designed and prototyped a rescue coordination app that helped volunteers report cases, assign ownership, and track progress in one place.
Roles
End-to-end product designer, researcher, and product owner
Team
President, volunteers, and a volunteer product manager
Timeline
8 weeks
Reporting time: 3–5 minutes → under 1 minute
7 of 10 volunteers felt confident their reports would not be missed
StrayCare was designed to cut rescue coordination delays by up to 30% based on validated prototypes and user testing with 10 volunteers.


The request
The request
The president and volunteers of StrayCare Foundation, (a community-driven animal-welfare organization in Belgaum, India) asked me to improve how their organization communicated about rescue cases and monitored progress.
The president and volunteers of StrayCare Foundation, (a community-driven animal-welfare organization in Belgaum, India) asked me to improve how their organization communicated about rescue cases and monitored progress.
At the time, the team relied on WhatsApp groups, phone calls, and spreadsheets. The process worked for a small number of cases, but important updates became difficult to find as activity increased.
A case could be reported in a group chat and disappear under newer messages. Volunteers could not easily tell whether someone had acknowledged it, taken responsibility, or completed the rescue.
At the time, the team relied on WhatsApp groups, phone calls, and spreadsheets. The process worked for a small number of cases, but important updates became difficult to find as activity increased.
A case could be reported in a group chat and disappear under newer messages. Volunteers could not easily tell whether someone had acknowledged it, taken responsibility, or completed the rescue.

Lack of coordination delays rescue efforts.
Lack of coordination delays rescue efforts.

Many strays cases go without timely help.
Many strays cases go without timely help.
The problem was not a lack of commitment. It was a lack of shared visibility.
The problem was not a lack of commitment. It was a lack of shared visibility.
The coordination gap
The coordination gap
When the answer lived across chats, calls, and spreadsheets, the organization spent time reconstructing information instead of coordinating action.
When the answer lived across chats, calls, and spreadsheets, the organization spent time reconstructing information instead of coordinating action.
I reframed the problem as:
I reframed the problem as:
How might we make every rescue case visible, assignable, and trackable from report to follow-up?
How might we make every rescue case visible, assignable, and trackable from report to follow-up?
Research: understanding the real workflow
Research: understanding the real workflow
I interviewed 20 volunteers and 15 community members about how rescue cases were reported, assigned, and followed up.
I interviewed 20 volunteers and 15 community members about how rescue cases were reported, assigned, and followed up.

I then ran early usability testing with 5 volunteers, focusing on two tasks:
Report a rescue case
Update the status of an existing case
I then ran early usability testing with 5 volunteers, focusing on two tasks:
Report a rescue case
Update the status of an existing case
What I learnt from the research
Rescue volunteers expressed frustration with the absence of real-time updates during a rescue process.
Rescue volunteers expressed frustration with the absence of real-time updates during a rescue process.








































75 %
75 %
80 %
80 %
Volunteers
Community members
Community members
Volunteers

Rescue Delays
Rescue Delays
Inefficiencies
Inefficiencies
25%
50%
Expressed frustration with the absence of real-time updates during a rescue process.
Expressed frustration with the absence of real-time updates during a rescue process.
The central opportunity was:
Give everyone a shared understanding of what needs attention, who owns it, and what happens next.
Give everyone a shared understanding of what needs attention, who owns it, and what happens next.
Design decisions
Design decisions
Designing the reporting flow
Designing the reporting flow
The first reporting flow asked users to make too many decisions at once. Important information was mixed with secondary details, which made the form feel slower than it needed to be.
The first reporting flow asked users to make too many decisions at once. Important information was mixed with secondary details, which made the form feel slower than it needed to be.




The design principle was:
Capture enough information to start a rescue, not every detail that might be useful later.
Capture enough information to start a rescue, not every detail that might be useful later.
Choosing how to show progress
I explored three ways to represent case progress.
I explored three ways to represent case progress.



Toggles
Toggles were quick, but they only showed whether something was on or off. They did not explain what had happened or what action came next.
Step indicators
Step indicators clarified the sequence, but they did not communicate urgency or current ownership strongly enough.
Action cards with a timeline
I chose action cards because rescue coordination is action-oriented. Volunteers needed to understand the current situation quickly, not decode a set of isolated controls.
The timeline also helped coordinators see where a case had stalled.
The timeline also helped coordinators see where a case had stalled.
Simplifying the coordinator view
The first dashboard displayed case categories, volunteer counts, and several summary sections.
Although the information was useful, the layout required too much scrolling and made urgent rescues difficult to prioritize.
The first dashboard displayed case categories, volunteer counts, and several summary sections.
Although the information was useful, the layout required too much scrolling and made urgent rescues difficult to prioritize.



I simplified the experience into a focused case list so coordinators could quickly scan. The decision was to prioritize action over overview.

Final design
The final MVP design introduced a streamlined flow for rescues:






Easy to report cases and view details about updates on the case

Final design
The final MVP design introduced a streamlined flow for rescues:






Easy to report cases and view details about updates on the case
Outcomes
Outcomes

Current State
Rescue help messages are lost in the chats.
Volunteers are not certain who is going to attend.

Current State
Rescue help messages are lost in the chats.
Volunteers are not certain who is going to attend.

Proposed Solution
Volunteers are notified of a new case. Volunteers can assign themself to the case and is visible to others.

Proposed Solution
Volunteers are notified of a new case. Volunteers can assign themself to the case and is visible to others.
User Testing
User testing revealed confusion in the reporting form, which I simplified to make it faster and more intuitive.
User testing revealed confusion in the reporting form, which I simplified to make it faster and more intuitive.
Reporting time: 3–5 minutes → under 1 minute
7 of 10 volunteers felt confident their reports would not be missed
StrayCare was designed to cut rescue coordination delays by up to 30% based on validated prototypes and user testing with 10 volunteers.
Reflection
Reflection
StrayCare taught me that the core problem was not simply reporting a rescue case. It was creating shared ownership after the report was submitted.
StrayCare taught me that the core problem was not simply reporting a rescue case. It was creating shared ownership after the report was submitted.
I also learned that product design does not happen in isolation. When WhatsApp Communities changed the organization’s workflow, it changed the value proposition of a separate product.
I also learned that product design does not happen in isolation. When WhatsApp Communities changed the organization’s workflow, it changed the value proposition of a separate product.
If I continued the project, I would explore a lightweight version that works alongside the tools volunteers already use while preserving the structured status and follow-up system validated during testing.



