Applying Design Principles to Web Design: A Systematic Review Process

The review workflow has five phases. Completing all five takes 20-30 minutes per page and catches 90%+ of principle violations before designer review.

Phase 1: 5-Second Test (1 minute)

• Load the page
• Look at it for 5 seconds
• Look away and answer: 'What is this page for?' and 'What can I do here?'
• If you cannot answer: hierarchy fails — the page purpose is not clear

Phase 2: Squint Test (2 minutes)

• Squint eyes until page is blurry
• What elements are dominant? (these are the most visually heavy)
• Should those elements be dominant? (are they the most important?)
• If wrong elements dominate: contrast fails — fix size, weight, or color of wrong elements

Phase 3: CRAP Checklist (10 minutes)

For each principle:

Contrast:

• [ ] Text meets WCAG AA contrast (4.5:1 body, 3:1 large text)
• [ ] Primary actions are clearly more prominent than secondary
• [ ] Headings are noticeably larger/heavier than body text
• [ ] Active states clearly different from inactive states

Repetition:

• [ ] Colors come from the design token system (no one-off hexes)
• [ ] Border radius is consistent for same element type
• [ ] Spacing values are from the 4px scale
• [ ] All interactive states use the same transition properties

Alignment:

• [ ] Text is left-aligned (except short headings)
• [ ] Elements in columns share the same left edge
• [ ] Icons and text baselines align in horizontal groups
• [ ] Grid columns are consistent across sections

Proximity:

• [ ] Labels are closer to their inputs than to other labels
• [ ] Related content is grouped tightly; unrelated content is far apart
• [ ] Borders and dividers are used only when proximity cannot communicate separation

Phase 4: Gestalt and Psychology (10 minutes)

