ProUXAudit Design System 1.3

A UX audit loses value when an observation and a recommendation merge into one vague judgement. The ProUXAudit design system separates the observed situation, its evidence, priority, proposed change and the check that judges the result after implementation, so a client gets a decidable work order rather than only a score. Its documentation states the rule plainly: the product is a precise instrument for deciding what to improve, not a dashboard for watching AI work. [2] Design reference · Design-system documentation · reviewed 21 Oct 2026

The system lives in the product repository as one token file. Colour roles, the type ladder, space, radii, layers and durations that screens read all come from it. Eleven legacy colour names remain as aliases that point at the new roles; removing them is a versioned migration, not a silent deletion. [1] Observed · Versioned code · reviewed 18 Oct 2026

The public audit intake and shareable report are visible product surfaces. Screens in the case captured on 12 September 2026 show those specific views; an empty findings area in one report does not establish that the rest of a website has no issues. [3] Observed · Dated case gallery · reviewed 12 Sept 2026

The specimen is six plates built from a file derived from the product's tokens.json: colour roles in both themes, the type ladder with its tracking curve, shape and space, static component renditions, the finding-to-decision chain and spring motion. Values are read when the page is built, so the plates cannot drift from their own token file; the file's link to the product code is stated in the source reference. [1] Observed · Versioned code · reviewed 18 Oct 2026

Every swatch shows its hex value and the contrast against the ground its usage rule names. Contrast for twenty-two role pairs is computed in both the dark and the light theme with the WCAG 2.x formula; the table lists each pair's minimum and both results. The result is calculated, not measured on a screen. [3] Observed · Contrast computation · reviewed 18 Oct 2026

The finding card uses an illustrative landing page where two equally prominent actions compete for attention. It separates the observation, an expandable example layout as evidence, severity “high · example only”, the change “one primary action” and a follow-up check in a real browser. Severity is not a measured customer finding; the card does not analyse your URL or use customer data. [4] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

The motion plate draws the product's spring presets with the same equations the product uses. Opening it loads a lab: drag or throw a puck, tune damping and response, and watch the landing point come from projected momentum rather than from where you let go. [2] Observed · Versioned code · reviewed 18 Oct 2026

Components on the plates are drawn renditions with sample text: no button sends a request, no field reads input and no payment is requested. Where a plate shows an offer, payment and order states remain design proposals. [5] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

Colour is assigned by meaning. Canvas, surface, raised and selected are planes; text and muted carry copy; mint is the action colour for one filled primary action per decision group and never stands for “good”. Status colour always travels with a word or an icon, and the light theme is specified on its own rather than inverted from the dark one. [4] Design reference · Design-system documentation · reviewed 21 Oct 2026

Only navigation chrome may be translucent; evidence, findings, prices and forms stay opaque, and a card is never muted by lowering its opacity. Depth runs from canvas through content, chrome, popover, scrim and modal to toast, and a shadow appears only on something that genuinely overlaps another plane. [4] Design reference · Design-system documentation · reviewed 21 Oct 2026

Geist has one weight axis and no optical-size axis, so the optical work lives in the tokens. Each role sets size, leading, weight and tracking together; tracking follows a logarithmic curve from −0.035 em at display sizes to +0.012 em at the smallest text, and only the eyebrow is set in capitals. [1] Observed · Versioned code · reviewed 18 Oct 2026

Every interactive element is at least 44 × 44 pixels at every breakpoint and primary task controls are 48 pixels. Reading width stays at 680 pixels and forms at 512 pixels; a long URL never pushes a page sideways. [1] Observed · Versioned code · reviewed 18 Oct 2026

A spring has two parameters: damping and response. An animation starts from the value on screen, release velocity is handed to the spring, and a release above 400 px/s is a throw that earns 0.8 damping; a slow release settles without overshoot. Under reduced motion the value jumps instead of travelling. [2] Observed · Versioned code · reviewed 18 Oct 2026

A component contract includes default, pending, invalid, empty and recoverable states. A field keeps a persistent label, an error names the fix, and red alone never carries the message. [5] Design reference · 1.2 design prototype · reviewed 24 Sept 2026 “Queued” does not mean “complete”, and “payment confirmed” does not mean “audit delivered”. [6] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

On a phone, audit intake keeps one URL field and the next action visible; finding evidence and recommendation follow in reading order without hover. A tablet is not a stretched phone: wider space can place report evidence beside the decision while preserving reading order. Both layouts are 1.2 design references, not confirmation of deployed device views. [5] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

The system is enforced, not only documented. A token gate in the product repository checks contrast in every theme, the match between the token file and the generated stylesheet region, and the type curve, and keeps per-file budgets of raw palette utilities that may only fall. A second check maps every changed file to the routes that render it. [3] Observed · Versioned code · reviewed 18 Oct 2026

Token values, spring presets and gate scripts were read from the product repository at staging commit bee85a6 on 18 October 2026. This shows what the code defines; it does not establish that every production screen already reads only these roles. Eleven legacy colour names still resolve as aliases until their own migration. [1] Observed · Versioned code · reviewed 18 Oct 2026

Contrast figures are computed from token values, not measured on a display, and they cover the role pairs the usage rules name, not every possible combination. [3] Observed · Contrast computation · reviewed 18 Oct 2026

The gallery of public surfaces captured on 12 September 2026 establishes how audit intake and a shareable report looked on that date. It does not measure site-wide accessibility, customer numbers, collected payments or sales growth. Browser verification and an agreed client goal are needed before judging the effect of repairs. [6] Observed · Dated case gallery · reviewed 12 Sept 2026

The documentation is a wider reference that also holds app-shell, audit-panel and commerce cards. The whole reference can also be browsed as an interactive platform: 28 components in the dark and light themes, 16 of them live React components (hand-written renditions of the app's originals) and 12 labelled as static renditions. [4] Design reference · Design-system documentation · reviewed 21 Oct 2026 This page curates its foundations and labels workspace and purchase states as proposals; evidence from a public screen does not transfer to the production status of those views. [7] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

The gate scripts exist in the repository and run in its continuous-integration workflow; this page does not publish the result of their latest run. [2] Observed · Versioned code · reviewed 18 Oct 2026

Device layouts and other 1.2 prototype behaviour are a design reference; this page does not claim that every view in the 1.2 prototype has been tested. [5] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

If you have an audit or a difficult journey, we can review one important finding together: verify it in a browser, order changes by likely impact and agree up to three repairs or the scope of a new website. We then check the same journey after implementation; measuring its effect requires separate data. [2] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

If your product needs the same discipline — one token file, computed contrast, motion with defined parameters — send the public URL and the interface you want to stabilise. The first deliverable is an inventory of the values already in use and a proposal for which of them become tokens. [1] Design reference · Design-system documentation · reviewed 21 Oct 2026