Designing screens a developer can actually build

The states are the design

A screen in a portfolio is the version where the data loaded, the user is logged in, the field is valid and the list has seven items. Real products spend most of their life somewhere else — loading, empty, error, too long, offline, mid-edit.

Empty states are the clearest tell. A list that shows nothing when it is empty makes a product feel broken on the first day a new customer uses it, which is the one day that matters most.

• Empty: what does this look like before any data exists, and what does it invite the user to do?
• Loading: is it a skeleton in the final layout, or a spinner that collapses the page when it resolves?
• Error: does the message say what happened, or does it say “something went wrong”?
• Long content: the longest plausible name, the largest number, the deepest nested row

A scale, not a set of numbers

If a design uses 14px here, 15px there and 17px somewhere else because each looked right in isolation, a developer has to guess which ones are intentional. The guess is where the finished product stops matching the design.

A named scale removes the guess. Four type steps, one spacing unit and its multiples, and every gap in the file is one of them. It is less expressive on any single screen and vastly more consistent across eighty.

Document the rules you would have to explain

Handoff is not a folder of exports at device resolution, although that helps. It is the set of decisions a developer will otherwise make without you: when a card becomes a list, what a disabled button does, how many characters a label truncates at.

Write those down once, next to the component they belong to. Every answer you leave implicit becomes a small divergence in the build, and they compound.