# Skill Modern UI Patterns > Use for professional SaaS UI implementation and refinement in React, TypeScript, Tailwind, dashboards, admin panels, tables, forms, settings, billing, onboarding, responsive layouts, component states, and design-system consistency. - Skill: `iapro-community/skill-modern-ui-patterns-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add iapro-community/skill-modern-ui-patterns-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/iapro-community/skill-modern-ui-patterns-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: IAPro-Community (https://skillmd.com/u/iapro-community) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/iapro-community/skill-modern-ui-patterns-2 --- # Skill Modern UI Patterns Use this skill when building or improving operational SaaS screens. Favor product clarity, compact density, accessibility, and maintainable components over decorative novelty. ## Impeccable Product Vocabulary Use [Impeccable](https://impeccable.style/) as a design-thinking layer, not as a replacement for the existing component system: - Start from product context: audience, task, product voice, and visual defaults to avoid. Reuse `PRODUCT.md` and `DESIGN.md` when present. - For new work, use `shape` (brief) -> `craft` (implementation) -> `critique` (design review) -> `polish` (final refinement). For existing work, begin with `critique` or a named pass such as `typeset`, `layout`, `colorize`, `quieter`, or `bolder`. - Separate product mode from brand mode: dashboards and admin screens need semantic states, repeatable components, and fluent density; landing pages can carry stronger type, imagery, and brand expression. - Prefer purposeful hierarchy and restraint over AI-default decoration. Avoid generic gradients, excessive roundness, glass cards, nested cards, oversized icon containers, repetitive section kickers, and a single undifferentiated font unless the design system has a reason for them. - Finish with `audit` and `harden` when the change affects production UI, then verify realistic content, responsive states, accessibility, and existing analytics. ## Symptom Routing - Generic or interchangeable -> `critique`, `distill`, then `bolder` or `shape`. - Busy or overdecorated -> `quieter`, `distill`, and remove redundant copy or containers. - Broken on small screens -> `adapt`, `layout`, and `harden` with long localized values. - Hard to scan -> `typeset`, `layout`, and strengthen primary-action hierarchy. ## Workflow 1. Reuse the app shell, component library, tokens, icons, form helpers, table patterns, and data-loading conventions already in the repository. 2. Identify the screen type: dashboard, list/table, detail page, form, settings, billing, onboarding, support/admin, or reporting. 3. Map the core workflow: scan, filter, compare, act, confirm, recover. Design the UI around that sequence. 4. Implement with stable structure: predictable grid tracks, constrained widths, consistent spacing, and responsive state transitions. 5. Add complete states for data and interaction: skeleton/loading, empty, no results, partial error, permission denied, saving, saved, validation error, and destructive confirmation. 6. Verify the result in mobile, tablet, and desktop viewports before claiming completion. ## Dashboard Patterns - Put the page title, freshness indicator, primary action, and key filters near the top. - Use metric cards only for decision-making numbers; include trend, period, source, or caveat when ambiguity would cause rework. - Prefer one strong chart or table cluster over many small decorative cards. - Keep chart legends, tooltips, and empty states readable at small widths. - Use clear units and formatting: currency, dates, rates, counts, percentages, latency, and quota. - Make drill-down paths obvious through row clicks, detail drawers, segmented controls, or tabs. ## Component Patterns - Use icon buttons for common compact tools: edit, delete, copy, refresh, export, filter, search, sort, expand, collapse, undo, redo, close. - Use text or icon-plus-text buttons for commands whose consequence must be explicit. - Keep cards shallow. Do not place page sections inside floating cards or nest cards inside cards. - Use drawers for contextual detail, modals for blocking decisions, popovers for lightweight controls, and pages for durable workflows. - Keep destructive actions confirmable and auditable. Show what will be affected. - Preserve existing analytics, URLs, form semantics, and keyboard behavior while refactoring UI. ## Forms And Tables - Put validation near the field, summarize submission failures, and preserve user input after errors. - Mark required fields using the project convention and provide examples for ambiguous values. - Keep table headers, row actions, sorting, filtering, pagination, and bulk selection consistent with existing screens. - Provide empty states with one clear next action when action is possible; otherwise explain the missing prerequisite briefly. - For wide tables, prioritize columns, provide column visibility or detail expansion when feasible, and avoid hiding primary identifiers. ## Professional Finish - Keep palettes balanced; avoid one-note purple/blue, beige, slate, or brown themes unless the product already uses them. - Use typography hierarchy appropriate to the surface. Do not use hero-scale text inside dashboards, cards, or sidebars. - Keep copy specific, spelled correctly, and free of mojibake. - Verify contrast, focus states, disabled states, truncation, wrapping, and icon alignment. - Do not add new UI dependencies unless they solve a concrete gap and match the existing stack. ## Done Criteria - The UI supports the main workflow without explanation text. - Layout remains stable with realistic data and long labels. - Loading, empty, error, and success states are implemented where relevant. - Responsive behavior is verified. - Lint, typecheck, build, or targeted tests run when available.