DOMAIN:CREATIVE — DESIGN_QA_METHODOLOGY¶

OWNER: leah ALSO_USED_BY: margot (design production), boris (visual production), tobias (iOS design review), faye (team alfa PM), sytske (team bravo PM) UPDATED: 2026-03-28 SCOPE: quality assurance methodology for all creative output across GE client projects

PURPOSE¶

Leah validates ALL creative output before it leaves GE. She does not create — she validates. This page defines HOW to validate creative work systematically, distinguishing between objective specification compliance (measurable, automatable) and subjective creative review (requires judgment, but anchored to objectives).

CORE_PRINCIPLE: Every piece of creative output must be traceable to a specification. If something cannot be verified against a spec, the spec is incomplete — escalate to Anna (spec owner), not to the designer.

THE TWO TYPES OF CREATIVE REVIEW¶

TYPE_1: OBJECTIVE SPECIFICATION COMPLIANCE¶

These checks have binary pass/fail outcomes. No opinion required.

Check Category	What to Verify	Tool/Method
Color values	Hex codes match brand palette exactly	Programmatic extraction, delta-E comparison
Contrast ratios	WCAG AA minimum (4.5:1 normal text, 3:1 large text)	Contrast ratio formula (see below)
Typography	Font family, weight, size, line-height match spec	Token comparison against design system
Spacing	Margins, padding, gaps match design tokens	Pixel-level measurement against spec
Logo usage	Correct variant, minimum clear space, no distortion	Overlay comparison against brand guidelines
Asset dimensions	Export sizes match spec (1x, 2x, 3x for iOS)	File metadata inspection
File format	Correct format per deliverable type (SVG for icons, WebP for photos, etc.)	File extension + magic byte check
Naming convention	Files follow project naming scheme	Pattern matching against naming spec
Responsive breakpoints	Layout adapts correctly at specified breakpoints	Visual comparison at each breakpoint
Dark mode	All elements have dark mode variants where specified	Presence check + contrast verification

TYPE_2: SUBJECTIVE CREATIVE REVIEW (ANCHORED)¶

These checks require judgment BUT must be anchored to documented objectives. Leah does NOT apply personal taste. She evaluates against the creative brief.

Check Category	What to Anchor Against	Red Flag
Visual hierarchy	Creative brief's priority order	CTA is not the most prominent element
Emotional tone	Brand strategy's tone-of-voice document	"Playful" brand using corporate stock photos
Layout balance	Wireframe/comp approved by client	Major compositional shift from approved direction
Imagery selection	Brand photography guidelines	Off-brand style, wrong demographic, cultural mismatch
Copy-visual alignment	Copy deck + visual treatment	Headline says "simple" but design is visually complex
Whitespace usage	Design system spacing principles	Cluttered layout that contradicts brand's "premium" positioning

CRITICAL_RULE: If Leah's subjective assessment conflicts with a designer's intent, the creative brief arbitrates. If the brief is ambiguous, ESCALATE — do not impose personal judgment as fact.

PROGRAMMATIC COLOR VERIFICATION¶

HEX VALUE MATCHING¶

Direct comparison: extract hex from deliverable, compare against brand palette.

TOLERANCE: Exact match required for primary brand colors. No "close enough." For gradients and derived colors, document the derivation formula in the design system.

COMMON_FAILURES: - Designer eyedropped a color from a compressed JPEG (lossy = wrong hex) - RGB vs sRGB color space mismatch between design tool and export - Opacity applied on top of color creates a different effective hex - Dark mode palette uses wrong shade mapping (e.g., primary-500 instead of primary-200)

CONTRAST RATIO CALCULATION¶

The WCAG 2.1 contrast ratio formula:

contrast_ratio = (L1 + 0.05) / (L2 + 0.05)

Where L1 = lighter color luminance, L2 = darker color luminance.

RELATIVE_LUMINANCE calculation from sRGB:

L = 0.2126 * R + 0.7152 * G + 0.0722 * B

For each channel (R, G, B):
  1. Normalize: value / 255
  2. Linearize:
     if normalized <= 0.04045: linear = normalized / 12.92
     else: linear = ((normalized + 0.055) / 1.055) ^ 2.4

WCAG_THRESHOLDS:

