How to annotate screenshots for heuristic evaluation reports

Annotated screenshots give a heuristic evaluation report its evidence. A raw capture shows what a screen looked like; numbered callouts, arrows and short notes show why an interface creates friction and which usability heuristic is involved. The result is easier for teams to scan than a narrative that describes problems without visual proof. Learn more about Usability Testing For Users With Disabilities A Practical Guide.html.

Good annotation is disciplined rather than decorative. Capture the states needed to understand each task, link every marker to a written finding, and keep judgements proportional to the evidence. The workflow suits solo reviews and distributed teams in Sydney, Melbourne, Brisbane and smaller centres, as well as international product teams.

Prepare the screenshot set

Start with the flows you are evaluating, not every page. Capture the entry point, the normal completion path, and any state where an error, warning or permission request appears. Use a consistent browser width, zoom level and image size for reviewers to compare components without mistaking a layout change for a flaw.

Record the viewport, device and capture date in the issue log. Australian teams often use the day-month-year format, so write 04/07/2026 as 4 July 2026. For a seasonal example, note whether the screen was checked before or after Australia Day, and retain the matching offer version.

Keep filenames predictable: flow, screen, state and version. Organising personas, use cases and findings alongside captures in the UCDmanager platform gives the report a traceable source rather than a folder of disconnected images.

Choose a consistent annotation style

Number each marker in reading order and place it beside the relevant element. A short title such as “Unclear primary action” beats a long sentence inside the image. Use arrows or thin boxes for location, then repeat the explanation in the issue log. This keeps the screenshot readable on a laptop in Melbourne or a phone in Perth.

Use colour as support, never as the only signal. Red can signal a problem, but a numbered badge or icon should also carry the meaning for reviewers with colour-vision deficiencies or greyscale printing. Match marker colours to the written severity categories and include a legend.

Decide whether the image records an observation or presents a proposed redesign. Resist placing mock controls over the original interface unless the new version is labelled as a suggestion. For synthetic test material, borrow only the structure of a bonus code example, using fictional branding and no live promotion. Assess whether urgency and promotional wording compete with the primary task.

Make annotations accessible and inclusive

The annotated image needs the same accessibility expectations as the interface under review. Give every screenshot meaningful alternative text, then provide the full finding in nearby text. Do not bury crucial information in tiny callouts, and avoid an image of text where selectable text would be easier to read with a screen reader.

Check contrast between annotations and the underlying interface, and keep labels legible when the report is enlarged. If an arrow crosses a form label, reposition it. When an error message is too small to evaluate, include a readable transcription below the image instead of enlarging one region at the expense of the rest.

Inclusive annotation means describing consequences accurately. A field that is difficult to complete may create a greater barrier for a user with a motor or cognitive disability than the visual defect suggests. Accessible usability testing complements expert review, particularly for Australian Government services required to meet WCAG 2.2 AA.

Rate issues using the visible evidence

Assign severity from impact, frequency and persistence, not from how untidy the screenshot looks. A minor issue might be an inconsistent button style. A critical issue could prevent a customer from completing a purchase or interpreting a mandatory consent request. State the affected user, task and consequence so another reviewer can challenge the rating.

Tie each annotation to a recognised heuristic where possible: visibility of system status, match with the real world, user control, consistency, error prevention or recognition rather than recall. For a checkout, show an Australian dollar total with 10% GST identified and an Australia Post delivery option with an unambiguous postcode. Describe whether the failure is confusing, missing, delayed or unavailable.

Use severity categories that suit the organisation, but define them in the report. Include representative evidence and note whether a problem was reproduced across several sessions or inferred from a single state. Avoid inflating priority from visual prominence; the most conspicuous defect is not automatically the most consequential.

Redact sensitive information before sharing

Remove personal data before adding annotations. Blur names, email addresses, order numbers, access tokens and precise location details, replacing them with neutral placeholders that retain the layout. Australian contact examples distinguish 1300 numbers from geographic 02 and 07 prefixes, so redact business numbers too when the screenshot is not needed for the finding.

Cropping alone may not be sufficient. Check exported images for hidden metadata and the wider page for information revealed by a partially visible menu or notification. Apply the same redaction rules to thumbnails and attachments. For research involving health, financial services or children, use synthetic data where possible and follow the consent terms agreed with participants.

Assemble a report that drives remediation

Pair each image with a compact finding: identifier, screen, annotation, heuristic, severity, affected task and recommended action. An issue list can carry these details while screenshots demonstrate the context. This keeps visual evidence clear and makes it possible to filter findings for an owner, such as the checkout, content or accessibility team.

Include the evaluated flows, review scope and limits. A screenshot proves that a state was observed; it does not prove how often users encounter it. Separate direct observations from assumptions, and flag areas needing further research. For a larger evaluation, link the report back to relevant project records instead of duplicating every note.

When findings will also become a public case study, publishing guidance can help adapt the material for a non-specialist audience. Keep the original annotations intact, explain abbreviations such as WCAG, and present recommendations in plain Australian English. A completed report lets a product owner identify the problem, understand its impact and locate the component needing attention without reconstructing the review.