Design the empty, loading, and error states first

Why this rule exists

Designers love to draw the happy path, the screen full of perfect content, and forget that users spend a great deal of their time in the states nobody demos: the empty account on day one, the slow load on a poor connection, the error when something goes wrong. These states are not edge cases; they are the moments when the user most needs help, and leaving them as afterthoughts produces the blank screens, endless spinners, and cryptic failures that make products feel broken. A thoughtful empty state teaches a new user what to do; a good loading state reassures; a clear error explains what happened and offers a way forward. Designing these first, before the polished happy path, forces you to confront how the product behaves when reality is imperfect, which is most of the time. The quality of an interface is revealed not on its best day but on its worst, and those days deserve design, not neglect.