Keeping cool when a lake day turns dangerous.
How I built an interactive story that teaches dog owners to spot heat stroke, cool a dog safely, and get to the vet.
I've been working at a vet clinic in Texas for nearly three years. This past summer in particular, we dealt with quite a few heat stroke emergencies; between phone calls and walk-ins, it felt like a big jump from previous years. I would feel a lot of anger and judgment toward the clients, since this is something that is easily preventable. What I realized after those feelings subsided, though, is that it likely wasn't willful neglect, but a simple lack of education on the matter.
That experience is where Callie and Tay came from. It is a short e-learning module, roughly ten minutes long, that follows a woman named Callie and her French Bulldog, Tay, through a lake day that goes wrong. The names are a pun, by the way; say Callie and Tay out loud and you get caliente, the Spanish word for hot. I wanted something a dog owner would actually finish, rather than a list of symptoms they would skim and forget. Since this was a solo project, I took the reins on all of it: research, learning objectives, story structure, scripts, visual direction, and directing the AI tools that helped me build it.
Purpose
Heat stroke is one of those emergencies where the owner is the first responder, whether they know it or not. A dog can't tell you she is overheating, and by the time it is obvious, a lot of the damage may already be done. What an owner does in the minutes before reaching the clinic matters a great deal.
I started by asking a veterinarian a simple question: as a DVM, what would you consider critical for owners to know? Her answers were pretty practical. Be careful once temperatures climb past 80 degrees, be extra careful with flat-faced breeds, keep shade and water close, and use a towel soaked in cool water during transport. From her key points and my own reading, I landed on three learning objectives:
Give owners a clear understanding of what heat stroke is
Provide tools to help owners identify heat stroke symptoms
Educate owners on best practices for first aid while transporting their dog to a veterinarian
I also knew what I did not want. Most pet safety content I came across was a wall of bullet points; accurate, but not something that sticks when you are standing in the sun with a panting dog. The goal was for the learner to feel how easy the signs are to miss, and then practice catching them.
The Learner
To keep my decisions grounded, I put together a proto-persona for the kind of learner I pictured taking the module. It is assumption-based; it comes from the veterinarian's key points and the kind of clients I see at the clinic rather than formal interviews.
Lake Day Leah
Age: 31
Occupation: Dental hygienist
Dog: Biscuit, a 3-year-old French Bulldog (her first dog)
Tech comfort: Lives on her phone, but has no patience for anything that feels like a compliance course
What she knows: Never leave a dog in a parked car. Beyond that, not much.
What she gets wrong: Assumes Biscuit will slow down or find shade if he gets too hot, and that ice is the fastest way to cool a dog off
Motivator(s): Leah takes Biscuit everywhere in the summer and wants to keep doing it. She would do anything for him; she just doesn't know what she doesn't know.
Leah shaped a few things right away. The module had to be short, it couldn't talk down to her, and it couldn't make her feel like a bad owner for missing something. That last point ended up driving a rule I held to for the entire project: there is no fail state. Choosing wrong costs time on screen and Tay visibly gets worse, but the learner always gets the chance to fix it.
Process
Planning the Story
Before anything was built, I worked everything out in Craft (productivity/note-taking app similar to Notion): research notes, a user flow for each part, story beats, dialogue scripts, and a visual asset brief. The structure I settled on was an intro and three parts.
The idea the whole module hangs on is that the second part is the first part turned inside out. In Part 1, the learner plays as Tay, sniffing around the lake for food. There are four leads to investigate in any order (the cooler, the dock, her water bowl, and the lake), and every one of them is quietly a heat risk factor. Tay narrates the whole thing with total confidence, and she is wrong about all of it. There are no wrong clicks, but a clock in the corner moves forward with every lead. The learner spends an hour of that dog's afternoon without realizing it.
Part 2 is the same afternoon from Callie's side. Tay says one line and then goes silent, and the learner has to work out what is happening from the outside: checking her gums, feeling her ears, watching her panting, and seeing if she responds to her name. Callie never gets a temperature readout, and neither does the learner. After all, a real owner wouldn't have one either. From there it is a call to the clinic, cooling Tay down, and the drive in. Part 3 takes place at the clinic, where the vet walks back through everything the learner saw and did, and it closes with a printable take-home sheet.
Building It
This is where the project became pretty different from anything else in my portfolio. Rather than using an authoring tool like Storyline or Rise, I built the module as a static site (plain HTML, CSS, and JavaScript, with no build step) using two agentic coding tools, Claude Code and Google's Antigravity. My own role ended up being closer to a creative director than a developer. I wrote the briefs, made the final calls, and reviewed the work.
How I used them changed over the course of the project. I started out with Claude exclusively; at one point there were three Claude agents working in parallel on separate pieces, with one on voiceover and audio, one on Part 2, and one on the design system. Then I jumped over to Antigravity and worked in it exclusively for a stretch. It wasn't until later that I realized I didn't have to pick, and that I could use the two at the same time.
Each one turned out to be better at a different kind of work. Claude's Opus model was stronger at the thinking tasks, such as planning, making judgment calls, and reviewing. The Antigravity agents were more efficient at the heavy lifting. So I settled into a split, with Claude acting as the project manager and Antigravity doing the execution. It also made for much more efficient token usage, since I was no longer spending my best thinking tool on routine edits.
In practice, that looked a lot like handing work to a small team. Claude would break a round of work into phases, write the specs, and decide what to cut or keep. Antigravity agents would then carry it out. For the Part 3 overhaul, for example, Antigravity first produced a beat-by-beat inventory of every click in the act, Claude used that inventory to decide which interactions to trim or merge, and Antigravity made the edits. The artwork went the same way; Claude wrote the shot list and the expression each line of dialogue called for, Antigravity generated the images and wired them into the scenes, and Claude checked every image against the style brief before it was allowed in.
Each phase ended with a gate. Claude would walk through the act in the browser, forwards and backwards and with the keyboard only, and nothing moved on until it passed. Evaluation worked in a similar way, with Antigravity drafting the findings, Claude ruling on them, and Antigravity applying the fixes. Any decision that was really a design decision came back to me. Keeping the one doing the work separate from the one checking it caught a lot of mistakes that a single tool grading its own work would have let through.
Skills played a big part in keeping all of this consistent. I had two written specifically for this project. The first scaffolds a new part of the story, so that every screen controller follows the same structure and stays compatible with my editing tools. The second requires an agent to load its own change in a browser, exercise the actual interaction, and report what it saw rather than what it expected to see. That one alone cut down on a lot of should work now answers that didn't.
I also brought in Tommy Jepsen's open-source awesome-ux-skills set and scoped it to the project. The ones that got the most use were the heuristics review (Nielsen's ten), the general design review, persuasive UX (Fogg's tools), visual craft, and accessibility. These had a direct impact on the work, since the agents were now critiquing against the same frameworks I would reach for myself, and citing them in their findings. The heuristics pass turned up problems with back navigation and state continuity. The visual craft check counted over a hundred spacing values in Part 3 that had drifted off the 4px scale my own design language called for.
The other tools filled in around that. Callie's voiceover was generated with Magnific, and Tay's barks and huffs are public domain recordings. The illustrations were generated from character model sheets and a locked style brief so that Callie and Tay would look like themselves from scene to scene.
I'll admit that keeping Tay's face consistent was more of a fight than I expected. Character drift is a known problem with generated art, but a flat vector style makes it worse. With no outlines, gradients, or texture, a French Bulldog's face comes down to a handful of shapes: the white blaze up her muzzle, the bat ears, and two solid black eyes. There is nothing else for the eye to anchor on, so a small change to any one of them reads as a completely different dog. The blaze would shift, the ears would change shape, or a catchlight would sneak into her eyes. Tay is also in nearly every asset, so there were a lot of chances for it to go wrong. The fix was to always generate from the model sheet rather than from a text description, and to write the repeat offenders into the negative prompt.
The single most useful thing I did was build my own feedback tool before building much of anything else. Describing visual changes in words gets old fast, so I had an Edit Mode added to the module itself. With it, I can drag and resize elements right in the browser, edit text in place, and pin sticky notes to anything on screen for the next round of revisions. One of my notes on the water bowl, for example, pointed out that it was a hot day and some of that water should have evaporated by now. Every edit is snapshotted automatically, which saved me more than once.
Refining It
A lot of the refinement came from reading my own work with a critical eye. An early draft of Part 2 had a bystander at the lake who suggested packing Tay in ice. I cut him. The ice idea is now presented as something everyone knows, so the learner ends up overruling their own instinct, and nobody in the story has to play the fool.
Using those review skills, I also had a full design review run on Part 3, which turned up a handful of things I had missed. The clock was ticking forward on every line of dialogue for no reason. The persuasive UX lens also caught a button labeled Skip ahead in the one spot where I most wanted the learner to stop and think. Both were easy fixes, but I wouldn't have caught them on my own.
As the parts piled up, I wrote a design language document to keep them consistent, covering color and type tokens, spacing, motion, and component anatomy. The module was built to WCAG 2.1 AA, with computed contrast ratios, full keyboard operability, and reduced motion coverage. One success criterion mattered more than usual here. Gum color is a key symptom, so the module never uses color alone to carry it; every gum check pairs the color with a label, a fill pattern, and the capillary refill time in seconds.
The Take-Home Sheet
The part I am most proud of comes at the very end. Once the story wraps up, the learner gets a one-page fact sheet they can print and keep. A ten-minute module is easy to forget by the next hot weekend, but a sheet of paper on the fridge is not.
The sheet steps outside of Callie and Tay's story on purpose. It is written for any warm day outdoors with any dog, whether that is a hike, a beach trip, or the backyard. It is laid out in four bands: the numbers worth remembering, habits for before and during the day, the warning signs ordered from early to late, and what to do if it happens. Every fact on it is one the module already taught, worded the same way and tied back to its source, so nothing on the page is new. It is the story boiled down to what an owner needs in the moment.
It also took more passes than I expected to get it to print cleanly on a single letter-size page, and to make it readable on a phone, where it takes over the full screen.
Early Feedback
I had my wife, a friend, and one of my colleagues try the module. For the most part, they moved through it without much trouble. The one place I noticed any of them struggling was the car transport scene in Part 2; it was not immediately apparent what they were supposed to click on, so I'll need to revisit the visibility of the controls there.
Next Steps
The interaction design and the story are in a good place, but the module is still a proof of concept, and I have labeled it that way. The veterinary content needs a full review by a subject matter expert before anyone should rely on it. The biggest open item is whether to cool with ice or with cool water; the veterinary literature has shifted on this, so I flagged every affected line in the code so the correction can be made in a single pass.
On the design side, the first fix is the car transport scene, where the clickable controls need to stand out more. After that, I'd like to move past informal feedback and run a proper round of testing with dog owners. There are two things in particular I can't answer on my own. Does the outcome for learners who chose to wait come across as information or as blame? And does the quiet stretch in the waiting room build tension, or does it just look broken?
Conclusion
I went into this wanting to teach three objectives, and I came out of it with a much stronger feel for how story structure can do the teaching for you. Letting the learner cause the problem as Tay before having to solve it as Callie did more than any list of symptoms could have, and the take-home sheet gives them something to hold onto after the story ends. I also learned that working with AI tools doesn't take the design decisions off your plate. If anything, there are more of them, and they come at you faster. As for Callie and Tay, they made it home just fine. The module still has a bit further to go before it can say the same.
See It for Yourself
The module is live and free to play in any browser. It takes about ten minutes and is best on a laptop, or on a phone turned sideways. Please keep in mind that this is a proof of concept and not veterinary advice. The veterinary content has not been fully reviewed by a subject matter expert, so it should not be used as a reference in an emergency. If you think your dog has heat stroke, start cooling them and call your veterinarian immediately.