Tino 24/7 is a software-as-a-service platform for veterinary emergency centers across Germany. One animal emergency number that forwards patients to the nearest on-duty clinic, and a control surface for practice owners to set who's available, when, and how fairly the load is spread.

The case study opens on the thing that had to feel real first: a dashboard that aggregates shifts, calls, and statistics into a single overview the operator can trust at 3 a.m.

Emergency service software as a service. Simple, online, ready to go straight away. Tino 24/7 provides the solution for equitable and reliable emergency veterinary services (NFD): one animal emergency number that forwards patients, an online roster for who is on duty and when, and automated fair allocation for those who aren't configured manually.

I led product design end-to-end over roughly a year, building the modules that run the platform today: Dashboard, Scheduler, Messages, Change Request, Call History, Statistics, Tino Point Statement, Plan Generator, Widgets, and the Tino Guide.

In cases of animal emergencies, not every response center operates around the clock. Day-night clinics are few, often located far from the patient, and easily overwhelmed by cases routed to them by default.

The goal was a system that connects clinics and veterinary practices with owners of sick animals 24/7, and manages the shifts behind it so at least one center is always available in each area. Patient safety as an operating constraint, not a marketing line.

One of the central challenges in designing this product was achieving equitable shift distribution, balancing three moving variables at once: distance from the patient, volume of requests flowing into each center, and the center's own capacity to admit sick animals.

Any two of those variables can be optimized in isolation. Holding all three at once is the actual job, and the reason a naive round-robin scheduler breaks down inside the first week of real use.

I ran the full Design Thinking loop (Empathize, Define, Ideate, Prototype, Understand) transparently with the team and the first set of partner clinics. Each phase produced one artifact the stakeholders could review and sign off on.

The empathize phase was non-negotiable. Interviews with veterinary professionals and end-users surfaced the specific tensions between animal owners, vets, and clinic operators that the rest of the product would have to honor.

Research crystallized into two validated personas. John David, 38, runs a veterinary center and wants to extend services beyond regular hours without burning out staff or budget. Sophia Müller, 46, a dog owner, wants emergency care she can reach at any hour without guessing which clinic is open.

Their pain points ran in parallel: low foot traffic after hours and insufficient hand-off information on the clinic side; geographic barriers, overcrowding, and prolonged wait times on the owner side. One product had to solve both without favoring either.

To keep shift distribution fair at national scale, we segmented Germany into sectors: chambers aligned with the country's 16 states (with one state holding two chambers, making 17 total). Each chamber contains multiple clusters, and each cluster holds a set of veterinarians.

Shift plans are crafted per cluster, not per country, so fair allocation is local by construction. Distance, request volume, and capacity all resolve inside the cluster before anything is published to a vet's phone.

The admin hierarchy had to formalize an ambiguity the team had been papering over: not every chamber has an Emergency Clinic Service (ECS); and inside a chamber that does, not every cluster inherits it.

The flowchart resolves the branching logic explicitly (chamber has ECS? cluster has ECS?) into a small number of concrete states that map to specific admin responsibilities over zip codes, clinics, and vets. Ambiguity out of the spec, into a diagram every stakeholder could point at.

Authentication had to accommodate two distinct user shapes (vets and admins) and two distinct entry patterns: passwordless magic links for vets on mobile, and traditional password login for admins at a desk.

The flow resolves both branches into the correct dashboard on first login without a mode switch, an extra step, or the user having to know which kind of account they're on.

The wireframe pass concentrated on the scheduling canvas, the hardest surface in the product, where shift tables, change requests, filter modals, and group management all collide.

I mapped every branch as a low-fidelity frame so the team could interrogate the flow before pixels. Decisions about conflict resolution, bulk edits, and per-vet assignment got settled on paper, not in polish.

The design system is a greenfield one (typography, icons, colors, motion, layout, tokens, and photography) designed alongside the product rather than retrofitted onto it.

A design-tokens pipeline emits platform-specific formats (web JSON/CSS/SASS, iOS ObjectiveC/Swift, Android XML/Kotlin) from one source of truth. One change to the brand, three apps update in sync.

The final screen set spans the dashboard, sign-in, call history, plan generator, and settings. Every module is consistent with the token system and the scheduling primitives behind it.

The goal for production polish was the same as for the wireframes: make the scoring, the chamber model, and the admin logic visible, so the operator is never guessing what the system will do next.

Tino 24/7 gives owners access to emergency veterinary care around the clock, overcoming the limitations of traditional clinic hours. Users in remote or rural areas connect to their nearest day-night clinic through the app, bridging geographic gaps in access.

By facilitating appointments and streamlining processes, the platform reduces wait times at overcrowded centers, matches client demand with vet availability during off-hours to keep staffing costs rational, and carries hand-offs between centers so cases transfer cleanly even after a shift ends.