Page and journey comparisons

Use a Page / journey comparison when you need a like-for-like benchmark between two websites. Target A can be your organisation and Target B a competitor, partner, earlier design, prototype, or another relevant experience. Both targets receive the same task, market, device, viewport, access condition, and safety boundary.

• Choose Single-page comparison when two equivalent pages should answer the same need or support the same decision, such as two pricing, product, service, or campaign pages.
• Choose Journey comparison when a visitor must move through several steps to reach an outcome, such as finding a product, choosing an option, starting checkout, making a booking, or beginning registration.

This is a controlled expert comparison, not a whole-site score or a claim about customer behaviour. It is useful for finding relative strengths, friction, and patterns worth adapting. It is not the right analysis when the decision depends on traffic, conversion, search, heatmap, goal, or time-period evidence.

1. Open the organisation, select Projects, then select Create first project or New project.
2. Choose Page / journey comparison, give the project a durable name, and continue to Set up comparison.
3. Select Single-page comparison or Journey comparison.
4. Enter a clear name and exact Starting page for Target A and Target B. For a journey, use the page where the same task genuinely begins on each website.
5. Write one shared Page review question or Task. Describe the visitor’s intended outcome, not a prescribed sequence of clicks.
6. For a journey, add a Safe stopping point. Make the last permitted step explicit, such as “Stop before payment or placing an order.”
7. Set the shared market or location, device, viewport width, and viewport height.
8. Select Save comparison, review the controlled test on the analysis page, and correct the brief before starting autopilot.

A useful task is specific enough to repeat and open enough to reveal how each interface works. For example: “Find an adult men’s running shoe, choose a size, add it to the bag, and continue towards checkout.” Avoid instructions such as “open the navigation, select Men, then click Running”, because they hide differences in findability and interaction design.

Turn on This comparison requires sign-in when one or both targets need a browser session that is already authenticated. Before desktop testing begins, open every protected target in the same browser profile the desktop agent will control, sign in yourself, and leave the first protected page available.

The desktop agent never requests, receives, stores, or enters credentials. Do not paste a password, recovery code, one-time code, payment detail, authentication secret, or confidential account information into UX Robot, the comparison brief, or the desktop instruction.

If a session is missing or expires, the agent saves the current task, observations, and next step in a checkpoint with waiting_for: target_site_login. UX Robot identifies the affected target and asks the engineer to sign in. After the engineer confirms that the protected page is open, the agent reclaims the same task and resumes from the checkpoint instead of repeating completed work.

Select Start autopilot. When Desktop step ready appears, open the desktop handoff, connect the trusted desktop AI if needed, and copy the run instruction. Treat the temporary connection token like a password.

The comparison creates four bounded desktop tasks:

1. test Target A under the saved brief;
2. test Target B under the same brief;
3. collect equivalent public performance, accessibility, keyboard, focus, label, error, and recovery evidence where it is safely available; and
4. review both experiences against the same Nielsen usability heuristics.

The agent saves a checkpoint after each coherent chunk. If the desktop closes or work is interrupted, copy the same run instruction again: the next claim includes the saved observations and next step.

A comparison uses browser observations, safe reversible interactions, screenshots, public technical checks, accessibility checks, and expert review. It does not collect GA4, Search Console, sitemaps, Microsoft Clarity, organisation goals, or uploaded customer evidence. It does not infer traffic, conversion, abandonment, satisfaction, intent, or population behaviour from a browser test.

The dedicated comparison report follows the same editorial structure as UX Robot’s published comparisons. It includes the method and evidence, shared test brief, 30-second verdict, journey or page at a glance, side-by-side rounds, public performance, accessibility, Nielsen heuristic review, strengths for each target, prioritised changes, limitations, and sources.

Each proposed change separates What, Where, Why, and Measure. Use the side-by-side evidence to understand which pattern better supports the shared task, why it worked in that context, and how your team could adapt the underlying principle. Do not copy a competitor’s design without considering your own users, content, brand, constraints, and technical system.

Check that observations are attached to the correct target, rounds compare equivalent steps, screenshots show the stated interface area, blocked coverage is marked inconclusive, and limitations are prominent. A result describes one controlled test on a particular device, viewport, market, and access state; it does not prove that either organisation’s whole website is better.

When the draft is accurate and useful, approve it as the locked point-in-time report. Use Download PDF or Copy for AI under the same review and data-sharing rules as other UX Robot reports.

Edit the comparison before autopilot starts when a URL, task, stopping point, market, device, viewport, or sign-in requirement is wrong. Do not change the brief while fieldwork is underway: the two targets must keep the same conditions for the evidence to remain comparable.

If a run is interrupted, use the existing desktop handoff and resume from its checkpoint. If a target becomes unavailable, protected access cannot be restored, bot protection prevents a fair test, or equivalent coverage cannot be reached, record that limitation rather than inventing or substituting evidence.

Create a new analysis in the same comparison project when you need to rerun the benchmark after a redesign, fix, competitor change, or materially different brief. This preserves the earlier approved report instead of overwriting the historical result.