Icons

Icons should support comprehension, not replace it. This system treats icons as a secondary layer of meaning: useful for scanning, but never required to understand the UI.

Default icon style

This site uses a single icon set for consistency (Lucide-style icons).

Rules of thumb

• Use icons with consistent stroke weight
• Keep sizing predictable across the UI
• Align icons to text baselines when used inline
• Prefer icons that are widely recognized

Sizes

Use a small set of sizes across the system:

• 16px: dense UI (inputs, compact buttons)
• 18–20px: default UI (most buttons, nav items)
• 24px: feature moments (rare)

If you’re unsure, use 20px.

Where icons work well

Buttons

Icons work best when paired with text:

• Save + icon
• Download + icon
• Open in new tab + icon

When icons appear next to text, keep spacing consistent (for example, gap-2).

For icon-only buttons:

• always include an accessible name
• keep hit targets large enough for touch

Navigation

Icons can help scanning in sidebars or tool panels, but don’t rely on them as the only label.

Inputs and feedback

Icons work well for:

• success/error indicators
• loading spinners
• “clear input” affordances
• visibility toggles (password)

Accessibility

Icon-only controls

If a control has only an icon, it must include an accessible name:

• aria-label="..."

Decorative icons

If an icon is purely decorative, it should not be announced.

A simple rule: if removing the icon doesn’t change meaning, treat it as decorative.

Don’t rely on color alone

If an icon indicates status (success/error), reinforce it with text or additional UI, not just color.

Notes

Icons are easy to overuse.

If everything gets an icon, the interface becomes noisier and harder to scan. I use icons when they reduce reading effort, reinforce state, or make an action easier to spot.