Generate, review, and share reports

Open the journey analysis and select Start autopilot. UX Robot first collects the connected GA4 and Search Console reports for the saved evidence period. Starting a journey holds one analysis unit for it, so the billing owner needs one available unit to start.

Before starting, confirm:

• the organisation profile, goals and stakeholders are current;
• the journey brief describes the visitor, the task, what success means, and a safe stopping point;
• the correct GA4 property is connected, and Search Console if you use it;
• whether this website has Microsoft Clarity heatmaps and, if it does, which project contains them;
• if the journey has a step your team completes, such as signing up or signing in, someone is at the computer to do it when the agent asks, with the test account ready; and
• the billing owner has one available analysis unit for this journey.

1. Select Start autopilot. The evidence checkpoint asks whether heatmaps are available. Answer yes to add Microsoft Clarity collection to this journey, or no to continue without it. The page then shows a generic progress stage while server evidence is collected and the journey test is planned. During a long task, Still working, elapsed time, and the last saved activity time continue to update even when the evidence percentage cannot move.
2. When the journey needs your agent, the Your turn window opens by itself with one short instruction, and stays until your agent starts; you can also select Get the instruction at any time. Your agent is the AI app on your computer, such as Claude or Codex. If it is not connected yet, the window’s first step opens Settings → Desktop connections: add UX Robot to Claude or Codex as the page shows, sign in to UX Robot when the app asks, and set UX Robot’s tools to Always allow so your agent does not stop at every step. You do this once.
3. Start a new chat in your agent, choose one of the recommended models, and paste the instruction. Your agent tests the journey in its own browser, performs safe interaction and usability checks, and saves its place after each step. When heatmaps were selected, it also gathers the relevant Microsoft Clarity evidence. It captures screenshots for each meaningful journey stage, useful patterns, and interface failures; it does not capture Clarity or analytics dashboards.
4. When it needs you, such as for your team’s step, signing in to the website or signing in to Clarity, your agent asks in its chat and the Your turn window shows the same request. Do it in the browser your agent uses, then tell your agent in its chat that it is done. It never asks for or types passwords, codes or personal details.
5. If the chat closes or the computer sleeps, paste the same instruction into a new chat. Your agent carries on from where it saved its place instead of repeating finished work.
6. After the evidence set is complete, UX Robot starts the powerful server-side report model with the journey’s unit. Your agent gathers and records the evidence; it does not write the final report.
7. The unit is used once a valid structured report is stored. If generation fails, the collected evidence remains safe, Retry report preparation becomes available, and the journey keeps its unit so the retry uses no other.

You do not need to keep the UX Robot page open. Server collection and report generation continue in the background. Your agent’s chat needs to stay open while it carries out the journey and, when selected, the behaviour-evidence step. UX Robot emails both the person who started the run and the organisation owner when report generation finishes, with a link straight to the report. When the same person is both, only one email is sent. If generation fails, that email explains what went wrong and confirms that no analysis unit was used.

To end a journey before its report is written, select Stop this journey under the progress stages and confirm. Your agent can no longer pick up its tasks. If UX Robot has already planned the journey’s test, stopping it uses the journey’s unit, because that work was done; otherwise the unit is returned. A journey with no activity for 7 days is stopped in the same way. To test it again, select Start the journey again, which holds a new unit. A journey cannot be stopped while its report is being written.

A journey report whose priorities recommend visible changes adds one more step for your agent after the report is written, which shows each fix to what is already on your page as exact wording or a mock-up. The analysis page shows Make the after pictures. If your agent’s chat is still open, it carries on by itself; otherwise select Get the instruction and paste it into a new chat, or select Skip after pictures. The draft report can be read in the meantime, and approval waits until the step is finished or skipped. See Journey analyses for the full journey method.

When processing completes, select Read report to open the dedicated reading view. Start with the 30-second assessment, then the evidence-informed journey map, the stages, and the priorities. Each priority says what to change, where, why, and how you will know it worked, and is labelled Measured or Observed only so you can see which ones your evidence backs.

Every analysis row, analysis page, journey report, and stakeholder summary shows Created and Last run. These timestamps use the timezone saved in the organisation profile and include its current timezone abbreviation. Last run means when the latest full autopilot run started. An analysis that has never run says Not run yet.

The Performance chapter keeps real-user Chrome UX Report results separate from simulated Lighthouse diagnostics and shows unavailable or failed checks instead of hiding them. Readiness says whether the evidence can support a decision; it measures evidence completeness, not whether visitors succeed.

