# Web Interface Guidelines

> Use when building or reviewing a web UI and you need concrete interface-quality rules — interaction, state, accessibility, forms, feedback, motion, responsive layout, performance and copy. A practical checklist of web interface best practices to apply or audit against.

- Skill: `presidenteog/web-interface-guidelines` (Agent Skill)
- Install (CLI): `npx skillmds@latest add presidenteog/web-interface-guidelines`
- Raw SKILL.md: https://api.skillmd.com/api/skills/presidenteog/web-interface-guidelines/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: PresidenteOG (https://skillmd.com/u/presidenteog)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/presidenteog/web-interface-guidelines

---


# Web Interface Guidelines

## Overview
A concrete checklist for web UI quality — the details that separate a polished interface from a rough one. Use it while building (apply) or reviewing (audit). Complements `frontend-design` (creates distinctive UI) and `design-review` (visual QA pass); this is the rulebook both lean on.

## When to use
- Building a web component/page and want it to feel right.
- Reviewing a UI for quality/accessibility gaps.
- Standardizing interface conventions across a project.

## Checklist

**Interaction**
- Every interactive element has hover, focus, active and disabled states.
- Clickable things look clickable; hit targets ≥ 44px on touch.
- No action without feedback (loading, success, error). Optimistic UI where safe.
- Keyboard: everything reachable + operable; visible focus ring; logical tab order; `Esc` closes overlays.

**State coverage**
- Design loading, empty, error, success, partial and first-run states — not just the happy path.
- Empty states have a primary action + context, never a dead "No results".

**Forms**
- Labels always visible (not placeholder-only). Inline validation on blur, clear error text.
- Don't punish formatting (accept spaces in card/phone). Preserve input on error. Correct input types/`autocomplete`.

**Accessibility**
- Semantic HTML first; ARIA only to fill gaps. Alt text. Contrast ≥ 4.5:1 (text).
- Respect `prefers-reduced-motion`. Don't convey meaning by color alone.

**Feedback & motion**
- Motion clarifies (enter/exit, spatial continuity), ~150-300ms, eased. No motion for motion's sake.
- Toasts/inline messages for results; never leave the user guessing.

**Responsive & performance**
- Each breakpoint is intentional, not just "stacked on mobile".
- Avoid layout shift (reserve space for images/async). Lazy-load below the fold. Fast first interaction.

**Copy**
- Short, specific, action-oriented. Buttons say the action ("Save changes", not "Submit"). No happy-talk.

## How to use
- **Apply:** pick the sections relevant to what you're building; bake them in.
- **Audit:** go section by section, mark ✅ / ⚠️ / ❌ with the fix; prioritize accessibility + state coverage.

## Common mistakes
- Hover-only affordances (invisible on touch/keyboard).
- Placeholder-as-label; validation only on submit.
- Missing empty/error states; color-only signals; layout shift on load.

Related: `frontend-design` (build), `design-review` (visual QA), `webapp-testing` (a11y/visual tests).