Methodology
How UXMachine diagnoses a URL
UXMachine does not guess from a prompt. It starts from observable evidence: the visible experience of a public URL, its structure, accessibility signals and the friction a visitor would face before taking action.
Two ways to read a UXMachine diagnosis
Start with the executive summary when you need a fast decision. Open the full report when you want to inspect the evidence.
Quick read · 3 minutes
Use the executive summary to understand what may be blocking clarity, trust or action — and what to review first.
Deep read · 20 minutes
Use the full report to inspect the visual and textual evidence behind the recommendation.
- URL or screenshot
- Visual + textual reading
- Friction signals
- Prioritized decision
- 3-minute summary / 20-minute report
Why evidence comes first
A useful UX diagnosis must start from what is observable, not from general best-practice templates applied without context. When a system invents business context it does not have, the output becomes generic advice — which looks like a diagnosis but is not.
UXMachine captures visible signals for the specific page being analysed. If the evidence is insufficient to make a specific recommendation, the report says so explicitly and tells you what to verify before acting.
This is why uncertainty in the output is visible, not hidden.
The diagnosis pipeline
- 1
Capture the first visible viewport
UXMachine analyses the first visible viewport of the URL — what a visitor sees without scrolling — and the technical and semantic signals available from that experience. Some pages may block or limit capture; when that happens, UXMachine returns a partial structural reading or no diagnosis instead of inventing a recommendation.
- 2
Build an evidence package
It collects observable signals: structure, visual hierarchy, CTAs, accessibility cues, layout risks and visible content.
- 3
Identify friction
It looks for places where a visitor may struggle to understand what the page offers, what to do next or why to trust it.
- 4
Separate actionable findings from signals to verify
Some issues are ready to act on. Others should be checked before changing the page. The report separates them clearly.
- 5
Produce an action-first report
The output prioritises what to change, what to verify and what not to overinterpret.
Evidence sources and how they weigh
UXMachine does not treat URLs, captures and context as interchangeable inputs. Each source proves a different part of the decision.
- Public URL: structural evidence. It reads content, CTAs, DOM structure, semantic hierarchy, accessibility signals and flow.
- Capture: perceptual evidence. It reads visual hierarchy, visibility, contrast, focus, trust signals and first impression.
- Figma: design-intent evidence, coming soon. It will compare the intended design, components and variants with the real implementation.
- Context: decision lens. Your goal changes which signals matter first.
The source that weighs most depends on the blocker. Structural blockers rely more on URL evidence. Visual, trust or first-impression blockers rely more on Capture. Design-execution gaps will rely more on Figma when available.
How UXMachine avoids generic advice
Findings must be tied to visible evidence from the captured page. Generic recommendations — ones that would apply to any page regardless of what was observed — are filtered, downgraded or presented as verification tasks rather than direct actions.
A report that says "verify this before changing it" is still useful. It is more honest than one that presents weak signals as certainties.
Technical and accessibility signals are included in the output. They appear subordinate to the main UX decisions, so they do not dominate a diagnosis that has more significant structural findings.
What the report gives you
Main friction signals
Where visitors are likely to lose clarity, confidence or direction.
Prioritised actions
What to change, with reasoning tied to what was observed — not to general principles.
Verification checks
Signals that are plausible but need confirmation before you change the page.
Technical hygiene
Accessibility issues, contrast failures and structural problems worth tracking.
Evidence notes
Where each signal came from and what was captured to support it.
Known limitations
What the current capture could not reach and what that means for the diagnosis.
What this methodology does not claim
- It analyses primarily the first visible viewport of the URL — not the full site.
- It does not replace user research.
- It does not see analytics, revenue or private funnels unless you provide them.
- It does not audit every page of a site from one URL.
- It does not guarantee capture on every public page — anti-bot protection, paywalls or heavy JavaScript may block or limit it.
- When capture is incomplete, UXMachine may return a partial structural reading or no result. That is intentional: it withholds recommendations rather than inventing them.
- It does not guarantee business uplift.
- It does not store public diagnosis results.
Evidence, abstention and longitudinal learning
UXMachine does not start every diagnosis from scratch. When a page is diagnosed more than once, each reading is stored as a dated observation, and subsequent readings are compared with that history. This lets the report show what persists, what changed and what still cannot be concluded.
- Observe: capture the current evidence for the page.
- Save: store the reading as a dated observation.
- Compare: contrast the new reading with previous observations of the same page.
- Detect change or persistence: identify what stayed the same and what moved.
- Adjust confidence: use continuity to weigh how strongly a signal is supported.
- Decide or abstain: recommend an action, ask for verification, or withhold a conclusion.
In UXMachine, learning means building longitudinal, per-page memory and using previous observations to interpret how a page evolves. It does not mean retraining the base model, modifying its weights, or deriving global norms from other pages yet.
Current evidence always takes precedence over prior memory. If a new reading contradicts the history, the diagnosis follows what is observable now — the history informs the interpretation, it does not override the present.
Start with one public URL
Run a public diagnosis first. Create an account later if you want future diagnostics to become part of your UX memory.
No account required. Public diagnoses are not saved.