Design polish & accessibility

Your app works; now it needs to look like it works — because users (and portfolio reviewers, and your future employer) judge trustworthiness by polish long before they test functionality. The good news: most 'designed by a professional' feel comes from four teachable moves, all of which your assistant executes well when named:

• Spacing is the secret. Cramped interfaces read as amateur; generous, consistent spacing reads as intentional. One pass per screen: consistent padding inside cards, consistent gaps between sections, whitespace around the primary action. Prompt pattern: 'audit this screen's spacing for consistency; use multiples of 4.'
• Hierarchy tells the eye where to go. Each screen has one most-important thing (inbox: the unread messages; thread: the reply box) — size, weight, and position should agree on what it is. The squint test: blur your eyes at the screen; whatever pops should be the thing that matters. If it's the filter tabs, fix the weights.
• Consistency is a design system in miniature: one primary-button style, one card style, one date format ('2h ago' everywhere or 'Jun 4' everywhere — never both), one border radius. Extract the repeated bits into components if drift crept in — Button, Card — so consistency becomes structural instead of remembered.
• Restraint over flourish: system fonts or one good font, 2-3 colors plus grays, no gradients-because-AI-suggested-them. Boring-and-clean outranks ambitious-and-uneven at every level of the craft, and doubly so at yours.

Accessibility: the basics are not optional extras

A meaningful slice of your users will navigate by keyboard, screen reader, or with low vision — and the floor-level work is genuinely cheap when done during polish (and genuinely miserable retrofitted): keyboard passage (tab through each screen: can you reach and trigger everything? is focus visible?), labels (every input labeled, every icon-button given an accessible name — the assistant adds these instantly when asked), contrast (your gray-on-white must pass a standard checker (WebAIM's contrast checker is the usual one); muted ≠ illegible), and honest HTML (buttons are <button>, links are links — screen readers navigate by structure, and generated code is mostly-good-but-worth-auditing here). Ask the assistant for 'an accessibility audit of this component against the basics: keyboard, labels, contrast, semantics' — then verify with your own tab key, because the tab key doesn't hallucinate.