Empowered.Vote — researching and shipping voter tools end-to-end
Owning both sides of the loop for a civic-tech voter platform — running moderated usability studies and shipping the production TypeScript features those findings shaped.
Context
Empowered.Vote is a civic-tech project building tools that help voters understand candidates, ballot measures, and the actual mechanics of voting. I’ve been contributing as a volunteer, and on these features I owned both sides of the loop: the research that surfaced what users needed and where they got stuck, and the build that shipped the features and the fixes those findings pointed to.
That end-to-end ownership — from usability study to production TypeScript — is the closest thing on this site to how I actually work when I’m not handing research off to someone else to implement.
What I did
Over roughly three months I led four user-facing features into production and ran the research that shaped them:
- Compass: guided voter exploration
- Essentials: core voter information
- Treasury Tracker: campaign finance surfacing
- Read & Rank: ballot measure analysis and ranking
Research. When we introduced Compass (compass.empowered.vote), we knew we were asking users to interact with civic information in a new way. So I designed and conducted moderated usability sessions that combined task-based observation with generative interviews: participants thought aloud as they completed key tasks, and I then explored their expectations, points of confusion, and how they interpreted the language and interactions throughout the experience. I ran the same approach across Essentials and a round on Read & Rank, with the discovery questions aimed less at raw usability and more at the mental models users brought to each tool.
The Compass sessions were the clearest read. The biggest obstacles weren’t the underlying functionality but onboarding, terminology, and context — many users didn’t immediately understand what the tool was for, how it fit into the rest of the platform, or why they should use it.
Build. The stack is TypeScript front-to-back, with Supabase, Render, and GitHub as the surrounding infrastructure. My development workflow uses Claude Code as the primary partner: I do all the prompting, framing, and review; the AI handles most of the line-by-line code. Because I was also the one researching these features, a session finding could go straight into the codebase without a handoff in between. Bugs surface through iterative use rather than through extensive traditional testing — a deliberate tradeoff given the volunteer scope and the speed it lets us ship.
Outcome
The research closed the loop into shipped changes. On Compass, the findings led me to reprioritize the onboarding flow — adding coach marks (guided walkthrough notes), simplifying and clarifying the product language, and integrating Compass more tightly with our elected-officials views so its value was more immediately apparent. The result was a more intuitive experience and a clearer understanding of how Compass fit into the broader platform.
Across the effort: four user-facing features shipped in ~three months, used by real voters, with the research-to-build loop tight enough that a usability finding could become a deployed change quickly.
Reflection
Three honest notes.
On what the research changed. The biggest lesson from Compass was that adoption, in this instance, depended less on specific features and more on helping users build the right mental model — and that small changes to wording and context can dramatically change how people understand, and ultimately use, a product. It’s a finding I trusted precisely because I watched it happen in sessions and then shipped against it.
On wearing both hats. The most useful thing about owning research and build together was the short distance between them. Reading what the AI gets wrong fast enough to redirect it is the same instinct as recognizing when a research direction is sliding off the rails early — and doing both on one surface meant insights didn’t decay in a backlog before they got built. More broadly, building with AI rather than just reading about it is what most sharpened how I now argue about where it helps, where it adds friction, and where it’s misused. That’s the part I bring back into research conversations.
On the AI framing. I am not a traditional software engineer, and I don’t claim to be. What this work supports is a narrative about being a non-traditional builder who ships real software with AI; it doesn’t pass the bar for senior engineering roles on paper. I think that’s the right honest framing, and it’s also a framing I’d defend on the merits: working this way is genuinely different from either pure engineering or pure prompt-engineering, and it’s where a lot of UX-adjacent product work is heading.