Choose the task before the competitors

Write the question you need to answer in your own product. “Can someone find the return conditions before buying?” is more useful than “Which competitor has the best help centre?” It gives the review a starting point, a stopping point and a reason to exclude irrelevant features.

Baymard describes competitive UX analysis as examining competing products to understand differences and opportunities. Keep that comparison tied to your task. A long inventory of features may tell you what exists without telling you whether any of it belongs in your design.[3]

Choose a small set of products that offer a relevant route through the task. Include a different approach when it helps test an assumption. Explain why each product is included; do not treat a search ranking or visual polish as evidence that its experience works better.

Make the conditions comparable

Use the same task wording, viewport class and access level where possible. Record the date, starting page, signed-in state and any conditions that change what you can see. Stop before a purchase, upload or other consequential action unless you have permission to perform it.

If one product requires an account and another does not, that difference belongs in the record. Do not invent the inaccessible path or score it as a failure merely because you did not inspect it. “Not observed” is a legitimate result.

Nielsen Norman Group distinguishes expert review from competitive usability testing with participants. A reviewer can inspect interfaces and identify questions. Observing how representative people attempt tasks is a different method. Clicking through a competitor yourself does not produce participant task-success data.[1]

Keep a comparison record someone can retrace

Use one record per product and task. Keep facts, interpretations and next steps in separate fields. A screenshot can support an observation about visible content; it cannot establish that customers found the content, understood it or trusted it.

• Task and boundary: what you tried to do, where you started and when you stopped.
• Conditions: date, source URL, viewport, account state and relevant restrictions.
• Observed path: actions taken and the feedback or information encountered.
• Evidence: a source-linked capture or note for each important observation.
• Unknowns: inaccessible states, unanswered questions and untested assumptions.
• Design hypothesis: what you might try in your own product and why.

Worked example: finding a return policy

This comparison is fictional; it does not describe real retailers. In Product A, a returns link appears beside the delivery information on the product page. In Product B, the reviewer reaches returns information through the footer. Both paths end at a policy page. No participants take part, and neither path is timed.

The observation is about where the information appears. It does not show that Product A has higher conversion, that Product B frustrates customers or that either policy is easier to understand. The policy content, audience and surrounding context may differ.

• Observed difference: product-page link versus footer route.
• Unknown: whether people notice either link and understand the conditions.
• Hypothesis for our prototype: place a concise returns link near delivery details.
• Next task to test: ask participants to find the conditions for returning the item before deciding whether to buy.
• Decision after testing: keep, revise or remove the proposed placement based on what participants actually do.

Turn the review into a testable design question

GOV.UK's moderated usability guidance describes watching participants attempt specific tasks. That provides a different kind of evidence from a desk review. Use a task that lets people demonstrate their approach instead of directing them to the control you want them to find.[2]

Before prototyping, write what would change your mind. If people overlook the proposed link, the reference has not settled the placement decision. If they find the link but misunderstand the policy, placement may not be the main problem. The next design action should follow the observation, not loyalty to the competitor example.

Keep the original comparison and its limitations beside the prototype question. A concise annotation can preserve each observation; a design brief can explain which hypothesis you chose to pursue. Neither should turn an untested interpretation into a customer finding.[4][5]