The Last 10% of an Interface Is the Product.

There is a point in every project where the thing works. The flow completes, the data saves, the demo goes well. By most plans, that is ninety percent done.

What remains is a list nobody put on the roadmap: the empty state, the loading state, the error that only appears on a slow connection, the focus ring, the label that wraps badly in German, the button that looks disabled when it isn't.

People experience the gaps

Users rarely notice the main path, because the main path is what they expected. What they notice is the moment something unexpected happens and the product either handles it or doesn't.

An empty state that explains what will appear and how to get it there. An error that keeps what they typed. A form that still works with a keyboard. Each one is small, and together they are the difference between software people tolerate and software people trust.

Why it gets cut

This work is invisible in a demo and hard to estimate. It also arrives at the end, when the deadline is closest and everyone is tired of the project.

So it gets filed as polish. I think that framing is the mistake. Polish suggests decoration on top of something finished. These states are the product, in the conditions people actually use it.

A checklist I use

Before I call a screen done, I look at it:

• With no data, and with far too much
• On a slow connection, and with the request failing
• With a keyboard only
• With the text size turned up
• With motion turned off
• On the narrowest phone I can find

It takes about an hour per screen and it always finds something.

The compounding part

Teams that do this work consistently get faster at it, because the patterns become components and the components carry the care with them. Teams that skip it pay later in support tickets and in a general sense among users that the product is a bit flimsy.

That sense is hard to measure and very hard to reverse. Finishing properly is cheaper.