Health Monitoring Domain Research 0→1 High Fidelity

Equitek — Horse Health
Monitoring App

A full high-fidelity prototype for a racehorse health monitoring platform — built on AI-assisted research and domain learning from scratch. The client reaction said more than any metric could.

My Role
Solo Designer
Target Market
UAE / Dubai racing teams
Organisation
IVI, Maynooth University
Output
Full high-fidelity prototype

A hardware product that needed a brain.

Equitek came to IVI with a hardware-first problem: they were building a wearable sensor patch for racehorses to monitor health and performance data in real time. The sensor was the product — but they needed a companion app to make that data meaningful to the people managing the horses.

They had a target market — racing and stable operations teams in the UAE, particularly Dubai — and wanted a prototype to demonstrate the concept to investors before the hardware was production-ready. There was no existing design, no validated feature set, and no design precedent to borrow from.

The real challenge: Design a credible, detailed health monitoring experience for a domain where I had zero prior knowledge — well enough that domain experts would trust it.

Learning the domain before touching Figma.

The first thing I did was a structured discovery session with the Equitek founders — not to gather user research, but to understand what they already knew: target users, competitive landscape, technical constraints of the sensor, and which metrics they considered essential.

I then mapped the existing equine monitoring market — Equimetrics, HorsePal, Hoofstep, Steed, Horsano, and Arioneo. Most were built for vets and data analysts, not stable staff making fast decisions under pressure. That gap — accessible, actionable monitoring for operations teams — became a core design principle.

💡

Key insight: The goal of the app was not to show data — it was to show whether the data was normal for this moment. That distinction drove every information hierarchy decision.

Building a reference system from scratch.

Using AI-assisted research and secondary sources, I built a detailed understanding of equine health metrics — structuring data into reference tables to make real design decisions about what to display, what thresholds trigger alerts, and how to visualise performance across a race session.

Vital MetricNormal RangeAlert ThresholdWhy It Matters
Heart Rate40–180 bpmAlert above race zonePrimary indicator of exertion and cardiac stress
Body Temperature37–38.3°CAlert on recovery slowdownFlags heat stress and infection risk
Blood Glucose85–115 mg/dLAlert on fatigue-related dipsEnergy availability and metabolic stress
Oxygen Saturation>94%Custom recovery thresholdsRespiratory efficiency and endurance capacity
Gait / MovementSymmetry index >90%>10% asymmetry = alertEarly detection of lameness or injury risk

Gait analysis added another layer of complexity. I mapped gait types to race phases so the app could surface contextual warnings — not just raw numbers.

Gait TypeDescriptionSpeed RangeRace Phase
Walk4-beat, slow and steady4–6 km/hPre / post race
Trot2-beat, diagonal pace8–12 km/hWarm-up (Q1)
Canter3-beat, smooth16–27 km/hBuild-up (Q2) · Cooldown (Q4)
Gallop4-beat, fastest gait40–65+ km/hPeak intensity (Q3)

Three modes of use. One coherent system.

With enough domain knowledge to make intelligent decisions, I moved to IA. The core question: what does a racing operations team need to see, and in what order?

Mode 01

Live monitoring — real-time vitals during a race or training session, with threshold-based alerts surfaced immediately.

Mode 02

Session review — post-session analysis across Q1–Q4, showing how each metric tracked against expected ranges for that phase.

Mode 03

Horse health history — longitudinal records per horse, enabling trainers to spot patterns and make informed decisions about training load.

Validation

IA was validated with the Equitek founders before wireframing. Their feedback removed out-of-scope features and sharpened the focus on the core monitoring experience.

Equitek information architecture and user flow
Information architecture — three modes and the flow between them

Six screens. A complete product vision.

The prototype covered the full core experience — from a high-level fleet view to individual horse session breakdowns and alert management. Every screen answers a specific question a racing operations team member would have in a specific moment.

Horse Dashboard
At-a-glance view of all monitored horses with status indicators — green, amber, red based on active alerts.
Live Monitoring View
Real-time vitals with HR zone indicator, gait status, speed, and active alert feed. Designed for fast comprehension under pressure.
Session Performance View
Q1 to Q4 breakdown — showing not just what happened, but whether it was expected for that phase of the race.
Alert Detail Screen
Specific alert with full context — which metric, which threshold was breached, which segment it occurred in.
Horse Health Profile
Historical data, past sessions, and longitudinal trends per horse — the long-term view that supports training decisions.
Threshold Configuration
Custom alert thresholds per horse — because no two racehorses have identical baselines.
Equitek dashboard and live monitoring screens
Horse dashboard and live monitoring view
Equitek session performance and alert screens
Session performance view and alert detail screen
Equitek health profile and settings
Horse health profile and threshold configuration

The silence said everything.

When I presented the prototype, the founders went quiet for a moment before responding. They had not anticipated the level of detail — they had expected something much more surface-level.

"They had not thought about the app at such a detailed level and were not expecting this."

— Equitek founders, on seeing the prototype

They requested removal of a small number of screens outside their immediate scope. The core monitoring experience was approved without significant changes.


From zero domain knowledge to investor-ready.

A full high-fidelity prototype built from zero domain knowledge through structured research, competitive analysis, IA validation, and iterative design. The prototype serves as Equitek's demonstrable product vision for investor conversations — and also functions as a specification document for what data the sensor needs to capture.

The biggest gap was the absence of actual user research with racing operations teams. The domain research was thorough — but it was research about horses, not research with the people who manage them.

The founders were the proxy for the user throughout, which worked for a first prototype but would not be sufficient for a product moving toward real deployment. If there is a Phase 2, the first thing I would push for is access to a few operations team members in Dubai for even brief interviews.

← Execit Next case study Smart Factory →