✦ Task type · Website testing
Cross-browser checks on machines that belong to people
A screenshot grid renders your site on clean machines. Almost nobody browses on a clean machine, and the difference is where the reports come from.
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.
Common questions
Does this replace a rendering service?
No, it complements one. Automated grids are better at breadth, consistency and catching regressions on every deploy. What they cannot reproduce is a real profile: content blockers, privacy settings, a system font stack, a browser two versions behind because updates are managed by an employer.
Which browsers actually matter?
Your analytics know. If you have none, Safari on iPhone is where most real-world surprises live, followed by whatever your audience's employer standardises on. Chrome on a current desktop is the configuration least likely to hold a surprise.
What reward is fair?
Six to fourteen dollars per browser for a walk through a few pages with screenshots. Keep each campaign to one browser so the results are comparable.
What about content blockers?
Ask about them rather than around them. A significant share of visitors run one, and the interesting failures are the elements that quietly disappear when a blocker matches a class name that was never meant as an advert.
Thinking of taking this task?
The same job, from the other side. Rewards are set by the poster, so treat these as the range this task type usually sits in rather than a promise.
- Usually pays
- $6 to $14 per browser
- You need
- A real device with the named browser
- Proof expected
- Screenshots per page plus your full browser and OS version
Leave your setup exactly as it is. Extensions on, settings untouched: the unprepared machine is precisely what the poster is paying for.
Create a worker accountCheck your browsers
Set the reward and the browsers you need covered. Workers reserve a spot; the URL stays private until they do.
Post this task