ProUXAudit Design System 1.2

A UX audit loses value when an observation and a recommendation merge into one vague judgement. ProUXAudit Design System 1.2 separates the observed situation, its evidence, priority, proposed change and the check that can evaluate the result after implementation. The client gains a decidable work order rather than only a score. This describes the design reference, not a promise about every public report. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 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. [2] Observed · Dated case gallery · reviewed 12 Sept 2026

The local specimen uses an illustrative landing page where two equally prominent actions compete for attention. Its card 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 and assessing impact needs separate data. The whole chain is readable without scripts; it does not analyse your URL or use customer data. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

The public report screenshot is dated evidence of a product surface. [2] Observed · Dated case gallery · reviewed 12 Sept 2026 The finding card beside it is a design reference. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026 Where the story reaches pricing or purchase, payment and order states in the 1.2 document remain design proposals. The specimen sends no payment request and creates no order. [3] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

The foundation uses colour by meaning: canvas, surface, raised surface, text, action and error do not change jobs for individual screens. The 1.2 reference uses 17 px report text and 16 px control text; prices, evidence and form fields remain on opaque surfaces. Translucent material may support navigation but cannot weaken the readability of a decision. These are reference dimensions and roles, not verified production CSS. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

The wordmark keeps clear space; its source asset and usage rights need checking before new media is published. The 1.2 prototype's iPhone and iPad views show different layouts, but they are neither external platform approval nor a separate production release. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

A component contract includes default, pending, invalid, empty and recoverable states. One decision group has one primary action, a field keeps a persistent label, and an error has descriptive text associated with its input; red alone cannot carry the message. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026 “Queued” does not mean “complete”, and “payment confirmed” does not mean “audit delivered”. [2] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

The motion specimen can retarget an object mid-flight while preserving its current position; reduced-motion settings make the state change immediate. The evidence panel has a visible close control and Escape path, rather than relying on dragging. These are prototype behaviour rules from 1.2; their keyboard and motion paths need independent testing in the public specimen. [1] Design reference · 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. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

Each finding needs one checkable observation, visible or described evidence, a reason for its priority, a proposed action and a condition for judging the repair. An assumption is not a measured outcome; missing evidence stays missing. This lets a client distinguish a quick repair from a larger discovery task. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

For purchase, “service selected”, “sent to payment”, “provider-confirmed payment” and “order ready for work” are distinct states. A local or illustrative return screen cannot confirm an actual payment or automatically started work. This is a proposed state contract in the 1.2 prototype, not evidence of public transactions. [2] Proposal · 1.2 design prototype · reviewed 24 Sept 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. [2] Observed · Dated case gallery · reviewed 12 Sept 2026

The 1.2 HTML is a wider design-system reference with audit, report, workspace and billing views. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026 This page curates its decision chain and labels workspace and purchase states as proposals. Evidence from a public screen does not transfer to the production status of those proposed views. [3] Proposal · 1.2 design prototype · reviewed 24 Sept 2026

Route coverage means repeated browser checks of enumerated journeys, not a claim of complete product coverage drawn from one prototype view. This selection explains the decision chain; it does not publish or claim to test every view in the 1.2 prototype. [1] 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. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026

Send the public URL and the user's most important action when you contact us. The first deliverable is an evidence-linked next decision, not an automated judgement from the example card. [1] Design reference · 1.2 design prototype · reviewed 24 Sept 2026