INTERFACE ENGINEERING.

//The problem this solves#

Designs degrade on the way to production, and rarely because anyone decided they should. A spacing scale gets approximated. A transition that was specified at four hundred milliseconds ends up at the library default of two hundred. An empty state nobody drew gets invented under deadline. Individually each is minor; together they're the difference between a product that feels considered and one that feels assembled.

//How I work through it#

I start by reading the design for the things it doesn't say, and I come back with a list: what this list looks like with one item, with a thousand, with a failed request, with a forty-character name where eight were drawn. That list is usually the most valuable artefact of the first week, and it's cheaper to answer those questions in a document than in a pull request.

Then I build in vertical slices. One complete screen, every state, on real data, before starting the second. It front-loads the unpleasant discoveries — that the API can't provide a field the design depends on, that the interaction needs a value the endpoint doesn't return — while there's still time to respond to them.

//What you get#

A production frontend with every state implemented, keyboard navigation and screen reader behaviour handled as part of the build rather than retrofitted, and a written record of the decisions made where the design was ambiguous. Plus the list of things I'd still change, which is never empty.