Every organisation is paired with a dedicated UX Robot engineer who can learn its goals, website, evidence history, and previous decisions. If you do not have an internal UX team, the engineer can help explain findings, prioritise work, run workshops, review proposed changes, and check whether completed work improved the experience. If you already have a UX, product, design, or digital team, the engineer can add focused capacity where it is most useful.

The report speaks to the website owner in plain, constructive language. Each explanation should stand on its own without requiring you to understand how UX Robot collected the evidence. Strengths show what to build on, findings explain the opportunity they create, and recommendations give an achievable next step without hype or unsupported promises.

Screenshots show the exact tested viewport with the affected control outlined. The highlight comes from the element bounds recorded in the same browser state, not from a later AI guess, and UX Robot keeps the untouched source image separately. Screens containing personal, authentication, payment, confidential, or signed-in third-party information are not captured; the agent must save that exception explicitly, and the report identifies the page area in words.

• Trace important claims back to GA4, Search Console, Clarity, browser observations, or known context.
• Check that each source keeps its proper role: search demand, on-site behaviour, and interaction evidence are related without claiming that one caused the other.
• Check that a priority labelled Measured really cites a measure, and that the figures describe the journey’s pages.
• Check that missing evidence is identified as a limitation instead of being replaced with assumptions.
• Look for unsupported certainty, invented facts or misleading causation.
• Confirm that personal or sensitive information has not been unnecessarily reproduced.
• Open each highlighted location and confirm that the outline identifies the issue described by the finding.
• Check that priority and effort are practical for the organisation.

If the draft is not ready, correct the brief and run it again only when a new full generation is justified. AI can make mistakes; human review remains required.

Select Approve and save report when the current result is the version the organisation should retain as its historical record.

1. Confirm the analysis, readiness information, and generated report. On a journey report, select Dismiss on any priority or fix-list issue that does not apply; it leaves the report and becomes a dismissed issue when you approve.
2. Select Approve report and read the permanent-lock warning.
3. Select Approve and save report to create the approved snapshot.

When UX Robot holds a draft back, the analysis page and the report show Needs attention with the reasons the report gave, such as a priority without a screenshot. Approval and export stay off until a report is ready. If the journey fieldwork itself was incomplete, the analysis page offers Retry journey fieldwork; otherwise the fieldwork is kept and the reasons say what is missing.

Approval is permanent for that analysis. The analysis becomes locked: its brief and evidence cannot be edited, and the report cannot be rerun. Approval turns each priority into a numbered issue you can send to your ticket tool, and starts writing the stakeholder summary. When you have shipped changes, select Run this journey again to test the journey with a new analysis that checks every open issue.

Download PDF and Copy for AI are available on every finalised report. They are also available on a completed draft that can be approved: marked ready, with finding-specific screenshots, and a readiness score strictly greater than 60%. A score of exactly 60% does not qualify.

• Download PDF creates a print-ready report in the same design as the report on the website, with its fonts, its dark 30-second assessment panel, before and after pictures side by side and Lighthouse scores as coloured bars. The document is prominently labelled Draft or Finalised, and a finalised export always uses the approved, locked snapshot.
• Copy for AI copies the complete structured report together with instructions for the receiving AI. Paste it into the AI tool your organisation permits.

The copied prompt tells the AI to work only from the supplied report, keep each source in its role, avoid outside knowledge, start from the 30-second assessment and the journey map, keep the What, Where, Why and Measure handoff, and never present a draft as approved. You can follow it with a narrower request, such as drafting a meeting brief, creating implementation tickets, or extracting acceptance criteria and success measures. The same evidence rules still apply.

Stakeholder delivery is available after the journey report is approved. Approval starts writing a shorter summary of the approved report for decision-makers.

1. Open the approved analysis. The Stakeholders section shows when the summary is ready; if it failed, select Retry stakeholder report.
2. Select Review stakeholder summary and check it for clarity, accuracy, and appropriate language.
3. Return to the organisation’s Stakeholders section and confirm each intended recipient has a correct email and is marked to receive reports.
4. Select Send stakeholder emails, review the recipient count, and confirm Send emails.

The summary keeps the journey report’s evidence basis: it says plainly whether each problem is measured in your evidence or observed in the browser only, and it shows representative screenshots from the journey’s stages.

Each selected stakeholder receives an editorial email with the report brief, confidence, up to three priority issues, up to three recommended actions, and private links to the stakeholder summary and full approved report. Recipients should not forward those links outside the authorised audience. Sending is queued, so delivery may not be instantaneous.