A one-hour research shareout recently ran to two and a half hours. The extra ninety minutes were the team building on the findings: everyone standing on the same evidence, riffing and improvising on the story the data was telling about the upcoming product experience needs. The key to all of it was that I had managed to make myself a tool to aid my research.
The tool let me build the user story in a clean manner, where my team members could trace from observed behavior, to measured cost, to a design rationale, to a specific proposal. That shrinking of the recording, to data annotation, to design rationale, basically created a conceptual map that helped others navigate to my location on user understanding. The footage shows the behavior. The measurement quantifies it. The rationale connects it to a decision. They could see the corridors, the turns, and the steps taken to get to the conclusions.
A research instrument is not for producing numbers. It is for producing a shared object that a team can gather around.
Building a place to stand on
Having truly usable instrumentation for your specific niche of HCI has always been tough if you are not in core product ops. Most tools get priced like they expect a grant number at checkout. If the instrument didn’t exist, the analysis didn’t happen. Or we made accommodations, by reminding ourselves that we are not doing academic research in organizational settings.
Doing LLM-assisted coding myself, this problem seems to be showing signs of malleability, at least for me. I have spent a whole series sobering up on these tools; that has not changed. This time I needed frame-accurate behavioral data from working sessions: the human motor cost of transport in the UI, and what fatigue looks like across participants. Annotation tools for this exist, but they are lab instruments from psychology and linguistics, built to code any behavior in any footage, and coding by hand would have taken longer than the decision could wait. I needed an instrument fitted to this product and these sessions, so I built one, slowly, in rationed sessions, and the findings it produced now shape my design decisions.
Recorded sessions, mapped onto annotated data: simple counts of clicks and presses, per participant, per minute. No models, no inferential statistics. Interactions per minute, plotted across the session, dropping steadily: as unarguable a picture of fatigue setting in as I have ever put in front of a team. Not because the analysis was clever, but because there was nothing in it to argue with. A count is a count. The goal was never a citable result but the journey to empathy with the labor of the user and the risks involved. The near-misses, recorded clear as day in the sessions, argue the point without any lobbying: we need to build features that prevent these mistakes from happening again. When I proposed the design solution, the team could see it was a defensible design decision, made on observed data instead of assumption.
Tools of One’s Own
The experience puts a specific pin on the UX lone wolf argument in my head. I’ve been slowly intercepting frontend work directly, because I knew enough frontend code to have an LLM fix it, slowly but surely raising the bar for the tangible artifact. But this tool experience surfaced a different problem: we are often under-tooled and asked to do the best with what we’ve got. Because we all have bills to pay, we do it. But if you are lucky enough to get some tokens allocated to you, I’d recommend tooling for your needs on the research side as well. Because once you’ve repaid the UX debt directly on the front end, the problems you can start to solve become truly strategic and value-add across the board.