# Read-only UX, trust, and conversion audit for regional trades websites

Use when the user asks for a customer-perspective critique without implementation changes.

## Audit sequence

1. **Freeze the baseline.** Record branch, commit, and clean/dirty state before building or launching anything. Do not reset unexpected changes. Recheck status at the end; if concurrent edits appeared, state that the findings apply to the recorded baseline.
2. **Exercise the real build.** Run existing check/build and browser tests, then launch the built site. Keep screenshots and probe scripts outside the repository when the task is read-only.
3. **Inspect customer journeys, not only pages.** Cover homepage → service/reference proof → contact → inquiry completion. Test desktop and a real mobile viewport.
4. **Collect measurable evidence.** Record viewport, page height, horizontal overflow, fixed-bar and content bounding boxes, console errors, visible CTA labels, and actual form transport.
5. **Cross-check presentation against source.** Verify whether reference images are project-specific, years look current, trust claims have visible evidence, and CTA wording matches the actual action.
6. **Report in priority order.** Use Blocker / High / Medium, with observed evidence, customer impact, and one concrete remedy per finding. Include strengths and verification scope briefly.

## High-value checks

### Mobile fixed contact bars

A bottom bar can technically pass overflow tests while still hiding conversion content. At the initial viewport, compare its top edge with the bottom of the hero, trust strip, direct-contact card, and wizard controls. Ensure content/footer clearance is not the only mitigation: content must not begin underneath the bar.

### Honest inquiry transport

Inspect the compiled runtime state, not just form labels:

- If no endpoint is configured, a `mailto:` action is preparation, not submission.
- Contact preferences such as WhatsApp or phone must not culminate unconditionally in an email-only action.
- A “photos available” checkbox without an upload or share route creates channel-switch friction.
- For a secured endpoint, permit real upload only with verified privacy disclosure.
- Without an upload backend, prefer an explicit share flow: Web Share with files when `navigator.canShare({files})` permits it, then WhatsApp, email, and copy-summary fallbacks. Never imply transmission before the selected channel confirms it.

### Trust evidence

Separate evidence from slogans. Strong evidence includes verified business age, address, named regional project locations, project-specific imagery, and current external review links. Repeated claims such as “personal,” “clean,” and “directly reachable” are weak unless connected to proof. Do not invent response times, certifications, testimonials, staff, or project counts.

Check whether multiple reference detail pages reuse one generic hero image and whether all visible projects are many years old. Both can make authentic content look like placeholders or an inactive portfolio.

### Conversion density and motion

Measure mobile page height and note repeated blocks leading to the same CTA. A regional trades homepage should normally surface proof before a long catalogue and finish with one consolidated inquiry action.

Treat first-visit logo intros as conversion elements, not harmless decoration. Record their duration and whether they dim, cover, or delay the service proposition, region, phone number, or primary CTA. One-per-session and reduced-motion handling do not by themselves remove first-impression cost.

## Reporting caveats

- Distinguish verified defects from recommendations.
- A passing automated accessibility or no-overflow suite does not disprove visual occlusion, stale proof, excessive page length, or misleading CTA semantics.
- If the working tree changes during the audit, do not attribute or revert those edits. Report the exact audited commit and list the later dirty paths separately.