# TagTrack — Proposed usability session guide

Status: research plan, not completed research. Prepared 12 October 2026.

## Question

Does a dedicated review step help an equipment coordinator notice wrong-asset or wrong-recipient details without adding unnecessary friction?

## Participants and setup

Recruit people who actually coordinate or borrow shared equipment. Include varied mobile familiarity and, where possible, participants who use assistive technology. Agree participant consent and recording arrangements before sessions. Use fictional names and records only; do not collect real company inventory.

Prepare both the existing Flutter flow and this prototype on comparable devices. Alternate which interface is shown first to reduce order effects. The prototype has simulated camera/save behavior; compare equivalent manual-lookup tasks rather than treating it as a camera-performance test.

## Tasks (read the goal, not the button names)

1. You need the Sony Alpha camera for Alex in Production. Find the asset and record who receives it.
2. Before confirming, you realize the receiving person should be Sam. Correct the handoff without creating two assignments.
3. You have a printed asset code, but the camera is unavailable. Find TG-002. Try an unknown code first and explain what you would do next.
4. The camera is being returned. Check who had it, record the return and verify what changed.
5. A save fails during a handoff. Recover while keeping the correct asset and recipient. Explain whether you believe a change was saved.
6. Find an item in maintenance and explain whether you would hand it out.

Use the prototype's scenario controls only to set up the condition; do not present those controls as normal product features. Avoid coaching unless a participant is stuck; record assistance explicitly.

## Observe

- Can the participant identify the asset, its availability and recipient correctly?
- Do they notice an intentionally incorrect recipient before confirming?
- Where do they hesitate, backtrack or seek help?
- Does an error message communicate whether a change happened?
- Does manual lookup remain discoverable without the camera?
- Can the participant distinguish a session log from shared or permanent storage?
- Does the additional review step feel useful, redundant or unclear, and why?

## Record without inventing outcomes

For each task, record completion, assistance, critical errors, observations and optional elapsed time. Separate design problems from prototype limitations. Use a participant code, not identifying information. There is no numeric success target or claimed baseline yet.

## Decision after the sessions

Compare qualitative evidence and critical errors across the two flows. Keep, simplify or remove the extra review step based on the observed trade-off. A small formative study can identify problems; it should not be reported as proof of a population-wide conversion or speed improvement.

## Accessibility follow-up

Check full keyboard navigation, zoom/reflow, screen-reader labels and announcements, and native Flutter semantics separately. Include real-device camera-permission and persistence-failure tests before implementing a production redesign.