The Problem
A growing SaaS company has 6 frontend developers building features independently. Every developer interprets the brand differently -- buttons come in 4 slightly different shades of blue, spacing varies between 12px and 16px depending on who built the page, and the settings panel uses a completely different card style than the dashboard. There are no documented color tokens, typography scales, or component specifications. The design team creates mockups in Figma, but developers eyeball the implementation, leading to a product that looks like 6 different apps stitched together. Onboarding a new developer means weeks of learning unwritten conventions by reading existing code. Every code review includes at least one comment about inconsistent spacing or wrong button styles.
The Solution
Use the brand-guidelines skill to define the foundational visual identity (colors, typography, spacing, voice), then use the ui-ux-pro-max skill to translate those guidelines into a complete component specification system with interaction patterns, accessibility requirements, and responsive behavior for every UI element in the product. Brand guidelines define how things look; the component specifications define how they behave.
Step-by-Step Walkthrough
1. Audit the current UI for inconsistencies
Catalog every visual inconsistency across the product to understand the scope of the problem and prioritize which components need standardization first. The audit creates a shared awareness that the problem is systemic, not just a few mismatched buttons.
Audit our SaaS dashboard for visual inconsistencies. Compare button styles, colors, border radii, and font sizes across the 8 main pages: dashboard, settings, billing, team management, API keys, analytics, notifications, and onboarding. Document every variation of primary buttons, secondary buttons, form inputs, cards, modals, and navigation elements. Create a spreadsheet showing which pages use which variants so we can see the full scope of inconsistency.
The audit typically reveals that inconsistencies cluster around components built by different developers at different times. This data helps prioritize: standardize the components that appear most frequently first.
2. Define brand guidelines and design tokens
Establish the foundational brand system: color palette, typography scale, spacing units, and visual principles that every component will inherit.
Create comprehensive brand guidelines for our product. Define a primary color palette (primary blue, success green, warning amber, error red, and 5 neutral grays) with specific hex values and WCAG AA contrast ratios against both white and dark backgrounds. Establish a type scale using Inter as the primary font: 6 heading sizes and 3 body sizes with specific line heights and letter spacing. Define an 8px spacing system with named tokens (xs through 3xl). Document our visual principles: clean over decorative, information-dense but not cluttered, consistent border-radius of 8px for containers and 6px for inputs.
3. Specify core UI components
Design the specification for every core component with exact dimensions, states, interaction behavior, and accessibility requirements. Each specification should be detailed enough that a developer can implement the component without asking a single follow-up question.
Create detailed UI/UX specifications for our core components based on the brand guidelines. For each component (button, input, select, checkbox, radio, toggle, card, modal, toast, tooltip, badge, avatar, table, pagination, tabs, breadcrumbs), specify: default dimensions and padding, all visual states (default, hover, active, focused, disabled, loading), keyboard interaction behavior, ARIA attributes and screen reader announcements, responsive behavior at mobile and tablet breakpoints, and dark mode color mappings. Start with buttons and inputs since they appear on every page.
4. Design complex component patterns
Specify higher-level patterns like forms, data tables, navigation, and empty states that combine multiple core components. These patterns are where most usability problems occur because they involve multiple components interacting together.
Design specifications for our complex UI patterns. The data table pattern: sortable columns with visual indicators, row selection with bulk actions toolbar, inline editing, pagination with page size selector, empty state, loading skeleton, and filter bar. The form pattern: field layout rules (when to stack versus inline), validation display timing (on blur versus on submit), error message positioning, required field indicators, and form section grouping with progressive disclosure. The navigation pattern: sidebar with collapsible sections, breadcrumb generation rules, mobile drawer behavior, and active state indication.
Each pattern specification includes an error state and an empty state. These are the states developers most often forget to implement, and they are the states users encounter during the most frustrating moments of their experience.
5. Create a component usage guide with do and do-not examples
Document how to use each component correctly with concrete examples of proper and improper usage to prevent future drift. The usage guide answers the "when" and "why" questions that the component specs do not cover.
Write a component usage guide for the development team. For buttons: when to use primary versus secondary versus ghost variants, maximum of one primary button per visible area, never use buttons for navigation (use links instead), and icon-only buttons must have aria-label. For modals: maximum content height with scroll behavior, always include a close mechanism (X button and Escape key), destructive actions require explicit confirmation with a typed confirmation input for irreversible operations. For toasts: auto-dismiss after 5 seconds for success, persistent until dismissed for errors, stack from bottom-right with 8px gap, maximum 3 visible simultaneously. Include visual do/don't comparison examples for each rule.
Real-World Example
The design lead and a senior frontend developer partnered on the design system over three weeks. The audit revealed 47 distinct component variations across the product -- 47 components that should have been 18. The four shades of blue turned out to be three developers using slightly different hex values from memory and one who had sampled the color from a compressed screenshot.
The brand guidelines locked down the color palette and spacing system as named tokens, immediately resolving the "which blue?" debates. The component specifications became the source of truth: when a developer needed to build a new settings page, they referenced the spec instead of copying styles from whatever page looked closest.
The first page rebuilt using the new system -- the team management page -- took 40% less development time because every component had exact specifications including states, keyboard behavior, and ARIA attributes. The design team stopped producing pixel-perfect mockups for standard pages and instead referenced components by name in their briefs: "use the standard data table with sortable columns and inline editing."
After 8 weeks, the entire product used the unified system, and the onboarding guide for new developers shrank from a scattered collection of Slack messages to a single design system document. The seventh developer hired after the system launched was productive on their first day because every visual question had a documented answer.