Concept· 2026
Web designDesign systemMotion3D

CLSD×LOOP:
a fintech argument
as a design system

Eight slides of B2B payments content, rebuilt as a design system and a live landing page. One token file, one accent, one easing curve. Self-initiated concept, no client.

Role
Self-initiated. No client. Concept, system, copy, build, 3D.
Scope
Design tokens, landing page, motion, two 3D objects.
Stack
React · Vite · TypeScript · CSS custom properties · Blender
Status
Live at polezhaev.design/clsdloop. Public examples, indicative figures.

Recorded from the live page. Every motion runs in the browser.

Open live site →

Challenge

Eight slides of dense payments content: issuing, acquiring, fee splits, thresholds. No budget for photography or illustration, and a brief I set myself: it has to read as a product, not as a design exercise.

Approach

System first, page second. One token file holds every colour, size and duration, and no component may hardcode one. One accent, one easing curve, no motion library. Two objects modelled in Blender and shipped as frame sequences.

Outcome

An eleven-section landing page that asks one question — should a payments business be both issuer and acquirer — and answers it. Nothing on it was bought. The system is written down well enough to build the next carrier from the same file.

Token file1

Every colour, size and duration on the page, in one file

Sections11

From the question in the hero to the verdict

Easing curve1

One cubic-bezier for every eased motion, no motion library

Bought assets0

Open-licence type, code and two Blender renders

Counted from the built page and its token file; the motion rules are in the project’s own spec.

The system is the deliverable. The page proves it.

One token file holds the colours, the type scale, the easing curve and every duration. Components read them as CSS variables and may not hardcode a value. The scale has a gap on purpose: nothing between display and body, which is what makes the page read as a poster.

The token sheet, rendered from the file the page runs on

Process

From eight slides
to one argument.

01

Cut

One question and the facts that decide it. The rest of the deck went.

02

Tokenise

Palette, scale and timings set once, in one file, before drawing a section.

03

Set

Each section is a screen: the loop, the fee split, the gate, the verdict.

04

Move

Every motion in code, no library. Two Blender objects carry the argument.

One typeface, a gap in the scale

Archivo for display and text, Martian Mono for the 9px meta line. Nothing between display and body. The hero asks the question; the verdict answers it at the same size.

The assembly the page scrubs by scroll, played through on its own curve

Two objects, both sides
of the argument

A coin turns on its own: a bank on one face, a card on the other. A card terminal assembles from its parts as the reader scrolls. Both were modelled and lit in Blender against the page’s accent and shipped as frame sequences with alpha, so the ground behind them is the section’s own colour.

One turn: issuing on the obverse, acquiring on the reverse. The rim reads ONE CLOSED LOOP.

Outcome

One file, one page, nothing bought.

The page is live and the system behind it is written down: decisions numbered, measurements recorded, motion rules checkable. The point is not the landing page but a way of building one.

  • Eleven sections from one token file
  • One easing curve, no motion library
  • Two Blender objects as frame sequences
  • Zero bought assets
TALK

If this is the kind of case you are hiring for, I am happy to walk through the decisions behind it.