← ClaudeAtlas

designing-an-interfacelisted

Design a screen someone can read at a glance and act on without being taught — hierarchy, density, the states you forgot, and copy that says something. Use before building any screen, panel, sheet or empty state, and when a screen "works" but feels wrong.
mirzaaghazadeh/StandBye · ★ 6 · Web & Frontend · score 75
Install: claude install-skill mirzaaghazadeh/StandBye
# Designing an interface Most bad screens are not ugly. They are unreadable: everything the same weight, nothing answering the question the person actually arrived with. Start from that question. ## Before you draw anything Say in one sentence what the person is here to find out or do. "What is my team working on?" "Why did last night cost that much?" If you cannot say it, the screen has no shape yet and any layout will do — which is why it will be bad. Then find the one thing on the screen that answers it. That is the only element allowed to be loud. Everything else supports it or gets out of the way. ## Hierarchy is contrast, not size Three levels is usually enough: the answer, its supporting detail, and the chrome around them. Separate them with weight and colour before reaching for size — a 13px semibold label against 12px muted text reads better than 18px against 14px, and stays calm. - One accent colour, used for the action you want taken and nothing else. An accent on everything is an accent on nothing. - Colour is never the only signal. A red dot and a green dot are the same dot to a colourblind reader: pair it with a word or a shape. - Numbers people compare belong in a monospaced or tabular font, right-aligned, same precision. `$0.03` under `$12.40` reads as a column; `$0.0300` and `$12.4` read as noise. ## Density Desktop users are not on a phone. Tight rows, real information, no card with four words in it. But density is not clutter: group related t