PRISM — Design Systems and Performance

Frontend work sits at the intersection of engineering and design, and fails in both directions simultaneously. Technically correct code can produce UI that users experience as sluggish, inaccessible, or visually incoherent. Visually impressive UI can hide under a bundle size that makes it unusable on mobile networks, or hide accessibility failures that exclude users who depend on assistive technology.

The PRISM skill addresses both failure modes with domain-specific patterns for design decisions, accessibility, Core Web Vitals, and bundle budgets.

The Work Type Assessment

The skill opens with a work type assessment that determines which sections are relevant:

A) Building new UI from scratch
B) Adding a feature to existing UI
C) Building a dashboard or data visualization
D) Building a landing page or marketing page
E) Optimizing for mobile
F) Performing an accessibility audit
G) Optimizing performance (LCP, INP, CLS)
H) Debugging a visual bug or regression

Type A loads UI style selection, typography, and the full design checklist. Type C loads chart type selection and data visualization patterns. Type F loads the complete accessibility checklist. Type G loads the Core Web Vitals targets and optimization techniques. Type H loads the visual debugging protocol.

Two questions follow: "Who are your users?" and "What is the primary metric you're optimizing for?" The answers shape every subsequent recommendation. A B2B analytics dashboard for data scientists has different design requirements than a consumer mobile app for first-time users.

UI Style Selection

The skill catalogs 67 UI styles organized by use case. Choosing the right style is not aesthetic preference — it is communication strategy. The style signals the product's personality, audience, and purpose before the user reads a single word.

A selection of key styles and their use cases:

Corporate Dark — dark backgrounds (#0A0A0B, #141415), accent colors electric blue or neon green. Use for: SaaS developer tools, monitoring dashboards, technical products. Conveys precision, seriousness, technical depth.

Glassmorphism — frosted glass with rgba backgrounds (0.1-0.2 opacity), backdrop-filter blur (10-20px), subtle white borders. Use for: fintech apps, iOS-native inspired web apps, premium consumer products. Conveys modernity and depth.

Minimal Swiss — strict grid, neutral colors, typography as design. Use for: portfolio sites, editorial platforms, high-end professional services. Conveys refinement and confidence.

Bento Grid — card-based, asymmetric layouts, varied card sizes conveying hierarchy. Use for: product marketing pages, feature showcases, dashboards. Conveys organization and modernity.

Neon Brutalism — bright neons (#FF2D78, #00FFD1) on black or white, thick borders, distorted elements. Use for: creative portfolios, gaming products, gen-z targeted consumer apps. Conveys energy and disruption.

When working in an existing codebase, identify the existing style before proposing changes. Adding glassmorphism components to a minimal Swiss product creates visual incoherence. The first action for type B work is documenting the existing style and following it.

Chart Type Selection

The most common data visualization error is using the wrong chart type for the data. Chart type is not aesthetic choice — it is determined by data structure and what comparison you are communicating.

| Data relationship | Chart type | |------------------|------------| | Change over time (continuous) | Line chart | | Change over time (discrete) | Bar chart | | Part-to-whole (few categories) | Pie/donut chart | | Part-to-whole (many categories) | Stacked bar chart | | Correlation between two variables | Scatter plot | | Distribution of a single variable | Histogram | | Comparison across categories | Grouped bar chart | | Geographic data | Map (choropleth or bubble) | | Network/hierarchy relationships | Node-link diagram or tree | | Flow/process | Sankey diagram | | Performance metrics over time | Sparkline + trend indicator | | Multi-dimensional comparison | Radar/spider chart |

Rules that prevent the most common mistakes:

Never use a 3D chart. 3D distorts the visual comparison between values. Depth perception is inconsistent across viewers. There is no case where a 3D chart communicates better than its 2D equivalent.

Never use a pie chart with more than 5 categories. Human perception cannot accurately compare angles beyond 5 slices. Use a sorted bar chart instead.

Always include a zero baseline on bar charts. A bar chart that starts at 95% to show the difference between 96% and 99% is a misleading chart. Start at 0.

Label data directly whenever possible. Legends require the reader to look away from the data to find the mapping. Direct labels keep the reader's eye on the data.

Typography by Domain

Font pairing is not decoration. The right font combination establishes authority, approachability, or energy before the user processes any content.

Tech and developer tools: Inter (body) + JetBrains Mono (code). Clean, technically precise, immediately legible at small sizes. This is what GitHub, Linear, and most modern SaaS products use.

Finance and professional services: IBM Plex Serif (headings) + IBM Plex Sans (body). The serif headings convey authority and trustworthiness. The sans-serif body maintains readability.

Healthcare and wellness: Source Serif 4 (headings) + Source Sans 3 (body). Legible, accessible, non-intimidating. Avoids the clinical coldness of pure sans-serif.

Creative and editorial: Playfair Display (headings) + Lato (body). High contrast, expressive headings with neutral body text.

Scale matters as much as font choice. Use a type scale: 12/14/16/18/20/24/30/36/48/60/72px. Do not set arbitrary sizes. Consistent scale creates visual rhythm.

Accessibility: WCAG 2.1 AA

Accessibility is not optional. It is a legal requirement in many jurisdictions and a quality signal that correlates with overall UI engineering quality. The patterns file contains the complete checklist. The non-negotiables:

Color contrast: Body text requires 4.5:1 contrast ratio against background. Large text (≥18px bold or ≥24px regular) requires 3:1. Use a contrast checker before finalizing any color combination. The most common failure: light gray text on white background.

Color not as sole information carrier: Never communicate state using only color. Red vs green for success/error is invisible to color-blind users (8% of men). Add icons, labels, or patterns as secondary signals.

Keyboard navigation: Every interactive element must be reachable and operable by keyboard alone. Tab order must be logical (matches visual reading order). Keyboard-trapped components (modals, menus) must have explicit escape paths.

Focus indicators: Do not suppress the browser's default focus ring with outline: none unless you replace it with a custom focus indicator. Many engineers suppress focus rings for aesthetic reasons without adding a replacement — this makes the interface unusable for keyboard users.

ARIA labels: All images with informational content need alt text. Icons that communicate meaning without text label need aria-label. Form inputs need associated <label> elements.

Semantic HTML: Use <button> for buttons, <nav> for navigation, <main> for main content, <header> and <footer> appropriately. Semantic elements provide screen readers with structural context that <div> cannot.

Heading hierarchy: <h1> → <h2> → <h3>. Never skip levels. One <h1> per page. Screen readers navigate by headings — a broken hierarchy makes documents inaccessible.

Touch targets: 44×44px minimum for any touchable element on mobile. The most common failure is close-together small buttons that are physically difficult to tap accurately.

Core Web Vitals: The Performance Contract

Google's Core Web Vitals are the measurable performance contract between your site and its users. Three metrics:

LCP (Largest Contentful Paint): How fast does the main content appear? Target: < 2.5 seconds. This is the hero image, headline, or primary content block. Optimization: <link rel="preload"> for LCP resources, serve images in WebP format, use CDN.

INP (Interaction to Next Paint): How responsive is the page to user input? Target: < 200ms. This measures the time from any user interaction to the next paint. Optimization: break long tasks into chunks with setTimeout, defer non-critical JavaScript, use CSS transitions instead of JavaScript animations.

CLS (Cumulative Layout Shift): Does content jump around as the page loads? Target: < 0.1. Caused by: images without explicit width/height, ads that inject into the layout, late-loading fonts. Fix by: always specify image dimensions, reserve space for dynamic content, use font-display: swap with explicit font metrics.

Measure with Chrome DevTools Lighthouse or PageSpeed Insights. Target all three in the "Good" range before shipping.

Bundle Budget

JavaScript bundle size directly determines time-to-interactive on mobile networks. Budget:

• Total JavaScript (initial load): < 300KB gzipped
• Critical CSS: < 14KB (fits in the first TCP packet)
• Individual route chunks: < 50KB gzipped

Enforcement:

// vite.config.ts or webpack.config.js
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'],
        ui: ['@radix-ui/react-dialog', '@radix-ui/react-select'],
      }
    }
  }
}

