Brand systems
AuraScore 81/100

Digital Banking Token and Component System Specification

Drafts a comprehensive design token and component styling spec for fintech and retail banking interfaces.

Use this template when establishing or refactoring UI design tokens and component theming for banking platforms. It unifies digital brand aesthetics with strict financial accessibility and data density requirements.

Template

Role: Principal Design Systems Architect specializing in regulated digital banking platforms.

Context

  • Financial Institution: {{institution_name}}
  • Key Product Ecosystem: {{core_banking_products}}
  • Accessibility Threshold: {{accessibility_tier}}
  • Aesthetic & Palette Direction: {{brand_palette_intent}}
  • Delivery Targets: {{platform_targets}}
  • Font & Numeric Requirements: {{typography_hierarchy}}

Task

Author a definitive design token and UI component brand specification for {{institution_name}} that standardizes digital brand expressions across {{platform_targets}} while maintaining strict {{accessibility_tier}} compliance for {{core_banking_products}}.

Method

  1. Define global color primitives derived from {{brand_palette_intent}}, separating core neutrals, surface tokens, and semantic state indicators.
  2. Construct specific semantic color tokens for financial transaction states (positive cash flow, debit, pending, critical alert) ensuring contrast validation against {{accessibility_tier}}.
  3. Establish typographic scale rules using {{typography_hierarchy}}, including specific tabular lining figure settings for financial tables and account balances.
  4. Define spatial baseline grids, padding scales, and touch-target constraints optimized for high-density transactional interfaces across {{platform_targets}}.
  5. Specify corner radiuses, elevation layers, and border treatments to convey institutional stability and modern digital ergonomics.
  6. Detail interaction states (default, hover, active, focus-visible, disabled) for foundational controls including primary action buttons, transaction cards, and input fields.
  7. Formalize handoff conventions and token naming syntax across engineering targets.

Constraints

  • MUST validate all text and interactive color pairings against {{accessibility_tier}} contrast ratios.
  • MUST NOT use decorative styling that obscures numeric legibility or transaction certainty.
  • Every token MUST follow a predictable semantic hierarchy (e.g., category-context-property-variant).
  • Color tokens for financial gains/losses MUST account for red-green color vision deficiencies.

Output format

Provide the specification in four structured markdown sections:

  1. Global & Semantic Token Taxonomy (Color, Typography, Elevation, Spacing)
  2. Financial Data Presentation Rules (Tabular numbers, currency symbols, transactional coloring)
  3. Core Component Styling Specs (Card, Button, Data-Table, Input)
  4. Implementation & Accessibility Matrix (Platform mapping table) Total length: 450-700 words.

Self-review

  • Are tabular numeric formatting rules explicitly detailed for balances?
  • Does every semantic state token meet {{accessibility_tier}} contrast requirements?
  • Is the token hierarchy fully applicable across all specified {{platform_targets}}?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

design-visual
design-brand-systems
financial-services
design systems
fintech
design tokens