Start with a task you can name

Choose something narrow enough to finish: upload an image, filter a list, or change a delivery address. Write the starting condition and the intended end condition before collecting references. “Upload one supported image from an empty workspace” gives you a boundary. “Research great upload UX” does not.

Keep the page URL, observation date, viewport and input method with the sequence. Record whether you used a signed-out page, your own test account or a public demo. Do not expose another person's files or private account details in the reference. If a state requires access you do not have, leave it unknown.

Use a state checklist as a prompt, not a quota

Not every interface needs every state below. A local preference toggle may have no visible waiting phase; a read-only page may have no submission error. Mark a state “not applicable” only when you can explain why. Mark it “not observed” when you simply could not reach it.

• Starting or empty: What appears before there is content? Is the next action clear?
• Input and selection: What changes when a field, option or item is selected? Record focus separately if you inspect it.
• Waiting: What remains usable while work is in progress? Is the previous result still visible?
• Success: What changed, and what can the person do next?
• No result: How does a completed search with no matches differ from a search still loading?
• Error: What failed, which information remains, and where is the explanation?
• Recovery: Can the person correct input, retry, cancel or return without guessing?

Capture feedback without claiming it is accessible

W3C's status-message guidance distinguishes a short update about an action or result from the result itself. A new list of search results is not, by itself, a status message. A message reporting that the search finished or found no matches can be. Whether assistive technology receives that update depends on implementation, not its appearance.[1]

For form errors, the GOV.UK Design System uses an error summary alongside messages at the affected fields. Its guidance links summary items to the fields and keeps the wording consistent. That is a useful pattern to examine in a reference, not a reason to stamp every form screenshot “accessible”.[2]

Keep separate notes for what you saw and what you tested. “An error appeared above the form” is a visual observation. “The summary link moved focus to the affected field when activated” requires an interaction check. A claim about screen-reader announcements requires an appropriate assistive-technology check. Leave those fields unverified if you only have an image.

Worked example: an image upload

This is a fictional record, not a test of Sesavu or another product. Imagine a page that accepts a single image. Your reference set shows an empty upload area, a visible progress indicator, a completed thumbnail and an error after choosing an unsupported file. The error leaves the filename visible and offers a different-file action.

The useful follow-up is specific: does choosing a different file clear the earlier error, and can that action be reached with a keyboard? The reference does not answer either question. Keep them open rather than drawing a successful recovery screen from memory.

• Task: add one image from an empty workspace.
• Observed sequence: empty → file selected → waiting → thumbnail.
• Observed failure: unsupported-file message with a different-file action.
• Unknown: interruption during upload, retry after a connection failure, keyboard focus and announcement behaviour.
• Design proposal: keep the chosen filename beside a recoverable error; validate that proposal in the prototype.

Stop when the set supports a decision

Before collecting another example, ask which unresolved decision it will help with. You may need a clearer recovery pattern, not another successful thumbnail. Keep a short gap list beside the sequence so a polished reference set cannot hide missing evidence.

For each selected state, attach a precise observation rather than a judgement such as “good UX”. The annotation guide shows how to separate that observation from your proposed design. Keep the original source and capture conditions with the item as well.[3][4]