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

• App feedback questions to ask before the store prompt

  App feedback questions asked inside the app catch problems while the user can still be helped, before they become a one star review. These twenty two questions cover the overall rating, what people use the app for, crashes and speed, what is missing and the device, so a bug report and a feature request never land in the same box.

• Beta feedback questions that sort bugs, gaps and keepers

  Beta feedback has three jobs: find the bugs, find what is missing, and find out which new features are worth keeping. These twenty two questions keep those apart, with a structured bug report, a feature rating grid and a direct keep or cut question for each new feature.

• 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.

• Concept testing survey questions from appeal to intent

  Concept testing survey questions measure how people react to an idea before it is built: whether it appeals, whether it feels new, whether the claims are believable, what they would pay and whether they would buy. These twenty two questions follow that order, with screening first so the reactions come from the right people.

• Customer interview questions for discovery calls

  Customer interview questions for discovery should ask about what people did recently, not what they would do in the future, because past behaviour is the best evidence of a real problem. These twenty three questions run in five stages and are captured by the interviewer in a form, so every call produces notes in the same shape.

• Design feedback questions for a mockup review

  Design feedback questions should ask what a person noticed and understood, not whether they like the colours, because those answers can be acted on. These twenty one questions start with a first impression taken before anything else is asked, then test clarity, hierarchy and what people would click, and end with a preference between options.

• Pricing survey questions including the Van Westendorp four

  Pricing survey questions ask what people spend now, what they would consider too cheap and too expensive, which plan they would choose and which features they would pay for. These twenty questions centre on the four Van Westendorp price sensitivity questions, asked in a fixed order after people know what the product does.

• Product feedback survey questions for in app and email

  A product feedback survey asks how satisfied users are, which features they use and how important each one is, what is missing, how easy the product is and whether it is good value. These twenty two questions work in an in app prompt or an email, with the role question near the end so answers can be split by user type.

• Usability testing questions before, during and after each task

  Usability testing questions come in three kinds: a screener before the session, short questions after each task, and wrap up questions at the end. These twenty two are written for a moderator to fill in as the session runs, so every participant is asked the same things in the same order.