In short: record a session of your React Native app with the Hallway Test SDK, paste the recording’s link into Claude, Cursor or Codex, and ask for a UX audit. Through the Hallway Test MCP the agent reads the event log, the transcript, frames from the video, errors and network requests, and returns one table of problems sorted by priority, each with timecodes that open the video at that second.
Why the event log matters
A screen video alone is hard for a model to audit. It sees a handful of frames and has to guess what happened between them. A Hallway Test recording carries a stream of timestamped events on the same clock as the video: every tap with the label of the view that was touched, every screen change, every request and every error. That turns “the user seemed stuck” into “the user tapped Pay at 1:12, the request returned 500, and nothing changed on screen until 1:21”.
Spoken comments add the reason. Thinking aloud, saying what you look for and what surprises you, has long been called the most valuable usability method (Nielsen Norman Group). The SDK records the microphone with the screen, so your own words land in the transcript at the right second.
How to run the audit
- Connect Hallway Test to Claude, Cursor or Codex.
- Record a session on a real device. The setup guide covers the SDK.
- Copy the recording’s link from your app’s page under Mobile apps.
- Ask your agent: Audit this Hallway Test recording, followed by the link.
What the agent does
The agent follows the same order every time, and each step has its own MCP tool:
| Step | Tool | What it gives the agent |
|---|---|---|
| 1 | mobile_get_details |
Device, app version, duration, crash, whether video and voice exist, the viewer link and the required audit format |
| 2 | mobile_get_user_events |
Taps, swipes, text input, screens and navigation, each at its second in the video |
| 3 | mobile_get_video_transcript |
What was said, timed to the video, when the microphone was on |
| 4 | mobile_get_frames |
Screenshots at the seconds the events point to |
| 5 | mobile_get_errors |
JavaScript errors, native crashes and frozen screens |
| 6 | mobile_get_network_requests, mobile_get_console_logs |
The technical cause behind a problem already seen in the events |
Events come first because they are the evidence. Frames confirm what was on screen, and errors and network requests explain why, but they never create a finding on their own.
What you get back
One Markdown table in your language, sorted High, then Medium, then Low:
| Column | What it holds |
|---|---|
| # | The row number |
| Priority | High, Medium or Low |
| Problem | What went wrong, with the concrete values seen |
| Timecodes | Every moment that proves the row, each a link that opens the video at that second |
| Recommendation | One concrete change, or what to check first when the cause is unknown |
| How to verify | An observable check that the fix worked |
A problem without a moment to link to is left out. After the table the agent may add up to two sentences naming rows that rest on an assumption. It recommends changes and does not edit your code unless you ask it to. An example table is on the mobile app recordings page.
Patterns the audit looks for
- Hesitation: a long gap between events on a screen that should take a second.
- Wrong turns: back navigation, a screen opened twice, a modal closed without action.
- Dead and repeated taps: taps on something that is not a control, or three taps on one button.
- Silent failures: a spinner that never ends or a submit that does nothing, traced to a failed request.
- Crashes and freezes: native crashes, JavaScript errors and a blocked main thread, at the second they happened.
When to use a real tester instead
Your own recording shows how you use the app, and you already know it. To learn whether someone who has never seen it can finish a flow, send the same app to one of our in-house testers as a usability test. The recording comes back in the same format, and your agent audits it the same way.