Product Engineering

Forms are where product quality leaks

2 min read

Forms leak quality because the screenshot is only the first scene.

Once a real user arrives, the form has to survive pauses, mistakes, retries, keyboard navigation, stale drafts, and the awkward half-success where one field saved and another did not. That is the part that matters. The button and the layout can look perfect while the workflow underneath is brittle.

What usually decides whether the form feels good is timing. Early validation should catch obvious local problems. Server validation should own uniqueness, permission, and current-state checks. Pending state should tell the user the request is alive. Partial success should say what happened instead of collapsing everything into failure.

I care a lot about the shape of the error model. A user does not need “something went wrong.” They need the reason, the field or action it belongs to, and the next move. That is also where idempotency shows up. If the user retries because the page froze, the server should know whether it is seeing the same intent again.

Drafts and accessibility sit in the same pile. If the form can take long enough to hurt, it should keep work around. If the user cannot tell which field failed or reach it with a keyboard, the form is broken regardless of how tidy the mockup looked.

The boring states are not extras. They are the product.

Jeremy London

About Jeremy London

Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.