N9
A show-jump scientist wanted to explore a “Fitbit for horses.” She had an interested investor, but he still had doubts. I was brought in for research and design. After interviewing both stakeholders, I recommended a Google Ventures–style design sprint: five days to map the problem, sketch solutions, decide on one direction, prototype it, and test with customers—so they could leave the week with evidence, not opinions.
I planned a five-day sprint—Map, Sketch, Decide, Prototype, Test—and ran it in the countryside near the show jumper’s barn so we had direct access to the environment and horses. With only three people and a discovery brief (no business plan yet), I adapted the checklist: kept the day goals, dropped activities that would not help a tiny founding team, and added short facilitation breaks when energy dropped.
Before Monday, I briefed roles and the week plan, and asked stakeholders to gather research materials so Day 1 could start with shared knowledge instead of blank pages.
Prep included:
Monday’s job: understand the problem, put a journey on the wall, and pick a target for the rest of the week. I set up the workshop so materials were organised and easy to reach. We opened with a knowledge download—everyone said what they already knew—then practised a short elevator pitch so the team shared one story for the product.
We set long- and short-term goals for the project—what success would look like if the idea worked, and what we needed from this week. Each person wrote goals; we compared notes and merged them into one working note for the sprint. That note later helped when they built a business plan.
We listed problems around the horse, rider, and environment—including transport and competition. Then we narrowed to the primary problem we were solving this week and parked the rest so Day 2 would not chase everything at once.
We mapped a day in the user’s life as a critical path—step by step—so the team could see where pain, risk, and opportunity sat. That map became our shared picture of the problem space for the week.
Notes
This was my first design sprint. I was nervous at the start—I stammered, made mistakes, and got confused when my notes fell out of order.
Lessons learnt
Attend more UX workshops to sharpen facilitation. Keep a simple checklist so activities stay organised under pressure.
To deepen the map, we worked through needs, wants, and desires, and a who / what / when / where pass on use cases. We also reviewed pre-sprint research and competitor products. One constraint dominated: horses often reject attachments and can injure themselves trying to remove them—so form factor had to stay on the map.
We checked early ideas with the founder’s equine community. Practical options narrowed toward a device light enough to plait into the mane, a ride-only sensor as part of the saddle, or a horseshoe concept whose viability was still arguable.
Strong ideas that were not ready for this week went on a backburner board—production questions, competitor angles, and form-factor thoughts we refused to lose. Using open card sorting, we categorised and prioritised what remained, then cut the problem list to five. That became our sprint target: stay focused enough that Tuesday’s sketches had a clear aim.
Tuesday’s job: compete on solutions on paper—not debate a winner yet. We restarted with the elevator pitch, then opened the diverge work. (I also used a short music and cognitive reset mid-day to keep a three-person founding team sharp; that was facilitation, not a sprint ritual.)
Instead of a formal Lightning Demos round, we remixed Monday’s ideas through timed mind maps—problems, solutions, technology shape, and feasibility. Everyone exchanged notes and probed for clarity. Tough questions were encouraged; by the end we understood each other’s directions without picking a winner.
We pushed quantity with Crazy 8s. Using a timer on my iPad (Bit Timer), we sketched in short bursts and generated several directions in about fifteen minutes. Sheets were reviewed and marked for promise—still without locking a single concept for the prototype.
Each person then drew a fuller solution sketch—how the technology would sit on the horse, how discomfort would be avoided, and what the rider or trainer would see. We swapped boards and discussed differences as competing options. Unique insights stretched past the timebox; I stopped the debate there so Wednesday could do the deciding.
Wednesday’s job: critique the sketches, choose one direction, and storyboard that direction for Thursday’s prototype. We opened with short pitches, then moved the Tuesday sketches into decision mode.
We started with a silent critique: five minutes of written feedback on another person’s sketch, passed back so the owner could prepare a response. Then we opened into group critique—feasibility, viability, and equine constraints—while I discouraged over-attachment to any one idea.
We also re-checked conflicting story threads from Tuesday and pressure-tested them against implementation reality before voting with our feet toward one path.
Notes
Confidence grew here. The team worked more in sync on the problem.
Lessons learnt
Record the room—I missed crucial moments. Listen more and stay calmer in debate; short clips later showed where I argued too hard or grew impatient.
We cleared backburner ideas we would never use and compared the remaining options. Two strong directions remained: monitoring racehorses, or monitoring a horse around the clock. Decision criteria were explicit—biggest problem solved, easiest to implement, fastest to produce. We chose racehorse monitoring for the prototype.
With the direction locked, we storyboarded the racehorse monitoring journey the horse could wear without discomfort—the blueprint for Thursday. We discussed while I sketched until the sequence was clear enough to build from.
We gathered assumptions from the week and agreed how Friday would challenge them. Without a barn visit or full-size model on hand, we planned to use a printed horse image for form-factor demos alongside the software prototype, then take the same questions to target users.
Thursday’s job: fake it until it’s testable. After a short pitch practice, we built paper hardware prototypes from the Wednesday storyboard—sharpies, scissors, and timed builds—then explained how each version would be implemented and produced.
We aligned on one hardware concept against technology and equine requirements. I also built a low-fidelity companion app so Friday’s interviews could cover both device and software.
Friday’s job: learn from people outside the room. From the Facebook equine group we recruited five people with race or show-jump experience—trainers, riders, and one yard manager—and ran remote video sessions. In each call we walked through the paper hardware on a printed horse image, then the low-fidelity companion app, and asked them to think aloud against the week’s riskiest assumptions: Would a horse tolerate the form factor? Was race-day monitoring more valuable than 24-hour tracking? Did gait + temperature + heart-rate data feel useful enough to trust a “fit to race” signal?
What we tested
A mane-plait / light wearable concept with gyroscope movement sensing, temperature and ECG cues, GPS for location, and an app that showed gait patterns over time plus a simple readiness indication before an event.
What we heard
Form factor first: everyone rejected anything bulky or saddle-only for race use; a light mane or discreet wearable was the only direction they would try. Race-focused monitoring beat 24-hour tracking—“I need to know if this horse should run today,” not another always-on feed. Trainers cared most about gait change over time and a clear temperature / heart-rate flag; GPS was nice-to-have unless a horse was being transported. Scepticism landed on the AI claim: they wanted to see a short history of that horse’s own baseline before trusting any “fit to race” label.
Those reactions locked the concept we took out of the sprint: a racehorse gait monitor that learns each horse’s walking and gait signature over time, uses temperature and heart-rate context for event-day readiness, and pairs with a simple trainer-facing app—not a 24-hour wellness product.
Stakeholders agreed they had enough outside signal to write a business plan and start the next build: validate the light wearable on a real horse, and replace the AI label with “baseline vs today” until the model earned trust.
Sprint documentation Record of Map → Sketch → Decide → Prototype → Test: goals, map, sketches, decision, prototypes, and test notes so the founders could continue without losing context.
UX expert feedback Written analysis with recommendations on next steps for research, product, and business planning.
Permission request Request for permission to use project assets and media in this portfolio.