Lab signal
Families tracked
7 shared shells
Premium route cards, KPI cards, trading operator cards, and feature proof cards are documented here together.
AttnomSolutions
Loading page
Bringing in the next surface without the heavy transition shell.
Loading page
Bringing in the next surface without the heavy transition shell.
Attnom Cards documents the rules behind the card system: token logic, state behavior, motion discipline, and where each family is already live across the product.
Pattern lab signals
Lab signal
Families tracked
Premium route cards, KPI cards, trading operator cards, and feature proof cards are documented here together.
Lab signal
Motion model
Entry timing, hover lift, viewport staging, and reduced-motion safety are all pulled from the shared motion file.
Lab signal
Adoption map
Platform, Solutions, Workspace, Exchange, and Services now have route references so designers and developers know where the system is already carrying work.
System charter
The system only works when each card knows its job: explain a signal, route the user, document proof, or let an operator act. Empty shells and generic filler are now anti-patterns, not placeholders.
Token goal
Accent, radius, and shadow should identify the card family before the user reads a word.
State goal
A read-only signal, linked route card, and actionable card should feel different immediately.
Adoption goal
The same shell should change tone and copy when it moves from Platform to Solutions, Workspace, or Exchange.
If a new card breaks one of these rules, it should be considered a new family and documented as such instead of slipping in as a one-off.
Cyan carries primary guidance, blue frames trust and system state, yellow marks sequence, lime signals positive readiness, sunset carries cross-route tension, and ink anchors operating surfaces.
Uppercase mono headlines give the cards a deliberate control-room feel, while body text stays in the body font so dense explanation is still legible on smaller screens.
Most cards sit in the 28-36px radius band with a black 2px keyline. That contrast keeps the system feeling premium without turning soft or anonymous.
Shadows move with intent. Flat white cards use black offsets, while premium cards use tone-aware shadow color to show which lane the card belongs to.
The right question is not which card looks good, but which state best matches the next job the route has to do.
Card family
State behavior
Current guidance
Use these for route decks, hero splits, proof clusters, and structured operating boards.
Best used in
State note
The card explains a signal without forcing the user to click immediately.
Last interaction
No live interaction yet. Open an actionable card state to see what the component emits.
Default state
Card state
Use this state when the page needs to explain readiness before it asks for a click.
Default state
Proof cards can explain why a lane exists without needing to eject the reader into another route first.
Best for trust, operating model, and route explanation.
The motion file already gives the system its rhythm. These are the rules the cards page expects every route to respect.
01
Reveal timingMost card entrances should use spring easing 0.22 / 1 / 0.36 / 1 with fade-up behavior. Save larger blur reveals for section wrappers, not every child card.
02
Hover behaviorDefault lift is around 6px with a matching shadow shift. Do not stack lift, rotation, and oversized glow unless the card is intentionally a playful utility surface.
03
Scroll disciplineCards generally enter on first view and then remain stable. Repeated looping effects belong on rails, glows, or ambient details, not on core reading surfaces.
04
Safety ruleIf a control disappears behind scale-zero animation or lands below a 40px hit target, the motion is wrong. Safety and readability win over flourish every time.
Adoption map
These references point to real routes already importing the shared card families, so the lab stays grounded in actual adoption instead of aspirational design language.
Adoption route
/The root route uses premium cards to explain route choice, continuity, and platform utility before asking the user to descend deeper.
Adoption route
/solutionsThe commercial route uses card families to stage operating signals, delivery proof, route deck choices, and cross-route handoff.
Adoption route
/workspaceWorkspace leans on the split hero, action ribbon, and proof cards to keep projects, payments, and exchange notices legible in one surface.
Adoption route
/exchangeExchange surfaces use the same premium card language, but the copy shifts toward trust, custody, support, and operational readiness.
Adoption route
/services/*The service pages now use the pattern lab logic to keep configurators, proof sections, and route-specific next actions aligned with the broader system.
Usage reference
If a route needs a new shell, document why the existing families fail first. Most route work should start by composing the current families with better copy, proof, and CTA logic.
import {
CardDock,
CommandCard,
MetricBandCard,
ProofCard,
SplitInsightCard,
TimelineCard,
} from '@/components/ui';
// Compose the smallest family that fits the route job.
// Document new state behavior here before shipping it elsewhere.