# Frontend Design > Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics. - Skill: `waishnav/frontend-design-17` (Agent Skill) - Install (CLI): `npx skillmds@latest add waishnav/frontend-design-17` - Raw SKILL.md: https://api.skillmd.com/api/skills/waishnav/frontend-design-17/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: Waishnav (https://skillmd.com/u/waishnav) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/waishnav/frontend-design-17 --- Design for humans first. The output should feel product-designed, task-oriented, and specific to the interface's job. Avoid the default AI visual language even when it would be faster to generate. If the request is for a dashboard, admin, workspace, settings area, analytics page, or any internal tool, default to a disciplined product UI instead of a poster-like composition. ## Core Standard Build interfaces that feel normal in the best way: - clear hierarchy - predictable layout - calm color usage - readable data presentation - functional interactions - restrained visual treatment Think in the direction of mature product teams: precise, sober, and intentional. Do not make the UI perform "premium" with decoration. ## Phase 1: Classify The Surface Before writing code, decide which surface you are building: 1. Product UI 2. Landing page 3. Editorial / showcase surface 4. Dashboard Use the surface type to control layout and styling decisions. ### Product UI defaults Use these when the user asks for a dashboard or app-like interface: - Use a normal app shell. - Sidebar only when navigation depth truly needs it. - Sidebar width should usually stay in the `240px` to `260px` range. - Use solid backgrounds and simple separators. - Use a real toolbar/header, usually `48px` to `56px` tall. - Put the main work in the content area, not in decorative wrapper panels. - Use sections with `20px` to `30px` padding. - Prefer tables, lists, timelines, split panes, detail panels, and filters over decorative metric cards. ### Landing page defaults - A landing page may use a hero, but it still needs normal section structure afterwards. - Use recognizable section types: hero, proof, feature explanation, comparison, CTA. - Do not invent strange dashboard-like shells for a marketing page. - Do not fill the page with decorative copy blocks. ### Editorial / showcase defaults - You may push typography and composition further here. - Keep the interaction model obvious. - Even in expressive work, avoid AI-default gradients, pill overload, and generic SaaS dark mode. ## Phase 2: Information Architecture Before Styling Define the content hierarchy first: 1. What must be understood in five seconds? 2. What must be scanned quickly? 3. What requires detail on demand? 4. Which actions matter most? Then map those answers to a normal structure. ### Recommended dashboard structure Use this as the default mental model for data-heavy UI: - app shell - page header with title and primary actions - filter / scope controls if needed - summary row only if it earns its space - primary work surface: table, timeline, board, chart with labels, detail split, or queue - secondary context below or beside the main surface Do not start with a hero panel. Do not add a right rail unless it carries real workflow value. ## Phase 3: Uncodixify Rules If a choice feels like the easiest possible AI UI move, reject it and choose the cleaner option. ### Hard bans - no oversized border radii; most UI should stay within `8px` to `12px` - no pill-heavy buttons, tabs, filters, or badges - no floating glass shells - no frosted panels as the default visual language - no soft blue-purple gradients used as taste replacement - no generic dark SaaS composition - no dashboard hero sections unless there is a real product reason - no eyebrow labels above every section - no tiny uppercase tracked labels as a default hierarchy device - no decorative copy that explains how clean or focused the UI is - no fake charts - no donut charts unless the product specifically requires one - no metric-card grid as the first instinct - no dramatic shadows - no glowing borders - no transform-based hover choreography - no sidebar brand block with a decorative logo tile unless the product identity requires it - no nav badges, "live" pills, or ornamental counters unless they are functional - no right-side schedule rail added just to fill space - no repeated panel-on-panel-on-panel nesting ### Specific anti-patterns to avoid - big text on the left plus a floating card on the right as the default hero - three identical cards in a row with icon, heading, paragraph - four-item `2 x 2` card grids with identical internal structure - the same rounded rectangle repeated across sidebar, cards, buttons, and panels - muted gray-blue text that weakens contrast - premium dark mode that is really blue-black plus cyan - section notes, helper blurbs, and mini-manifestos scattered everywhere - trend text colored green/red without enough context - status badges on every table cell - quota and progress panels added without a real workflow reason ## Phase 4: Typography Typography should feel like a product decision, not a template. ### Font direction Avoid: - `Inter` - `Roboto` - `Arial` - `Segoe UI` - `Trebuchet MS` - generic safe default stacks as the main visual decision - serif-plus-sans pairings used only to fake premium taste Prefer clear sans families with some personality and strong data readability: - `IBM Plex Sans` - `Source Sans 3` - `Public Sans` - `Work Sans` - `Karla` - `Plus Jakarta Sans` For dense data or code-like accents, pair with: - `IBM Plex Mono` - `JetBrains Mono` - `Source Code Pro` ### Type rules - Use normal headers: `h1`, `h2`, `h3` - Avoid small uppercase labels above headings - Body text should usually sit around `14px` to `16px` - Keep line-height comfortable and contrast strong - Use weight and spacing to create hierarchy, not decorative labels - In product UI, one font family is usually enough ## Phase 5: Color Colors should stay calm and should not fight the content. ### Palette rules - Use a restrained token set with clear roles: background, surface, border, text, muted, accent, danger, success - Prefer charcoals, graphite, olive, rust, sand, oxblood, clay, smoke, or warm neutrals over blue-led palettes - If using dark mode, keep it muted and neutral rather than neon or glossy - Accent color should be scarce and meaningful - Favor strong text contrast over atmospheric haze ### Avoid - blue-purple gradients - cyan-on-navy startup palettes - decorative radial glows - five-accent-color palettes - accent colors spread across every component ## Phase 6: Component Standards Keep components straightforward and repeatable. ### Shell - sidebar: fixed width, solid fill, border-right, no floating shell - header: simple title, supporting actions, no decorative eyebrow - content width: normal container or full app canvas depending on product need ### Buttons - solid or bordered - radius `8px` to `10px` - no pill shapes - no gradient fills ### Cards and panels - use only when grouping helps comprehension - radius `8px` to `12px` - subtle border - minimal shadow, if any - do not wrap every section in a card ### Tabs - simple underline or border indicator - no pill tab bars - no sliding background animation ### Forms - label above input - simple borders - clear focus ring - no floating labels ### Tables and lists - left-aligned text - clear headers - simple row separators - subtle hover only - use badges sparingly - show state with text first, color second ### Icons - simple and consistent - `16px` to `20px` - no decorative icon chips unless needed for recognition ## Phase 7: Data Visualization And Human Readability When the UI contains data, optimize for understanding before style. ### Prefer these patterns - table plus filters - grouped list with totals - comparison rows - timelines - board columns when status flow matters - split view with list on one side and detail on the other - annotated charts with axes, labels, and real legends - stat plus sentence context, instead of stat alone ### Use visual emphasis intentionally - show one primary number only when it actually matters - use bars, sparklines, or heatmaps only when they clarify change or distribution - if a chart has no labels, it is probably decoration - if a panel can be replaced by a sentence and a number, do that ### Bans for data surfaces - no fake activity charts - no donut plus percentage pairings without decision value - no three-card KPI strip as the whole story - no decorative "team focus" or "recent activity" prose blocks - no dashboards that hide the main dataset below ornamental summary cards ## Phase 8: Layout Rhythm Normal UI does not mean flat or boring. Create structure through hierarchy and contrast, not gimmicks. ### Do - vary section density based on task importance - let one main surface dominate the page - use whitespace to separate jobs, not to look expensive - align content to a clear grid - keep spacing on a steady scale: `4 / 8 / 12 / 16 / 24 / 32` ### Do not - center random blocks while other content hugs the edge - alternate between unrelated alignment systems - use dead space as fake sophistication - overpad everything - collapse mobile layouts into one long undifferentiated stack ## Phase 9: Motion Motion should be quiet. - keep transitions around `100ms` to `200ms` - prefer color, border, background, and opacity changes - avoid hover transforms by default - avoid bouncy or theatrical motion - use animation only when it improves orientation or feedback ## Phase 10: Mobile Behavior Mobile should preserve the product structure, not merely stack desktop blocks. - reduce columns carefully - keep actions reachable - turn secondary controls into segmented rows, menus, or drawers when needed - protect tables from accidental overflow - preserve heading hierarchy and spacing density - avoid giant empty areas between sections ## Phase 11: Build Like A Designer Working From Real Components - Prefer interfaces that look like they could have been assembled from thoughtful Figma components. - Use familiar patterns and refine them instead of inventing novelty for its own sake. - Replicate the discipline of strong product design systems: consistent borders, sizing, spacing, and interaction states. - If a choice feels flashy but not useful, remove it. ## Phase 12: Final Review Before finishing, check: 1. Does this look like a real product UI instead of an AI-generated dashboard? 2. Is the main task visible immediately? 3. Are the most important data relationships easy to scan? 4. Did I avoid eyebrow labels, decorative copy, fake charts, and floating shells? 5. Are color, spacing, and radii restrained enough? 6. Would this still work if all decorative styling were reduced by half? If any answer is no, simplify and tighten the interface.