• Proximity: do visual groups match logical groups?
• Similarity: do same-function elements look identical?
• Continuity: are sequential elements connected visually?
• Figure-ground: do overlaid elements (modals, dropdowns) clearly sit above background?
• Cognitive load: is the primary action obvious? (Hick's Law)
• Target size: are all touch targets ≥ 44px? (Fitts's Law)

Phase 5: Responsive and Accessibility (5 minutes)

• Test at 375px, 768px, 1440px
• Tab through all interactive elements (focus rings visible?)
• Check one color contrast value (DevTools Computed → color swatch)

Each principle violation has a characteristic 'feel' and a specific fix. This reference connects symptoms to fixes.

Violation 1: 'Everything feels equal, no clear focal point'

Principle: Contrast, Visual Hierarchy

Diagnosis: Primary and secondary elements have similar visual weight

Fix:

1/* Increase contrast between primary and secondary */
2/* Make primary: larger, heavier, higher contrast color */
3.primary-heading { font-size: 2.25rem; font-weight: 700; color: #111827; }
4/* Make secondary: smaller, lighter, muted color */
5.secondary-text { font-size: 0.875rem; font-weight: 400; color: #6b7280; }

Violation 2: 'Each section looks like a different product'

Principle: Repetition, Unity

Diagnosis: Colors, fonts, or spacing are inconsistent between sections

Fix:

1/* Ensure all sections use the same token set */
2.section-1 { background: var(--color-bg-page); }
3.section-2 { background: var(--color-bg-surface); }  /* same tokens */
4.section-3 { background: var(--color-bg-page); }
5/* Never: hardcoded different colors in each section */

Violation 3: 'I cannot tell which label goes with which input'

Principle: Proximity

Diagnosis: Equal spacing between labels and inputs as between form groups

Fix:

1.form-group { display: flex; flex-direction: column; gap: var(--space-1); }  /* 4px label-input */
2.form { display: flex; flex-direction: column; gap: var(--space-6); }       /* 24px group-group */

Violation 4: 'Something looks slightly off but I cannot pin it down'

Principle: Alignment

Diagnosis: Elements have slightly different left edges or vertical positions

Fix:

1/* Check all elements have consistent horizontal positions */
2/* Use the same container padding for all sections */
3.section { padding-inline: var(--space-6); }  /* all sections: same horizontal padding */
4/* Use grid columns, not manual left positions */
5.content { display: grid; grid-template-columns: repeat(3, 1fr); gap: var(--space-6); }

Violation 5: 'The interactive elements don't respond consistently'

Principle: Repetition, Interaction Unity

Diagnosis: Different transition speeds or hover behaviors on different elements

Fix:

1/* Define ONE transition and use it everywhere */
2:root { --transition: 150ms cubic-bezier(0, 0, 0.2, 1); }
3.btn { transition: background-color var(--transition); }
4.card { transition: box-shadow var(--transition); }
5.link { transition: color var(--transition); }
6/* Same speed = same 'feel' = consistent product */

Violation 6: 'The modal feels flat, not separate from the page'

Principle: Figure-Ground

Diagnosis: Modal lacks elevation cues (shadow, backdrop)

Fix:

1.modal-backdrop { background-color: rgb(0 0 0 / 0.5); }  /* ground: dimmed */
2.modal-panel {
3  box-shadow: 0 20px 60px rgb(0 0 0 / 0.2);  /* figure: elevated */
4  background-color: white;  /* pure white vs dimmed background = contrast */
5}

Color and typography reviews have specific technical tests that go beyond the subjective 'does it look good?' question.

Color review process:

11. Open DevTools on any text element
22. Click the color swatch in Computed panel
33. Read the contrast ratio
44. Compare to requirements:
5   - Normal text (< 18px regular): minimum 4.5:1
6   - Large text (≥ 18px or ≥ 14px bold): minimum 3:1
7   - UI components (buttons, inputs): minimum 3:1
85. Check the most critical elements:
9   - Body text on page background
10   - Light gray secondary text on white (common failure)
11   - White text on action-colored buttons
12   - Placeholder text on inputs
13   - Disabled element text

Common contrast failures:

1/* FAIL #1: Light gray text on white — very common */
2.meta { color: #9ca3af; }  /* 2.85:1 — fails AA */
3/* FIX: Darker muted gray */
4.meta { color: #6b7280; }  /* 4.48:1 — passes AA */
5
6/* FAIL #2: Blue on light blue — badge */
7.badge { background: #eff6ff; color: #60a5fa; }  /* 2.67:1 */
8/* FIX: Darker blue */
9.badge { background: #eff6ff; color: #1d4ed8; }  /* 7.0:1 — passes AAA */
10
11/* FAIL #3: Green text on white — success messages */
12.success-msg { color: #22c55e; }  /* 1.9:1 — fails badly */
13/* FIX: Much darker green */
14.success-msg { color: #15803d; }  /* 5.0:1 — passes AA */

Typography review process:

11. Check font loading (Network tab): is the web font actually downloading?
22. Check line height (Computed panel): is it unitless? Is it 1.5-1.6 for body?
33. Check font weight (Computed panel): is it a number (400, 600) not 'bold'?
44. Check font size (Computed panel): is it in rem? 1rem = 16px?
55. Check heading sizes: are adjacent heading levels at least 25% different?
66. Check line length: is body text content max-width limited to ~65ch?
77. Check letter spacing: is uppercase text letter-spaced? Is body not over-tracked?

A review process only improves quality if it is consistently applied. Building it into the development workflow rather than treating it as an optional final step is the key.

Integrating review into the development workflow:

1. Pre-implementation review:

• Before implementing a design: run the 5-second test on the Figma artboard
• If you cannot answer the 5-second test from the design: ask the designer before implementing

1. Mid-implementation self-check:

• After implementing one section or component: squint test
• After implementing a full page: run Phase 3 (CRAP checklist) against the running page
• Fix any violations found before moving to the next section

1. Pre-PR review:

• Full 30-minute review before opening any PR with UI changes
• Document any violations found and fixed in the PR description
• Known violations that cannot be fixed this sprint: document as issues

1. Learning from violations:

• Keep a personal log of violations you repeatedly make
• After 3 occurrences of the same violation type: examine the root cause

(wrong token usage, missing design system component, different spec than expected)

• Fix the root cause, not just the symptom

Common developer-specific design violations:

11. Using 'font-weight: bold' instead of numeric weight
2   Fix: always use 400, 500, 600, 700 etc.
3
42. Setting font-size in px instead of rem
5   Fix: divide px by 16, use rem always
6
73. Using absolute line-height (px) instead of unitless
8   Fix: divide line-height-px by font-size-px = unitless ratio
9
104. Not setting max-width on prose containers
11   Fix: add max-width: 65ch to any text-heavy content area
12
135. Forgetting :focus-visible styles
14   Fix: add to every interactive element in the design system foundation
15
166. Inconsistent transition speeds (100ms here, 200ms there, 0.3s over there)
17   Fix: use --transition CSS variable for all transitions
18
197. Hard-coding colors instead of using tokens
20   Fix: search for any '#' in component CSS files, replace with var(--)