Level	Normal Text (<18pt, <14pt bold)	Large Text (>=18pt, >=14pt bold)
AA (minimum)	4.5:1	3:1
AAA (enhanced)	7:1	4.5:1
Non-text (icons, borders)	3:1	3:1

GE_STANDARD: All client deliverables MUST meet WCAG AA minimum. AAA is the target for body text.

FUTURE_NOTE: APCA (Advanced Perceptual Contrast Algorithm) is under development for WCAG 3.0. It accounts for polarity (light-on-dark vs dark-on-light). Monitor for adoption — do not switch until W3C finalizes.

DELTA-E COLOR DISTANCE¶

For comparing "is this the right shade?" when exact hex matching is insufficient (e.g., print-to-digital conversions):

Delta-E (CIE76) = sqrt((L1-L2)^2 + (a1-a2)^2 + (b1-b2)^2)

Delta-E Value	Perception
0-1	Not perceptible by human eye
1-2	Perceptible through close observation
2-10	Perceptible at a glance
11-49	Colors are more similar than opposite
100	Colors are exact opposites

GE_TOLERANCE: Delta-E < 2 for brand primary colors in digital deliverables.

TYPOGRAPHY VERIFICATION¶

WHAT TO CHECK¶

Property	How to Verify	Common Failure
Font family	Extract from file metadata or CSS	Designer used system font fallback instead of brand font
Font weight	Compare rendered weight against spec (400, 500, 600, 700)	"Semi-bold" interpreted differently across tools
Font size	Measure in spec units (px for web, pt for iOS, sp for Android)	Size correct at 1x but wrong at other scales
Line height	Ratio or absolute value per spec	Line height set in px when spec says ratio (1.5)
Letter spacing	Measured in em or px per spec	Tracking applied in design tool not exported to CSS
Text transform	Uppercase, lowercase, capitalize per spec	Designer manually typed UPPERCASE instead of using transform
Font rendering	Antialiasing method (subpixel, grayscale)	Font looks different on macOS vs Windows due to rendering

FONT LICENSING CHECK¶

VERIFY: Every font used in client deliverables has a valid license for the intended use. - Web fonts: WOFF2 with appropriate license (Google Fonts = OK, Adobe Fonts = check subscription) - iOS: System fonts (SF Pro) are free for Apple platforms only - Print: Some web licenses do NOT cover print usage

ESCALATION: If font licensing is unclear, flag immediately. Using an unlicensed font in a client deliverable is a legal risk.

LAYOUT VERIFICATION¶

AGAINST WIREFRAMES/SPECS¶

PROCESS: 1. Overlay deliverable on approved wireframe at same scale 2. Check element positioning against grid (8px grid standard) 3. Verify information hierarchy matches wireframe intent 4. Confirm responsive behavior at all specified breakpoints

MEASUREMENT_TOLERANCE: - Web: +/- 1px for spacing, exact for grid alignment - iOS: Exact match to design tokens (use Auto Layout values) - Print: +/- 0.5mm for physical dimensions

CROSS-DELIVERABLE CONSISTENCY¶

When a project has multiple deliverables (website + iOS app + print materials), verify:

Consistency Check	What to Compare
Color application	Same semantic colors used for same purposes across all media
Typography scale	Proportional hierarchy maintained (H1 > H2 > H3 ratios)
Component patterns	Buttons, cards, forms look like the same family
Imagery treatment	Same photo style, filter, crop approach
Iconography	Same icon set and style (not mixing outline and filled)
Voice and tone	Copy follows same tone guidelines regardless of medium
Logo placement	Consistent positioning relative to layout grid

DESIGN QA CHECKLIST (PER DELIVERABLE)¶

Run this checklist for EVERY creative deliverable before sign-off.

PHASE_1: SPECIFICATION_COMPLIANCE (Objective)¶

[ ] All colors match brand palette hex values exactly
[ ] All text meets WCAG AA contrast ratio (4.5:1 normal, 3:1 large)
[ ] Typography matches spec (family, weight, size, line-height, spacing)
[ ] Spacing follows design token system (8px grid)
[ ] Logo usage follows brand guidelines (variant, clear space, minimum size)
[ ] All assets exported at correct dimensions and formats
[ ] File naming follows project convention
[ ] Responsive layouts verified at all specified breakpoints
[ ] Dark mode variants present and contrast-compliant where specified
[ ] Interactive states defined (hover, active, focus, disabled) where applicable
[ ] All placeholder/lorem ipsum content replaced with real or realistic content
[ ] No orphaned layers, hidden elements, or debug artifacts in deliverable

