Live tool
CT Lab · Design Systems
Feed Card Pattern Spec
A Design Engineering Case Study
Executive Summary
The Feed Card Pattern Spec is a living visual specification for a single feed card. Rather than describing the pattern in prose, it annotates a real rendered photo of the card with measured spacing, the type scale, a component breakdown, and the named design tokens behind every value. It also ships its own accessibility layer: vision and color-vision- deficiency (CVD) simulation modes plus automated flagging of color-only signals. It is fully static and client-side: vanilla JS with embedded images, no backend and no API.
In one line
A redline that can't go stale, because the spec is drawn on top of the actual UI, traces every value to a token, and treats accessibility as part of the specification rather than a later review.
The Problem
Design specs drift from the real rendered UI almost immediately. Static redlines are authored once, then quietly diverge as the component evolves. The document says one thing, the screen shows another. Teams burn cycles arguing over spacing values and which token a color came from, because the source of truth lives in someone's head or a stale frame.
Accessibility makes the drift worse. Color-only signals (a red save button, a status chip, a category swatch) fail color-vision-deficient users entirely, and they violate WCAG 1.4.1 (Use of Color) and Section 508. Those failures rarely surface in a normal spec review, because the reviewer has typical color vision and the redline never simulates anything else.
How It Works
The tool renders the feed card as a live photo and overlays the specification directly on it:
What it annotates
- Spacing: measured padding, gaps, and corner radii called out on the real card
- Type scale: title, source, and label sizes/weights documented in place
- Components: anatomy of card, image, save button, and overflow control across states
- Design tokens: every value traced
primitive → semantic → component
Vision & CVD simulation
Built-in vision modes re-render the card through CVD matrices (Deuteranopia, Protanopia, Tritanopia) plus achromatopsia and a low-vision blur/contrast pass, so you can see how the pattern reads for different vision before shipping it.
Compliance flagging
The spec flags color-only dependencies against WCAG 1.4.1 and Section 508, surfacing them as live pass/warn indicators. Everything runs in the browser: vanilla JS and embedded images, no server round-trip and no API.
Design Decisions
Annotate the real card, not an abstract redline
The spec is drawn over the actual rendered component. Because it is anchored to the real pixels, it cannot quietly drift from the UI the way a separate redline does.
Name every token explicitly
Each value is traced through the full chain (primitive to semantic to component) so there is no ambiguity about where a color or spacing unit comes from. The argument over "which token?" is answered in the document.
Accessibility is part of the spec
CVD simulation and color-only flagging are built into the specification itself, not bolted on as a separate accessibility review. The pattern is specified and audited in the same artifact.
No backend on purpose
Keeping it client-side makes the spec deterministic, instant, and trivially shareable as a single file, the right constraint for a reference document that should load and render the same way every time.
What This Demonstrates
Design-systems thinking: token chains, component anatomy, and a documented type scale. Accessibility expertise: CVD simulation and WCAG 1.4.1 / Section 508 compliance treated as first-class, not surface-level. And constraint-appropriate engineering: a static, client-side build with no API because the job doesn't need one. It's part of the CT Lab pattern suite, alongside the Pattern Quality Auditor.