Confusing page UX

What usually goes wrong

• No single primary action above the fold
• Heading that does not state the visitor's job
• Too many equal buttons (decision paralysis)
• Mobile first screen cut off or crowded

What we will not invent

No fake conversion rates, user quotes, competitor rankings, or accessibility scores without real observation. If we cannot capture the page, we say so.

The job is a landing page that is hard to use

Someone arrives and cannot tell what the page is for, which choice is the default, or which button is the one that matters. That is a first-screen problem. It is not a request for a forty-point audit, a heatmap you do not have, or a rewrite of the whole site. Design UX Radar on /cro takes one public URL and returns one first-screen repair.

Scores come from fixed rules; a small language model writes the next-step text. The check starts from real screenshots of the rendered page. The paid tier is $29/mo for one URL stream: vision plus a model repair, re-runs while the subscription is active, and a preview you can read. Neither tier edits the live site, injects code, or publishes a change. You decide whether the repair is worth making.

A live packet states a claim limit in plain language. It says whether screenshots were captured, and it refuses traffic numbers, reviews, conversion rates, and accessibility scores that were not observed. If the top line is unclear, or there is no obvious main button, that gap is named. Recommendations stay inside what is visible. If capture fails, the packet says the screenshot is missing instead of drawing a page that was never seen.

One example of what comes back

The product page shows a labeled example, not a customer and not a live capture. The fixture URL is https://example.com/pricing. The claim limit on that example is: Example only — synthetic illustration, not a live capture of your site. The headline is: Visitors land and cannot tell which plan is for them. The visitor job on the card is: Pick a plan and start without guessing.

The one recommended change is: Do this next: Put one recommended plan above the fold. Effort on the card: About 30 minutes. Before: Three equal plan cards with no recommended choice. After: One plan marked “Most teams start here” with a single primary button. Why, as written on the example: When every option looks equal, people stall. A clear default reduces decision time. The matching visual is three equal plan cards, with the middle card marked “Most teams start here”. That badge is the after-state of the same repair. It is not a measured win.

A live free packet uses the same shape when a real URL can be captured: one headline, one primary repair with before, after, and why, and a claim limit that sticks to the screenshots. It does not add a second equal recommendation so the page looks busier.The paid tier can rerun that repair with vision. The free path already has to show a real first-screen check, not a locked stub.

The receipt beside the repair

Launchfiles hands the change over with a receipt. The public sample at /receipt/sample is a shape, not proof that a site was repaired. Nothing runs from that page. The sample verdict is “This homepage title is leaking first-visit clicks.” What exists on the sample is an unclear H1 and a buried primary action, bound to the route /. The claim limit printed on it is “Sample shape. Not live proof. No traffic or rank guarantee.”

The before note is “Unclear title. Primary action buried.” The after note is “One title. One action. Sample shape only.” The next line is “You approve, skip, or revise.” The window line says a 14-day window starts when you stamp, and that this sample has no traffic or rank numbers. The boundary is no publish, no deploy, no outbound send, and approval required. Ready items for live screenshots and sign-off are unchecked. The summary says the sample is not ready to treat as a live result.

Read that sample when you want to see the fields. Do not treat its homepage sentence as a finding about your URL. Your packet is a different object, filled only after a capture of the URL you paste. If the capture is empty, the receipt stays empty on the visual instead of inventing a before and after.

What to look at on the first screen

Use the repair as a reading order, not as a pile of opinions. Start with the headline: does it name the visitor’s job, or only the company name? Then the primary action: is there one button that is clearly first, or several controls with the same weight? Then the offer: on a pricing page, equal cards with no recommended plan make people stall. On a product page, a buried action below the fold has the same effect. On a phone, a first screen that is cut off or crowded hides the action even when the desktop looks fine.

Design UX Radar scores what it can see and leaves the rest unclaimed. It does not emit a CSS diff, an accessibility grade, or a conversion forecast. Public packets do not include attention heatmaps. Those would require a tag and an authenticated workspace, and they are not part of the public check described here. The useful output is still one change: what to put first, why that follows from the screenshot, and how you will know whether the first screen is clearer after you edit it.

You apply the edit in your own tool. Launchfiles does not log into the CMS, does not push the change, and does not mark the work done because a packet exists. A packet is a recommendation under a claim limit. Skipping it is a valid outcome. Revising the wording before you ship it is a valid outcome. Approving the text and then editing the page yourself is the path that changes the live site.

Where this sits in the harness

The AI work harness is the loop around this check: context, checks, a claim limit, one change, approve, receipt. Design UX Radar is the check for a page that is hard to use. The harness does not publish, deploy, or spend without approval. The same rule binds this repair. If you want a draft of new page copy instead of a first-screen repair, that is a different tool, and it still will not publish for you.

Start with the example if you only want the shape. Paste a URL when you want a packet about a real page. If the screenshot cannot be taken, stop there and fix access before asking for a smarter rewrite. A repair that is not tied to a capture is not a result.