What information should a client include in a bug report?

Four things: the page or screen where the issue appeared, the steps they took (what they clicked or typed), what they expected to happen, and what actually happened instead. Browser and device are useful but most clients can't reliably provide the technical details — a screenshot of the full browser window often captures that for you.

How do I get clients to describe bugs clearly instead of saying 'it's broken'?

Give them the structure before they start testing: ask for page, action, expected result, actual result. Frame it as "the faster you give me this, the faster I fix it" — most clients respond well to that incentive. A review link where they click the element they mean also forces precision: clicking a specific button is more accurate than describing it in email.

Do clients need to install anything to report bugs?

They shouldn't have to. Tools that require a browser extension or a login account get skipped — clients report fewer bugs and the ones that come through arrive over email instead, where they're harder to track. The lowest-friction approach is a link they open in any browser and click on the issue.

What is the difference between client feedback and a bug report?

Feedback is a preference or a direction change — 'the hero feels too dark', 'can we try a different font'. A bug report is a defect: the site or app does something it shouldn't, or fails to do something it should. Both matter, but they go in different buckets. Acting on a preference as if it's a bug (or ignoring a bug as if it's a preference) is where revision rounds spiral.

How do I collect bug reports from multiple stakeholders without losing track?

Funnel everything through one channel and make that explicit before testing starts. When two people on the client's team report the same bug independently through different channels, you risk fixing it twice — or missing that one of them added context the other didn't. One review link or one shared board means every report is visible to everyone, and duplicates are obvious.

How do I handle a bug report I can't reproduce?

Reply immediately asking for one more detail — a screen recording, their device model, or confirmation of which step triggers it. Don't mark it resolved or dismiss it. Bugs that are hard to reproduce are often account-specific or device-specific; your client's environment is the one that matters, not your local build. A 30-second Loom from them is often faster than a five-message thread trying to reconstruct what they saw.

drafty

How to collect bug reports from clients

Quick answer

To collect useful bug reports from clients, give them a single place to report issues (not email), ask for three things on every report — what they did, what they expected, and what actually happened — and capture the URL and device automatically so you're not chasing context. The more friction you add, the fewer bugs they'll report, and the ones that get through will be missing the reproduction steps you need.

Step 1

Tell them exactly what a good bug report includes

Clients aren't testers. Without guidance you get "the checkout is broken" — no page, no browser, no steps. Before the project goes for review, share a one-paragraph briefing: every bug report should include what page they were on, what they clicked, what they expected, and what happened instead. The four-part structure turns "it's not working" into something reproducible in 90 seconds. Frame it as "makes fixing faster" rather than "I need more info" and most clients follow it.

Step 2

Make reporting one click on the actual page

A form your client has to find and open separately gets skipped. Put reporting on the page itself — a widget that captures the URL and screenshot automatically, or a review link where they click the broken element and pin a note right to it. The second approach has a useful side effect: the note is anchored to the exact button or field they mean, so "the contact form" isn't ambiguous when the page has three forms. Clicking the thing beats typing a description of a thing you clicked five minutes ago.

Step 3

Capture the environment without asking for it

Browser, OS, and screen size account for most hard-to-reproduce bugs, but clients can't reliably report what version of Safari they're on. Tools that auto-capture metadata on submission skip the technical interview. If you're going manual, ask for a screenshot as a minimum — it reveals browser, viewport, and UI state more reliably than asking for a description. One thing most people get wrong: a screenshot of the error message alone is less useful than the whole browser window — the URL bar tells you which page and which state.

Step 4

Funnel everything into one thread, not email

Bug reports arriving over email, WhatsApp, and a Tuesday call are the same as no bug reports — you'll miss one, fix the wrong thing, or ship a version that closes the email bug and misses the call bug. Name one channel before you send anything for review. A Notion doc, a Jira board, a review tool where they comment in place — pick one and tell the client that anything sent outside it may not get actioned this round. The real cost of scattered reports isn't the tracking overhead: it's the revision that fixed the wrong bug because you reconstructed it from a vague message.

Step 5

Reproduce the bug before you fix it

Try to reproduce the bug before you write a line of code. If you can't in two attempts, ask for one more detail: a screen recording, a different network, a second device. A bug you can't reproduce is a bug you'll half-fix. Don't dismiss a reported issue as user error just because it passed your own test — clients find device-specific and account-specific edge cases your local environment doesn't hit. "Works on my machine" closes real bugs; asking for their device in a follow-up reopens them correctly.

The faster way

If you're building for a client in Figma, v0, or a hand-coded site, you can drop the whole thing into Drafty and share a link. Your client opens it in any browser — no account — clicks the broken element, and leaves a pinned comment right on it. The URL, element, and their note land in one thread. You reply, push a fix on the same link, and mark it resolved. No email trail, no "which form did you mean", no lost reports. Works for live sites, Figma exports, PDFs, and anything you can share as a URL.

Open a live demo

Questions

What information should a client include in a bug report?: Four things: the page or screen where the issue appeared, the steps they took (what they clicked or typed), what they expected to happen, and what actually happened instead. Browser and device are useful but most clients can't reliably provide the technical details — a screenshot of the full browser window often captures that for you.
How do I get clients to describe bugs clearly instead of saying 'it's broken'?: Give them the structure before they start testing: ask for page, action, expected result, actual result. Frame it as "the faster you give me this, the faster I fix it" — most clients respond well to that incentive. A review link where they click the element they mean also forces precision: clicking a specific button is more accurate than describing it in email.
Do clients need to install anything to report bugs?: They shouldn't have to. Tools that require a browser extension or a login account get skipped — clients report fewer bugs and the ones that come through arrive over email instead, where they're harder to track. The lowest-friction approach is a link they open in any browser and click on the issue.
What is the difference between client feedback and a bug report?: Feedback is a preference or a direction change — 'the hero feels too dark', 'can we try a different font'. A bug report is a defect: the site or app does something it shouldn't, or fails to do something it should. Both matter, but they go in different buckets. Acting on a preference as if it's a bug (or ignoring a bug as if it's a preference) is where revision rounds spiral.
How do I collect bug reports from multiple stakeholders without losing track?: Funnel everything through one channel and make that explicit before testing starts. When two people on the client's team report the same bug independently through different channels, you risk fixing it twice — or missing that one of them added context the other didn't. One review link or one shared board means every report is visible to everyone, and duplicates are obvious.
How do I handle a bug report I can't reproduce?: Reply immediately asking for one more detail — a screen recording, their device model, or confirmation of which step triggers it. Don't mark it resolved or dismiss it. Bugs that are hard to reproduce are often account-specific or device-specific; your client's environment is the one that matters, not your local build. A 30-second Loom from them is often faster than a five-message thread trying to reconstruct what they saw.

Keep exploring

How to collect client feedback BugHerd alternative Review a website

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo