TV interfaces fail in a way no other platform does: the user knows what they want, can see it on screen, and cannot work out which sequence of directional presses will reach it.
What to put in the public brief
- The TV platform, named exactly
- That a physical device is required, not an emulator
- How they will get the build
- That a video of the screen is required
- Roughly how long
Keep the app identity, build and credentials private.
What to put in the private instructions
Give a goal reachable only by navigating
"Start playing the third item in the second row." A goal that can be reached by pressing OK twice tests nothing about the layout.
Ask them to film the remote as well as the screen
The hand hesitating over a direction is the finding, and it does not appear in a screen capture even where one is possible.
Ask about the back button explicitly
Back behaviour is the single most common TV app defect and the most platform-specific. Ask where it took them and where they expected to go.
Ask them to sit where they normally sit
Not close to the screen to read it better. If text is unreadable from the sofa it is unreadable, and a tester leaning in has removed the problem you are paying to find.
Proof worth requiring
Ask for
Video of the screen with the remote visible, the exact device and platform version, and where they got stuck.
Do not ask for
Screenshots. A TV navigation problem is a sequence, and single frames cannot show a sequence.
When this task type is the wrong tool
If the app is not yet installable on retail hardware, this cannot run — the constraint is the device, not the tester.
If your problem is content discovery rather than navigation, that is a catalogue and metadata question, and a findability test on the web version will answer it more cheaply.