PHASE_2: BRIEF_COMPLIANCE (Anchored Subjective)¶

[ ] Visual hierarchy matches brief's priority order
[ ] Emotional tone aligns with brand strategy document
[ ] Layout matches approved wireframe/comp direction
[ ] Imagery aligns with brand photography guidelines
[ ] Copy and visual treatment are congruent (no contradictions)
[ ] Target audience would recognize this as designed for them
[ ] Deliverable achieves the stated objective from the brief

PHASE_3: CROSS_DELIVERABLE (If multi-deliverable project)¶

[ ] Visual language consistent across all deliverables
[ ] Design tokens used consistently (not ad-hoc values)
[ ] Component patterns recognizable as same design system
[ ] Responsive behavior is consistent in approach (not ad-hoc per page)

DESIGN QA WORKFLOW¶

DESIGNER COMPLETES WORK
        |
        v
LEAH RUNS PHASE_1 (SPEC COMPLIANCE)
        |
   PASS?---NO---> RETURN with specific violations list
        |              (hex #XYZ should be #ABC, line 14)
       YES
        |
        v
LEAH RUNS PHASE_2 (BRIEF COMPLIANCE)
        |
   PASS?---NO---> RETURN with brief reference
        |              ("brief says X, deliverable shows Y")
       YES
        |
        v
LEAH RUNS PHASE_3 (CROSS-DELIVERABLE) [if applicable]
        |
   PASS?---NO---> RETURN with inconsistency report
        |
       YES
        |
        v
DELIVERABLE APPROVED — mark as QA_PASSED

CRITICAL: Leah NEVER fixes issues herself. She identifies and returns with actionable feedback. Feedback format: ALWAYS reference the spec, NEVER personal preference.

BAD: "I think this blue looks too dark" GOOD: "Background color #1A237E does not match brand primary #1976D2 (spec: brand-guidelines.md section 3.2)"

BAD: "The layout feels off" GOOD: "CTA button is below the fold at 768px breakpoint, contradicting brief requirement BRF-007: 'CTA must be visible without scrolling on tablet'"

ANTI-PATTERNS¶

Anti-Pattern	Why It's Wrong	What to Do Instead
"Looks good to me" sign-off	Not anchored to any spec — valueless	Run the checklist, reference specs
Pixel-perfect obsession beyond spec	Wastes cycles on unspecified tolerances	Only enforce what the spec defines
Subjective feedback presented as objective	Undermines trust, causes friction	Label subjective feedback as such, anchor to brief
QA at the end only	Late-stage rework is expensive	Checkpoint QA at wireframe, comp, and final stages
Fixing issues instead of flagging them	Leah is QA, not designer — role contamination	Return with actionable feedback, let designer fix
Checking against memory instead of docs	Memory drifts, docs are SSOT	Always open the spec and compare
Skipping dark mode checks	"We'll do dark mode later" — and then it never happens	If dark mode is in scope, check it every time

INDUSTRY REFERENCE: HOW TOP COMPANIES DO DESIGN QA¶

GOOGLE (Material Design)¶

Component quality checklist covers brand guidelines + Material + HIG equivalents
Automated visual regression testing with screenshot comparison
Design tokens are the single source of truth — human review compares against tokens, not memory
Accessibility is non-negotiable: every component must pass automated a11y audit

APPLE (Human Interface Guidelines)¶

App Review enforces HIG compliance as a gate (your app gets rejected if it violates HIG)
Platform-specific design language: do not port Android patterns to iOS
SF Symbols provide a canonical icon set — using custom icons when SF Symbols has an equivalent is a violation
Dynamic Type support is expected — fixed font sizes are a QA failure

AIRBNB (Design Language System)¶

DLS provides design tokens that are the contract between design and engineering
Visual QA is automated where possible (snapshot testing)
Cross-platform consistency is enforced through shared tokens, not through visual comparison
Design reviews use structured critique format anchored to objectives

LYFT (Design Systems Team)¶

Quality Component Design Checklist: review brand guidelines, Material/HIG equivalents, UX research, and audit all current designs
Components go through structured QA before entering the design system
Cross-references multiple design systems to ensure platform-appropriate implementation