For the teams that run client software
Feedback from the people using the build, with the context attached.
Shutterbug sits in your dev, demo and preview environments. A client points at what is wrong and writes a line. You get the route, the build, the failing request, the console and a masked screenshot in your backlog, ready for a developer or their agent.
What a report carries
Everything the developer would have asked for, attached before anyone asks.
- 01screenshot, masked in the browser
- 02the picked element, outlined
- 03a line from the reporter, optional
- 04one press
- 05route
- 06build sha, dirty or not
- 07the failing request, with its body
- 08console errors
- 09browser and viewport
Even chatting may be a step too far.
From the brief. The widget is a camera, not a chatbot.
One press replaces the call, the screenshot and the paragraph explaining it.
- 01 · Capture
Your client presses the mark inside the build, points at the thing, writes a line. The widget attaches the route, the build, the failing request, the console and a masked screenshot before anyone asks.
- 02 · Backlog
Every report lands on one board as a receipt: what was said, what was shown, what the browser was doing. Mark it planned, in progress, shipped or closed. The client sees it move.
- 03 · Tackle
Developers, or their agents, pull the report with the whole picture attached and update the board when the change ships. No transcribing a call, no chasing a screenshot in Slack.
For software services businesses.
Put it on every client environment you run. Feedback arrives as evidence rather than a recollection, the client can see what they have already raised, and the board is the changelog you were going to write anyway.
For the developers on the account.
A report is the whole picture: the picked element, the request that failed, the console at the time, the build it happened on. Pull it into your editor or hand it to an agent, then mark it shipped from where you are.