Analyze with npm run build -- --analyze (Vite) or webpack-bundle-analyzer. Common bundle killers: importing entire lodash instead of specific functions, importing all of date-fns instead of individual functions, icon libraries that import entire sets.

Critical pattern: Dynamic import for heavy components:

// ❌ Loads Monaco Editor in the initial bundle (+2MB)
import { Editor } from '@monaco-editor/react';

// ✅ Loads only when the component renders
const Editor = dynamic(() => import('@monaco-editor/react'), { ssr: false });

Monaco Editor, charting libraries, PDF viewers, and rich text editors almost always warrant dynamic import. They are large, and users only see them in specific flows.

The Anti-Pattern Database

Common frontend mistakes the skill flags immediately:

Visual anti-patterns:

• Text on busy photo background without overlay (readability failure)
• Too many competing accent colors (more than 2-3 in a component is chaos)
• Asymmetric padding that looks like a bug
• Mixing font styles without a clear hierarchy

Performance anti-patterns:

• useEffect that fetches data on every render (missing dependency array or wrong dependencies)
• Inline functions in render causing child re-renders on every parent update
• Large images without loading="lazy" below the fold
• CSS animations on layout-affecting properties (width, height, margin) instead of transform

Accessibility anti-patterns:

• onClick on a <div> instead of a <button> (loses keyboard and screen reader support)
• aria-hidden="true" on interactive content
• Form fields with only placeholder text as label (disappears on focus)

Key Takeaway

Frontend excellence has four measurable dimensions: visual coherence (correct style for audience and purpose, correct chart type for data, appropriate typography), accessibility (WCAG 2.1 AA compliance across contrast, keyboard, semantic HTML, ARIA), performance (LCP < 2.5s, INP < 200ms, CLS < 0.1), and bundle budget (< 300KB JS, dynamic import for heavy components). The work type assessment ensures you load only the patterns relevant to what you are building. All four dimensions have objective thresholds — this is engineering, not aesthetics.