Personal · Product Design · 2026
Designing an unbiased civic platform that makes local elections easier to understand
Aggregating fragmented public election data into one navigable experience so voters spend less time searching and more time understanding.
- Role
- Designer & Developer
- Timeline
- 2026
- Responsibilities
- 0 to 1 product, data pipeline
- Tools
- Next.js, Tailwind CSS, AI-assisted data pipeline
Overview
Every election season, campaign signs go up on every street corner: a big name, a slogan, and nothing else. Most voters can name the candidates running for governor or Senate. Far fewer know anything about the candidates on the rest of their ballot: city council, school board, judges, county offices, the races that shape daily life the most. I started Arizona Ballot Guide as a way to get more hands-on with Next.js and Tailwind, and working with Claude Code as a development partner, I took it from idea to a fully functional platform in under two weeks. It grew into something I think is genuinely useful: a tool where voters can search their ballot, browse candidates by office, city, county, or district, compare them side by side, watch past debates and read recaps, and trace every position back to its original public source.
Goals
- 1.Surface the down-ballot races: make city, county, school board, judicial, and other local offices as easy to research as governor or Senate.
- 2.Centralize fragmented public data: pull from sources like BallotReady, Arizona Clean Elections, the Secretary of State, county election offices, campaign finance databases, and local news into one place.
- 3.Make comparison effortless: let voters compare candidates side by side, watch past debates, and read debate recaps instead of researching each one in isolation.
- 4.Stay neutral and sourced: link every position and claim back to its original public source rather than editorializing.
The Problem
Signs tell you who to vote for. Just as often, the sign right next to it tells you who not to vote for, for the same race. Neither explains why, so what is a voter supposed to believe?
Local election research means jumping between disconnected sources: campaign websites, government databases, news coverage, and voter guides. The information exists, but it isn’t connected, and for the races that rarely make headlines, most voters have nothing to go on beyond a name on a sign.
What voters see
A name on a sign, with no easy way to know what that person actually stands for or how they have voted.
What voters need
One place to look up their ballot and understand who is actually running, especially in the down-ballot races that get the least attention.
Problem to solve
The information existed. It just wasn’t connected.
Strategy & Execution
My guiding principle was simple: help voters spend less time searching and more time understanding. I built the platform around five core functions:
- Finding a ballot by address
- Browsing candidates by office, city, county, or district
- Comparing candidates side by side
- Surfacing issue positions, voting records, endorsements, and sources
- Showing transparency about where information came from and when it was verified
Every design decision favored clarity and neutrality over persuasion.
Every Screen, Sketched First
Before writing any code, I wireframed the core screens: the homepage, candidate profiles, the full candidate list, race pages, and the sample ballot, each with notes on the reasoning behind it. A few of those early calls survived untouched into the final product.
The homepage has one job: get an address. Browsing without one stays visible, but secondary, for voters who would rather not enter their location. A status callout sits above everything else on a candidate profile: the freshest, most decision-relevant fact first. And the sample ballot carries a persistent banner so no voter mistakes a demo for their own real ballot.
Race-Level Context, Not Just Candidate Bios
Each race page adds context beyond individual profiles: a timeline of who has held the office and when, the full list of candidates running, and debates or candidate forums where available, so voters can hear directly from the people asking for their vote instead of reading a secondhand summary.
The Data Pipeline
Behind the interface, a semi-automated data pipeline pulls from BallotReady, Arizona Clean Elections, the Arizona Secretary of State, city and county election offices, campaign finance databases, candidate websites, voter guides, legislative records, and local news coverage, several of which actively resist automated access. AI-assisted workflows help process that volume, but every result goes through human review and source attribution before it’s published under a candidate’s name.
Every candidate profile is real, not a mockup, built to make research feel like browsing, not homework, and to hold up just as well on mobile as it does on desktop.
Every change the pipeline picks up, whether a new profile, an updated position, or a candidate dropping out of a race, gets logged in a Recently Updated feed, so it’s always clear what changed, when it happened, and where it came from.
Impact
These numbers reflect traffic since Arizona Ballot Guide went live in May 2026, including a single-day traffic spike on Election Day itself. The platform is still live today.
01
35,423
Voters reached
02
28,708
Peak day traffic
03
358
Candidates tracked
What I Learned From This Project
AI Changed What Solo Scope Looks Like
Integrating Claude Code into my workflow let me build and ship the entire platform, from data pipeline to UI, in under two weeks. The real shift was not speed for its own sake. It meant I could stay focused on product and data decisions instead of getting stuck on boilerplate.
Public Data Is Not Always Open Data
Many of the government sources this project depends on have no real API, and some actively resist automated access. I built a workaround that keeps a human in the loop rather than fully automating around it, regularly re-checking sources for changes like a candidate dropping out of a race.