Hunt Log lets hunters record where they sat, how they walked in, what they saw, and whether they took a shot. The feature only works if a lot of hunters use it and keep using it, so I pushed for a usability study before development to find out whether they would.
Problem
Trail cameras only know what walks past the sensor. They miss the buck that showed up at 1:30 just out of range, the stand that went cold after three sits in a row, and the pressure that pushed deer off a field they normally use. Hunters see all of that from the stand. Our app had nowhere to put it.
For Moultrie, that gap matters more than it used to. The company is building an AI product that recommends when and where to hunt, and hunt logs are how it learns from real hunt outcomes. The product owner’s scope set the targets at 5% of users logging at least one hunt in the 2026 season, and 15% opening their end-of-season recap.
That puts a lot of weight on a form.
Making the Case for Testing
Nobody asked for a usability study, but I saw Hunt Log as a critical component for the company’s AI initiative. The quality of results depends on the amount of logging data, and the accuracy of that data. I wanted to make sure the logging forms were frictionless and intuitive before development.
So I told the product owner and stakeholders I was running a study, and kept the product owner updated as sessions came in. I built the study around three questions:
- Is the form balanced between the data the AI needs and the effort it asks of hunters?
- Which fields add friction without adding value?
- What could Hunt Log show back to hunters to make them log again?
We went in with one main hypothesis. Hunters would like Hunt Log but not use it habitually, because they wouldn’t see what they got back for the effort.
I also saw the study as a chance to try a new way of prototyping.
Building a Prototype That Worked
A linked Figma prototype couldn’t test what this study needed. Testers had to log a hunt, then come back later and edit that same hunt. They needed to upload a real photo from their phone and pan around a map. Linked screens can fake a happy path. They can’t fake saved data.
Saved hunts showed up on the map and in lists, and the summary pulled real past weather for the date and time the tester entered. All four task flows were working two days after the first commit.
The AI tool didn’t get everything right. Before the first session, I caught a bug that would have undermined the study. The edit task loaded a hard-coded sample hunt instead of the one the tester had just logged, so testers would have been asked to edit someone else’s.
The Study
My first plan was an unmoderated study on our existing Maze account, with heatmaps showing where testers tapped. In dry runs, the heatmap script crashed Maze tests on iOS, so I switched to moderated remote sessions. That turned out to be the better call, because the follow-up questions mattered more than anything a heatmap could have shown.
I ran six 45-minute think-aloud sessions with hunters from our research panel. They shared their screens and worked through five tasks, then answered seven debrief questions. A UX researcher reviewed my test plan, and a senior researcher co-moderated some of the sessions.
I wrote each task as an outcome, not an instruction, so none of them named a button or a screen.
What We Found
Logging Was Easy
Testers finished 24 of the 27 task attempts on record without help, and every one of them completed a full log.
”You can’t get any easier, man.”
Three of the four first-round testers expected one edit button for the whole log and were thrown by the separate edit links on each section. All four looked in My Content first when they went to start a new log, which was where they’d go to find one, but not where we’d put the button to create one.
The Reason to Log
Our hypothesis mostly held. Everyone saw value in Hunt Log, but when we asked how often they’d realistically log a hunt, 4 of 6 said “sometimes.” Every one of them currently kept their hunt history in their head.
The surprise came in the debrief. I asked testers how they’d feel knowing their logs would power AI hunt planning recommendations. One who had said “I’d probably use it sometimes” changed his answer on the spot.
”I would change my answer. I’d more than likely use it almost every time I went… so the data would be there, so it would help me have a better success rate.”
Our least motivated tester, who had said he’d rarely log, answered “No, I love that idea.” I asked every tester directly whether AI using their data bothered them. Every one said no.
That changed what I thought the problem was. We had treated the AI as Moultrie’s reason for Hunt Log, and the personal record as the hunter’s reason. For the hunters least likely to log, the AI was their reason too. The business goal and the user’s motivation were the same thing, and nothing in the design said so.
Changing the Design Mid-Study
After four sessions the same problems kept coming up, and there was no time on the schedule for a second round. Because the prototype was code, I didn’t need one. I built the fixes and deployed them the same day, then tested them with the last two testers.
- A second way to start a log. Since everyone looked in My Content first, I added a Log New Hunt button to the Hunt Logs list.
- Buck count separated from Buck List. Tapping a named buck from the hunter’s Buck List was quietly adding one to the buck count. I split them and moved the Buck List question to the top of the step. This came from what I watched testers do, not anything they said, so I flagged it as a call to keep an eye on.
- Stars instead of emoji. The trip rating went from a 1 to 5 emoji scale to three stars on its own step. One tester had said he didn’t know if he’d really click an emoji.
- A notes prompt that asks for a story. “Additional notes” became “Want to remember details from your trip? Tell your story below.”
The biggest addition was a two-screen New Feature intro that explained the AI benefit up front. The results were mixed. One tester understood it right away. The other thought the feature was for coordinating future hunts with friends. My co-moderator pinned down why in our debrief. The copy sold a future benefit, planning, for something the hunter does about the past. And the tester who misread the screen was the same one who changed his answer once I explained the AI benefit in conversation.
Two sessions isn’t proof, and I presented the version 2 results as directional. But notes went from mostly skipped to filled in without prompting.
Outcomes
Hunt Log is now in development. My co-moderator and I presented the findings to stakeholders, with usability issues separated from product questions, and they were thrilled with the study. Every recommendation was picked up, including the mid-study fixes.
One change moved past what we tested. The final design keeps stars for the trip rating but uses five instead of three, because a five-point scale gives the AI team more usable data.
The one exception was the intro screen itself. Based on its mixed results, the team is going with different copy than the version we tested. The idea stayed, since the AI benefit is still the strongest reason to log.
The prototyping method outlived the study. I trained another designer on it, and she has since run three unmoderated studies with coded prototypes, using Maze’s screen recording instead of heatmaps. The team is now building an in-house platform that hosts every active prototype with its tasks and tracks results, and Hunt Log was the first study connected to it.
Reflection
I’d try any third-party script on a real phone before building a study plan around it.
The open problem is still the intro. New copy should help, but it’s hard to sell hunters on a benefit they won’t see until the AI ships, and one screen at the start of a feature might not be enough. I’d test the message right after a hunter saves a log, when they’re deciding whether it was worth the effort.