Whiskerville

Whiskerville was designed around a simple observation: The hardest part of rescue work is often coordination, not compassion.

Explore Whiskerville
Whiskerville's dashboard showing a summary of the organization's capacity and pending action items.

Overview

Many foster-based rescues operate through a patchwork of Slack messages, spreadsheets, shared drives, text chains, and informal institutional knowledge — patterns I became deeply familiar with while volunteering in animal rescue. Critical workflows — foster placement, transportation, clinic planning, sitter coordination, supply requests, and medical tracking — are often fragmented across multiple tools with little operational visibility.

Whiskerville explores how thoughtful workflow design and systems-oriented UX can reduce that coordination burden without losing the flexibility and humanity rescue work requires.

Instead of forcing rigid enterprise-style processes, the product was intentionally designed around the messy, real-world realities of foster operations:

The goal was building software that feels operationally powerful while remaining calm, flexible, and humane.

What I Focused On

This project focused less on basic record management and more on operational coordination.

The primary design goal was to reduce organizational overhead for foster-based rescues without making the workflows feel rigid, bureaucratic, or overly “enterprise.”

Instead of treating the system as a collection of disconnected CRUD screens, I focused on:

A major challenge was balancing structure with flexibility.

Real rescue operations are dynamic:

The system needed to support those realities without forcing users through rigid administrative processes.

The Animal page, showing a clear view of the pet's intake details, medical history, placement status, and other key information.

Key areas:

Product & UX Decisions

Foster placements as first-class operational objects

One of the most important architectural decisions was treating foster placements as distinct operational entities rather than simple fields attached to an animal record.

Animals frequently move between foster homes due to:

Tracking placement history became operationally important for continuity, accountability, and historical context.

Instead of overwriting a single “current foster” field, the system models:

This allowed the UI to present foster history as a coherent operational timeline instead of disconnected administrative updates.

Each animals' foster history is presented as a timeline of placement events, showing the date of each placement, the foster, and the reason for the placement change.
Foster assignments can be easily modified or reassigned.

Designing for real rescue workflows instead of theoretical normalization

A recurring product challenge was resisting the temptation to over-structure workflows in ways that looked clean technically but created friction operationally.

For example:

In many cases, strict one-to-one relational modeling would have made the workflows slower and less humane to use.

The goal became:

normalize where it helps the humans — not just where it helps the database.

This philosophy heavily influenced:

Supply Request forms, showing the ability to request supplies for a specific foster parent or animal.

Timeline-driven operational visibility

The timeline became the backbone of the animal detail experience.

Rather than separating operational history across multiple disconnected tabs, the system organizes activity chronologically:

This creates a clearer mental model for volunteers and coordinators:

What happened to this animal, and what happens next?

To reduce noise, the timeline supports filtered operational views:

This preserves clarity while still allowing focused operational review.

The timeline view, showing a chronological list of activities for an animal, including intake, foster placement, medical updates, notes, and clinic events.

Transportation and temporary coverage as coordinated workflows

One of the biggest operational insights from real rescue organizations was how much coordination work happens outside formal systems.

Transportation requests and temporary foster coverage are often managed through:

Whiskerville introduces structured coordination workflows while intentionally keeping them lightweight.

Examples include:

The goal was reducing communication chaos without making volunteers feel like they were filing enterprise tickets.

Sitting Requests allow fosters to request temporary coverage for their animals, ensuring continuity of care even when they are unavailable.

Clinic coordination as an operational system

Clinic planning became one of the most systems-oriented areas of the project.

Trap-neuter-return (TNR) organizations frequently coordinate:

These workflows are often managed manually through spreadsheets and Slack coordination.

The clinic planning system explores:

Rather than treating clinics as isolated appointments, the system models them as operational coordination hubs.

Clinic planning page, showing a view of the clinic's schedule, contacts, slot management, animal assignments, veterinarian and location tracking, and operational readiness visibility.
Clinic schedule page, showing a view of the upcoming clinic events.

Visual & Interaction Design

The visual system was intentionally designed to feel calm, trustworthy, and operationally clear.

Many operational tools become visually overwhelming because every workflow competes equally for attention.

Whiskerville instead prioritizes:

The goal was making operational work feel approachable rather than administrative.

Whiskerville was designed with soft surfaces, clear spacing systems, and lightweight status signaling.

Interaction principles

Whiskerville emphasizes intuitive, simple workflows over rigid forms.

Systems Thinking

Although Whiskerville is currently a front-end portfolio project, the system was intentionally designed around realistic operational architecture.

The platform assumes coordination across:

The primary systems challenge was not simply storing data correctly.

It was designing workflows that reflected how rescue organizations actually operate in practice.

For example:

These operational dependencies shaped both the information architecture and the interaction design.

A core project goal was ensuring that:

operational complexity becomes understandable instead of overwhelming.

Trade-offs

This portfolio version intentionally prioritizes workflow quality and operational modeling over full production completeness.

The current implementation uses:

This allowed the project to focus on:

…rather than generic administrative tooling.

Why this approach
Building fewer workflows with stronger operational realism created a more meaningful exploration than attempting to build a generic all-purpose animal database.

The goal was demonstrating how thoughtful product design can improve real coordination-heavy operational environments.

Result

Whiskerville became an exploration of how operational systems can remain humane, flexible, and approachable even as organizational complexity grows.

The project reflects my interest in building products where:

…all reinforce each other instead of existing separately.

Rather than treating rescue work as a collection of forms and records, Whiskerville approaches it as a living operational system centered around coordination, trust, and care.

— Dan Thoreson