How to ask for useful feedback and analyse responses

To ask for useful feedback, show a specific piece of work to someone with relevant experience and ask about using it. Separate observations from suggested solutions, compare the responses and decide what to test. A question about the step where someone got stuck is easier to act on than “What do you think?”

Define the decision you need to make

Imagine writing a guide for new colleagues. You want to know whether they can use it to submit their first report independently. Your immediate question concerns the actions in the guide. A review of the writing style or illustrations may be useful later, but it answers a different question.

Identify the version, the task and when you would like a response. Ask whether the person has time to help. Avoid sending a long document with a request to “quickly check everything.” For a brief review, select one part and explain roughly how much time you expect the task to take.

Choose people with relevant, different perspectives

A newcomer can show what is unclear without prior knowledge. An experienced colleague can check whether the process itself contains an error. A manager may clarify mandatory requirements. Each response contributes something different, so keep a note of its context.

If you ask only friends or the most active users, other experiences will be missing. A few responses can reveal questions worth investigating, but they cannot establish how common a problem is across your whole audience. That requires a separate approach to gathering evidence.

Ask about a concrete experience

The GOV.UK guide to interviews recommends open, neutral questions and real examples. You can apply that principle to a small review of your guide: establish what happened before discussing a possible change.

A request could read: “I'm checking this guide before we give it to new colleagues. Could you try the first three steps and note where you needed help? Examples of difficulties would be useful; we are not reviewing the visual design yet.” If you want to record a conversation, agree that first and explain who will have access.

Keep the observation separate from your conclusion

Record the response accurately and place your interpretation alongside it. “The person searched for the recipient's address at step two” is an observation. “The address is not visible enough” is a possible explanation. “Put the address directly in that step” is a proposed change. The GOV.UK analysis guide also separates observations, findings and subsequent actions.

Group similar difficulties while preserving differences between participants. Three accounts of the same incident are not three independent tests. A single observation can still matter: a problem that makes the guide unusable for some colleagues deserves investigation even if it has only been reported once.

Do not promise anonymity if the situation makes someone identifiable within a small team. Remove unnecessary names and details from the shared summary. Publishing a named testimonial is a separate use of someone's comments and should be agreed with them.

For a joint review of completed work, use the retrospective question collection. Select prompts for the situation and connect answers to observations that can be discussed and checked.

Test a change and close the loop

In this example, you add the recipient's address and ask another newcomer to complete the same step. The check is whether they can submit the report without searching the team chat for an address. If the difficulty remains, identify where the next question arises.

Tell the participants what changed and what you have left as it was. Use the feedback-to-action template to turn the selected improvement into a task. If you disagree with a suggestion, follow the process for evaluating disputed feedback: explain your reason and the evidence that would make you reconsider.