Product feedback question bank

Bug reports that can be reproduced

A developer can only fix a bug they can make happen again. The bug report bank is built around the four facts that make that possible: the steps taken, what the person expected to happen, what actually happened, and the environment, such as the device, browser or app version. A screenshot or screen recording is often worth more than a paragraph. The impact on the person comes next, asked as a short choice rather than a free text description, so reports can be sorted. Everything else, such as contact details for follow up, should be optional unless the team will genuinely reply.

Feedback beyond bugs

Not every product problem is a bug. Feature requests, confusing screens and missing options need different questions: what the person was trying to do, how they worked around it, and how often it comes up. Asking about the goal rather than the requested feature matters, because users describe the solution they imagine, and the team may find a better one. Satisfaction and loyalty scores belong in a separate survey sent at a calm moment, not attached to a bug report sent in frustration, where they measure the frustration rather than the product.

Making the answers usable

Use a dropdown or radio list for anything the team will count, such as the area of the product, the platform and the impact, and keep free text for the steps and descriptions. Keep labels in the same words the product uses, so a person reporting a problem with a screen can find that screen's name in the list. Route the responses to where the team already works, and tell the person what will happen next. The bank opens with how many questions to ask and the three never to skip, and links a finished bug report form.

Every page in this collection

• Bug report questions an engineer can work from

  A bug report has to give an engineer enough to make the problem happen again on their own machine, without a single follow up message. These questions separate the goal from the steps and the expectation from the result, so a vague it is broken becomes a ticket someone can pick up.