The states nobody draws

A design file shows a screen on its best day: the data has arrived, the list has seven tidy rows, the name fits on one line. The product spends most of its life somewhere else.

Count them first

Before I estimate a build I list the states for every screen: loading, empty, partly loaded, failed, offline, and too much. A simple list view has six. A form has more.

Budget for them

My rule of thumb is that the drawn state is a third of the work. If the plan only has time for the picture, the other two thirds will be decided by whoever is in the file at five o’clock on a Friday.

Design them in code

These states are easier to design where they happen. I throttle the network, empty the database, and look at what the screen does. Then I fix what I see.