The UI Design Checklist - 80 Points for Pixel-Perfect Screens
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
Built for practical use
Typography QA
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
Spacing checks
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
State validation
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
Accessibility coverage
A UI review checklist for typography, color systems, spacing, consistency, responsiveness, states, accessibility, and handoff readiness.
How to Use This Checklist
This checklist is used during design reviews before designs are handed off to development. It catches common UI issues that waste development time during implementation.
Scoring: For each point, mark Pass / Partial / Fail. Fix all Fails before handoff.
Use for:
- Design QA before developer handoff
- Self-review by designers
- Peer design reviews
- Onboarding new designers (consistency guide)
Scoring
Calculate your score:
- Pass = 1 point, Partial = 0.5 points, Fail = 0 points
- Maximum: 80 points
Interpret:
- 70-80: Excellent UI — ready for dev
- 55-69: Good — specific fixes needed
- 40-54: Below standard — significant polish required
- Below 40: Not ready for handoff — back to design
Action: All Fails must be fixed before developer handoff. Partials should be reviewed and improved.
Review The UI
Score each UI checkpoint and capture the fixes that should roll into design QA.
CATEGORY 1: TYPOGRAPHY (10 Points)
1. Typography scale is consistent and defined.
The design uses a defined type scale (typically 6-8 sizes: 12, 14, 16, 18, 20, 24, 32, 48px) and doesn't introduce one-off font sizes. Inconsistent sizing creates visual chaos.
2. Body text is 16px minimum on desktop.
Smaller body text is hard to read for users with lower visual acuity. 14px is acceptable only for secondary text, captions, or data-dense interfaces.
3. Line height is appropriate for font size.
Body text uses 1.5-1.6x line height (e.g., 24px line height for 16px font). Headings use tighter line height (1.2-1.3x). Line height below 1.4 for body text reduces readability.
4. Line length (measure) is optimal.
Text paragraphs are 45-75 characters per line for readability. Longer lines (90+ characters) cause reading fatigue. Shorter lines (under 30 characters) create awkward word spacing.
5. Font hierarchy is clear.
H1 > H2 > H3 > body text. Each level is visually distinct in size and/or weight. Heading levels don't skip (no H1 → H3).
6. Font weights are used purposefully.
Regular (400) for body. Medium (500) or Semibold (600) for emphasis. Bold (700) for headlines. Avoid using all caps or italic for emphasis in long text (reduces readability).
7. Letter spacing is appropriate.
Tighter tracking for display headings (can go below default). Default tracking for body text. Slight positive tracking for all-caps text.
8. Web fonts are optimized.
Limited to 2-3 font families total. Font files are WOFF2 format. Only necessary weights/styles are loaded. font-display: swap is used to prevent layout shift.
9. System fonts as fallbacks are specified.
Font stacks include system fallbacks (e.g., `font-family: "Inter", -apple-system, BlinkMacSystemFont, sans-serif`) so text renders before web fonts load.
10. Text respects user preferences.
Text can be resized to 200% without breaking layouts (WCAG 1.4.4). Users who set larger font sizes in their browser see proportional scaling.
CATEGORY 2: COLOR (8 Points)
11. Color palette is defined and systematized.
Colors are organized as design tokens (primary, secondary, accent, semantic, neutrals) — not random hex codes. Typically: 2-3 primary colors, 4-5 semantic colors (success, warning, error, info), 8-10 neutral shades.
12. Color contrast meets WCAG AA standards.
Text-to-background contrast is at least 4.5:1 for normal text (<18px) and 3:1 for large text (18px+ or 14px+ bold). UI components have 3:1 contrast against adjacent colors.
13. Color is not the sole indicator of meaning.
If red = "error" and green = "success," there's also a text label, icon, or pattern. Color-blind users (8% of males) shouldn't be excluded.
14. Brand color is used consistently.
Primary brand color appears in predictable places: primary CTAs, active states, links, key emphasis. Overuse dilutes its impact.
15. Semantic colors are used correctly.
Red = error/destructive. Green = success. Yellow = warning. Blue = informational. Deviations from these conventions confuse users.
16. Dark mode is considered (if applicable).
If supporting dark mode, all colors have appropriate dark variants. Not just inverted — dark mode has unique considerations (elevation through surfaces, not shadows).
17. Color palette supports the entire UI hierarchy.
Enough neutrals for backgrounds, surfaces, borders, and text. Enough accent variants for hover, active, disabled states.
18. Gradients and color effects are used sparingly.
If used, gradients should be subtle and purposeful (not random decoration). Avoid rainbow gradients or overly saturated effects.
CATEGORY 3: SPACING & LAYOUT (10 Points)
19. Spacing follows a consistent scale.
Uses a spacing scale (typically: 4, 8, 12, 16, 24, 32, 48, 64, 96px) — not arbitrary values. The 8-point grid is the industry standard.
20. Grid system is defined and respected.
Page layout uses a clear grid (typically 12 columns on desktop, 4-6 on tablet, 4 on mobile). Elements align to grid lines.
21. White space is used intentionally.
Adequate breathing room between sections (40-80px on desktop), between groups (24-32px), and between elements (8-16px). Cramped layouts feel chaotic; overspaced layouts feel disconnected.
22. Margins and padding are consistent.
Similar components have similar spacing. A card with 24px internal padding on one page shouldn't have 16px padding on another page.
23. Responsive breakpoints are defined.
Standard breakpoints: mobile (320-767px), tablet (768-1023px), desktop (1024px+). Layout adapts at each breakpoint, not just scales.
24. Content has maximum width constraints.
Body content doesn't stretch full-width on large screens. Readable text width is typically 600-800px.
25. Alignment is consistent.
Related elements align to the same edge. Mixed left/center/right alignment within a section looks unprofessional.
26. Vertical rhythm is maintained.
Vertical spacing between elements follows a consistent pattern. Line heights, heading spacing, and paragraph spacing create visual rhythm.
27. Group related elements visually.
Gestalt proximity principle: related items are close together, unrelated items have more space between them.
28. Safe areas are respected.
On mobile, content doesn't overlap with notches, system UI, or bottom home indicators. Minimum edge padding: 16px on mobile, 24px on tablet, 32px on desktop.
CATEGORY 4: COMPONENT CONSISTENCY (12 Points)
29. Buttons are visually consistent across the product.
Primary, secondary, tertiary, destructive, ghost variants are defined and used consistently. Same primary button appears identical everywhere.
30. Button sizing is standardized.
Typical sizes: small (32px height), medium (40px), large (48px). Minimum tap target on mobile: 44×44px (per WCAG AAA 2.5.5).
31. Button labels are action-oriented.
Use verbs: "Create Report," "Save Changes," "Delete Account" — not "OK" or "Submit." Labels describe the outcome.
32. Input fields are visually consistent.
All text inputs, dropdowns, date pickers, and textareas share the same base styling (border, padding, height, corner radius).
33. Form field states are designed.
Default, hover, focus, filled, disabled, error states are all designed and used consistently.
34. Icons are from a consistent set.
Don't mix icon styles (outlined vs. filled, different stroke weights, different sizes). Use one icon library (e.g., Heroicons, Phosphor, Lucide, Remix).
35. Icon sizes are standardized.
Typical sizes: 16px (small), 20px (medium), 24px (large). Icons align to baseline or center of adjacent text.
36. Cards and containers have consistent styling.
Corner radius, shadow, border, and padding are consistent across similar card types.
37. Modals follow consistent patterns.
Size (small, medium, large, full-screen), close behavior (X, Escape, click outside), focus trap, scroll behavior, and action button placement are consistent.
38. Notification/toast patterns are defined.
Success, error, warning, info variants are designed. Position (top-right, bottom-center), timing (auto-dismiss duration), and stacking behavior are consistent.
39. Navigation components are consistent.
Primary nav, secondary nav, tabs, breadcrumbs, and pagination follow defined patterns. Same visual treatment every time.
40. Tables and data displays share consistent styling.
Table borders, header styling, row spacing, hover states, and alignment are consistent.
CATEGORY 5: INTERACTIVE STATES (10 Points)
41. Default state is clean and clear.
Elements look right out of the box without needing hover or interaction to understand them.
42. Hover state is designed.
On desktop, interactive elements change visually on hover (color shift, elevation, underline). Communicates "this is clickable."
43. Focus state is visible.
Keyboard focus is indicated with a clear outline or ring (WCAG 2.4.7). Don't rely on default browser focus; design a custom one that matches the brand.
44. Active/pressed state is designed.
Visual feedback during click/tap (color change, slight scale, etc.) communicates the interaction was registered.
45. Disabled state is clearly distinguishable.
Disabled elements have reduced opacity (typically 40-60%), different color, or different styling. It's visually obvious they can't be interacted with.
46. Loading state is designed.
Buttons and components show loading indicators (spinner, skeleton, progress) during async operations. Users should never wonder if their action registered.
47. Error state is designed.
Form fields with errors show red border, error icon, and error message. Error state is accessible (announced to screen readers via aria-describedby).
48. Empty state is designed.
When a list, table, or section has no content, an empty state illustration + explanation + CTA is shown.
49. Success/confirmation state is designed.
After successful actions (save, submit, delete), clear visual feedback is provided: toast notification, success message, checkmark animation.
50. Selected state is clear (for selectable items).
When a user selects an item from a list, their selection is visually distinct (background color, border, checkmark).
CATEGORY 6: RESPONSIVE DESIGN (8 Points)
51. Layout adapts at each breakpoint.
Desktop, tablet, and mobile layouts are genuinely different — not just "shrunk desktop."
52. Text resizes appropriately.
Headings scale down on smaller screens. Body text usually stays the same size (16px on mobile is still readable).
53. Touch targets are at least 44×44px on mobile.
Buttons, links, form controls, and interactive elements meet WCAG AAA 2.5.5 guidelines on mobile.
54. Images are responsive.
Images use max-width: 100% and appropriate aspect ratios. Use srcset for different resolutions (retina, standard).
55. Tables adapt to mobile.
Large tables either scroll horizontally (with fixed first column) or transform into card layouts on mobile.
56. Navigation transforms on mobile.
Horizontal nav becomes hamburger menu, bottom tabs, or drawer pattern. Users can access all navigation with one hand.
57. Modals work on mobile.
On mobile, modals are full-screen or near-full-screen — not tiny centered boxes. Close button is thumb-accessible.
58. Forms are mobile-optimized.
Input types trigger correct keyboards (type="email", type="tel", type="number"). Autofill works. Labels are above fields, not beside.
CATEGORY 7: ACCESSIBILITY (12 Points)
59. Color contrast passes WCAG AA.
Test with WebAIM Contrast Checker, Figma Stark plugin, or Chrome DevTools.
60. Interactive elements are keyboard-accessible.
All buttons, links, forms, modals, dropdowns can be operated with keyboard alone.
61. Focus indicators are visible.
Custom focus rings are designed (don't rely on browser defaults) with adequate contrast.
62. Focus order is logical.
Pressing Tab moves focus through elements in visual order. No unexpected jumps or trapped focus.
63. Alt text is defined for images.
Every meaningful image has descriptive alt text. Decorative images have empty alt="".
64. Icons have accessible labels.
Icon-only buttons have aria-label or visually hidden text describing their function.
65. Form fields have labels.
Every input has a visible label (not just placeholder text). Labels use <label> with htmlFor or aria-label.
66. Error messages are associated with fields.
Error messages use aria-describedby or aria-errormessage to link to their input.
67. Headings follow logical hierarchy.
One H1 per page. Headings don't skip levels. Screen reader users navigate by headings.
68. Link text is descriptive.
"View pricing" not "click here." Link text makes sense out of context.
69. Motion respects user preferences.
Animations and transitions respect prefers-reduced-motion. Users who set this preference in their OS don't see distracting motion.
70. ARIA is used correctly (when needed).
Custom components (tabs, accordions, dropdowns) use appropriate ARIA roles and states. But don't add ARIA where semantic HTML suffices.
CATEGORY 8: DEV-READINESS (10 Points)
71. Design system components are used.
All buttons, inputs, cards, etc. use the design system's component library. No one-off custom components that should have been part of the system.
72. Design tokens are referenced, not hardcoded.
Colors, spacing, typography reference tokens ("--color-primary-500") not raw values ("#3B82F6"). This enables theming and consistency.
73. All states are designed (not just defaults).
Default, hover, focus, active, disabled, loading, error, empty, success states are all designed before handoff.
74. All breakpoints are designed.
Desktop, tablet, and mobile versions are all designed — not just desktop with a note saying "make it responsive."
75. Interactions are specified.
Animations, transitions, state changes are documented (duration, easing, trigger conditions).
76. Edge cases are considered.
Long text, many items, zero items, slow network, offline — these scenarios are designed, not ignored.
77. Assets are exported and organized.
Icons, images, and illustrations are exported in appropriate formats (SVG for icons, WebP/JPG/PNG for images) and organized in a shared location.
78. Annotations are clear for developers.
Spacing, colors, behaviors, and interactions are clearly annotated in Figma or linked documentation.
79. Component variants are explicitly documented.
Button variants, card variants, etc. are all shown with clear labels (primary, secondary, etc.).
80. Developer handoff is structured.
Design file is organized with clear frames, consistent naming, and Figma inspect mode enabled. Specs are accessible without designer hand-holding.
Sources and References
- Material Design, Google (guidelines for typography, spacing, color)
- Apple Human Interface Guidelines
- Fluent Design System, Microsoft
- WCAG 2.1 Success Criteria, W3C
- Inclusive Components by Heydon Pickering
- Design Systems Handbook by Marco Suarez, Jina Anne, Katie Sylor-Miller
Created by Desisle — SaaS UI/UX Design Agency desisle.com | hello@desisle.com Free to use and share with attribution.
Keep Building With These Next
Design System Starter Kit - Token Architecture + Component Foundation
A starter Figma system with token architecture, core components, naming conventions, and auto-layout structure so teams can build on a real foundation instead of a loose UI kit.
Open System Starter KitSaaS Color System Generator - Build an Accessible Palette in Minutes
A tool concept that takes one primary brand color and expands it into a SaaS-ready, WCAG-aware system including semantic colors and export options.
Open Color System GeneratorThe SaaS UX Audit Checklist - 100 Points to Check Today
The same 100-point UX audit checklist our team uses when reviewing SaaS products across onboarding, navigation, dashboards, forms, accessibility, mobile responsiveness, and performance.
Open UX Audit ChecklistNeed This Applied to Your Product? We'll Turn It Into Execution.
These resource pages are meant to be used hands-on. If you want the audit, plan, or framework translated into live product work, we can do that with your team.