The value here is specifically that the machine is not yours and was not prepared for the test. Everything a rendering grid controls for is the thing you want to observe.
What to put in the public brief
- The browser and operating system, named exactly
- That a real device is required, not an emulator
- That screenshots are needed
- Roughly how many pages
- That extensions and settings should be left as they are
Keep the URL private.
What to put in the private instructions
Name the pages and what should appear on each
So a missing element is reported rather than assumed to be the design.
Say to leave their setup alone
Do not disable extensions, do not switch to a private window unless asked, do not change the font size. The unprepared profile is the instrument.
Ask what they are running
Browser version, operating system, any content blocker, and whether text is scaled. This is the metadata that turns one report into a reproducible one.
Ask about interaction, not just appearance
Whether menus opened, whether forms accepted input, whether anything needed a second tap. Screenshots hide all of that.
Proof worth requiring
Ask for
Screenshots per page, the full browser and OS version, any extensions, and one line per page on whether anything behaved oddly.
Do not ask for
A console log or a network trace. You are buying an ordinary person's browser, and requesting developer output selects for people whose setup is no longer ordinary.
When this task type is the wrong tool
If you need every commit checked, use an automated grid. Running this on each deploy would be slow and expensive and would still miss regressions between campaigns.
If the layout is fine everywhere and people still cannot complete a task, that is a findability or checkout problem rather than a rendering one.