From UX review to merged PR

When I first started poking around our codebase, an engineer went to set me up properly and then paused. "We probably didn't set up commit signing for you," he said, "because you were just prototyping and wouldn't be making PRs."

Funny how things progress.

I'm a designer. I'm not quietly retraining as an engineer, and this isn't a story about a designer who learned to code. It's a smaller, more useful story than that: how a UX improvement I'd normally hand off went from a comment in a review thread to merged code in production, in one loop, without leaving the problem behind me.

Where it started

It started, as these things do, with someone noticing something.

A teammate was reviewing Cornell Notes in production and flagged the placeholder text. It passed at 4.50:1, the lowest possible AA contrast pass. Audit-wise it cleared the bar, but visually impaired learners would benefit from more contrast. They were right. 4.50:1 is technically a pass and practically a shrug. It clears the bar by a hundredth of a point.

Normally this is where a designer's involvement thins out. You'd agree it's worth fixing, write it up, and watch it settle into a backlog to be picked up whenever there's room. The gap is real, the fix is tiny, and it competes forever with bigger things.

The small conversation that changed the loop

This time the whole thing happened in the same conversation. Someone asked what I thought. An engineer confirmed there was already a stronger placeholder colour in the theme. I said we could try it, and asked if they were happy for me to do a Claude-assisted PR. The answer was basically: go on then, it should be as easy as a PR gets.

Fifteen minutes later I linked the pull request. The fix already existed in our design tokens. It just needed someone to reach for it. This time that someone was me.

The loop

Looking back, the same four steps kept repeating, so I'll name them.

Review

Spot the gap in the real product, and turn it into a UX enhancement ticket. One improvement, one ticket. I used Claude to help me write the ticket up cleanly, so the intent was unambiguous before any code moved.

Prioritise

This was one of several tweaks I had lined up. I took the contrast fix first on purpose: small enough to walk end to end once, real enough to matter. If you're going to learn a new loop, learn it on something low-stakes and genuinely worth doing.

Build with Claude

From the same ticket, I worked through the code change with Claude. There's a neat symmetry here that I keep thinking about: the tool that helped me frame the problem also helped me solve it. It didn't do it for me. It gave me a clear path from "this is the UX problem" to "this is the diff that fixes it."

Ship

I'd bundled two changes at first, then broke them apart. One change per PR. The contrast fix went in first, and a Study Notes layout tweak branched off it and stacked cleanly behind. Small, focused, in a clear sequence, each easy to review and easy to revert.

Then CI passed, the PR merged, the branch deleted itself, and the ticket was done.

Fast, but not cowboy

The part I want to be honest about: an engineer reviewed every diff before it merged. That's not a caveat I'm embarrassed by. It's the point. The speed didn't come from skipping the safety net. It came from removing the distance between spotting a UX problem and proposing the fix. The review, the standards, the CI, and the human who knows the system better than I do were all still there.

So I'm not shipping features. I'm carrying small, well-understood UX fixes the last mile, on rails that engineering built, with AI collapsing the busywork in between.

Why it matters

For years the honest limit of a designer's influence was the handoff. You could specify the contrast, the spacing, the state, and then you waited. Sometimes the shipped thing drifted from the intent. Sometimes the smallest fixes never made the cut because they were never worth a sprint.

This changes the economics of small. Accessibility papercuts, a token used instead of a hardcoded grey, a placeholder that clears contrast comfortably instead of barely. The stuff that's too minor to fight for but genuinely better for the people using the product. Those can now go from spotted to shipped in an afternoon, by the person who cared about them in the first place.

A teammate spotted a gap. It reached merged code as a series of small, clear steps. A few visually impaired students will read those notes a little more easily, and none of them will ever know why. That's the job.

Funny how things progress.

A note on the writing: I used AI to help turn my talk and working notes into a clearer written post. The work, the decisions, and the PRs are my own, reviewed as ever by people who know the codebase better than I do.