A team wants to improve an internal service: booking equipment, requesting design help, or finding a shared document. Someone suggests a survey because it can reach many colleagues. Someone else prefers interviews because the problem seems complicated. The method should follow the uncertainty the team needs to resolve.
A survey can collect answers to consistent questions across respondents. An interview can explore what a person means, what happened in a specific case, and what the researcher did not know to ask. Neither automatically produces a representative picture, and neither turns preferences into proof that a proposed change will work.
This comparison focuses on improving an ordinary internal work process. It is not a guide to investigating personnel complaints, collecting health information, or evaluating individual employees. Those activities have different purposes and should use the organization's appropriate professional processes.
Name the decision before writing questions
“Find out what people think” is too broad to determine a useful method. Try a question that could lead to an actual decision. For an equipment-request service, the team might need to know why requests arrive incomplete, which part of the process people find difficult, or whether a proposed change makes the request easier to complete.
Those questions require different evidence. To understand why a field is misunderstood, talking through a recent attempt can help. To measure how respondents rate a clearly defined step, a consistent survey question may be useful. To find out whether people can complete a revised form, watching them try it may be more informative than asking whether they like its appearance.
GOV.UK's research-planning guidance starts with research questions and the groups whose experiences matter. Apply that discipline before choosing a form builder or booking interviews. The team should be able to explain what it would do differently after learning the answer.
What a survey makes comparable
The strength of a structured survey is that respondents receive a consistent set of questions and response options. That can make it easier to summarize answers and compare defined groups or occasions, provided the design and participation support the comparison. A tidy chart is not enough on its own.
Suppose a question asks, “How easy was it to submit your most recent equipment request?” The answer concerns submission. It does not necessarily describe whether the requested equipment arrived, whether it worked, or whether someone helped the requester complete the form. A question about the whole service would need a different scope.
Also identify who received the survey. If the invitation appears only after a successful submission, people who abandoned the form may be missing. If it goes only to a chat group, staff outside that group may never see it. If participation is voluntary, the respondents may differ from people who did not answer. Report those boundaries with the results.
For a small internal exercise, there may be no need to claim statistical representativeness at all. “These are the responses received from colleagues who used this route during the stated period” can be an honest and useful description. Do not attach a general margin of error or claim that a percentage represents the whole organization without an appropriate sampling and analysis basis.
What an interview can reveal
An interview lets the researcher ask someone to describe a real recent experience and follow up on unclear points. “I couldn't finish the request” may turn out to mean that a field was confusing, that required information was unavailable, or that the person did not know who could authorize the request. A fixed list of answer choices might miss a reason the team had not anticipated.
The interviewer needs a purpose and a discussion guide. That structure can keep sessions focused while leaving room for relevant surprises. GOV.UK's interview guidance emphasizes learning about users' circumstances and problems, with planned topics and follow-up questions. It does not turn a handful of accounts into a numerical estimate for every user.
Interviews also have limitations. A person may remember an event imperfectly, describe what they think the interviewer wants to hear, or discuss an unusual case. The interviewer may unintentionally lead the answer. These are reasons to ask concrete questions and distinguish observation from interpretation, not reasons to dismiss people's experiences.
If the research question is about how a process works, asking someone to show a suitable example can add context. Use only information appropriate for the session. The researcher does not need unrelated confidential records merely because the participant happens to have them open.
A worked example: why requests are incomplete
Imagine an internal equipment service receives requests without enough information to fulfill them. The team initially proposes this survey question: “Would you prefer our faster, simpler new request form?” This question cannot establish why current requests are incomplete. It also assumes the replacement is faster and simpler before that has been shown.
The team instead begins with a few carefully selected conversations across relevant roles. It includes people who submit requests, people who process them, and people who need help using the current route. The objective is to understand the missing information, not to collect votes for a favorite solution.
In one fictional interview, a requester explains that the form asks for an equipment code they do not know. In another, the processor explains that a description would be enough for initial triage, but the form does not say so. These invented examples show the kind of mismatch an interview could reveal; they are not findings from a real study.
The team now has a more specific question: do requesters understand what identification information they can provide? It can test revised wording with suitable example requests. It might also use a short survey to learn how respondents encountered the form and which information they had available. The survey follows a clearer question rather than replacing the exploratory work.
Finally, the team needs evidence about the whole outcome. If the revised form becomes easier to submit but creates more follow-up work for processors, the service may not have improved overall. Our guide to examining a handoff before choosing a new tool helps keep both sides of that exchange visible.
Repair the question before counting the answers
Survey wording determines what the response means. Pew Research Center's methods guidance discusses the effects of wording and response options, including the difficulty of questions that ask about two concepts at once. For an internal service, plain language and a single clearly defined subject make interpretation easier.
| Weak question | Problem to resolve | A more focused direction |
|---|---|---|
| “Was the process fast and easy?” | A respondent may find it fast but difficult | Ask about time and ease separately if both matter |
| “How often do you struggle?” | “Often” and “struggle” may mean different things | Define the task and a relevant period or recent event |
| “Which new feature do you want?” | Assumes a feature is the answer | Ask about the task or obstacle before proposing solutions |
| “Was support helpful?” | Some respondents may not have used support | Establish whether support was used before asking about it |
| “Did everything work?” | The service boundary is unclear | Name the step or completed outcome being assessed |
These are design examples, not ready-made validated survey items. Try proposed questions with people who resemble the intended respondents and ask what they understood. If they interpret a question differently from the team, fix it before collecting a large set of answers that will be difficult to use.
For repeated measurement, preserve the question and its context or clearly document changes. A shift in wording, audience, or invitation point can affect the apparent trend. If a later survey asks a different question, do not present the two percentages as though only the service changed.
Do not let the invitation choose the answer for you
An internal service may have users who rarely check the main team channel, work different hours, use assistive technology, or ask a colleague to complete the digital step. Consider whether the recruitment and response routes let those people participate. Offering a survey link is not the same as reaching every relevant group.
Interviews need similar care. Interviewing only the people who are easiest to schedule can leave important experiences unexplored. The goal of a qualitative sample is not automatically to mirror the organization by percentage, but it should make sense for the questions and groups being studied. State whose experience is represented and where gaps remain.
Feedback timing also changes the subject. GOV.UK's satisfaction guidance distinguishes feedback after a digital step from feedback at the end of a complete service journey. In the equipment example, submission is not the same as receiving the equipment. The invitation should match the outcome the team wants to understand.
Protect candor without making promises you cannot keep
Tell participants why the team is collecting feedback, how it will be used, and who will have access. Do not call a survey anonymous merely because it does not ask for a name. A small team, a detailed free-text account, or a combination of role and location can make someone recognizable. Check the actual collection settings and organizational process before describing confidentiality.
Keep the inquiry about the service rather than asking respondents to diagnose coworkers' behavior. A question such as “Which step required another contact?” can identify a process burden without inviting an unnecessary list of named individuals. If a participant raises a serious personnel concern, explain the appropriate route rather than treating it as ordinary usability feedback.
Recording interviews adds another decision about permission, access, storage, and retention. Follow the applicable organizational process, explain the arrangement, and collect only what the research needs. A useful interview can often be summarized without spreading an identifiable recording to everyone interested in the outcome.
Combine findings without pretending they are the same evidence
An interview account can suggest a cause or reveal a previously unknown obstacle. A survey can describe the answers received to a particular question. Operational records can show events such as incomplete submissions or repeated contacts. These sources can complement each other, but they should retain their identities in the analysis.
For example, “Three interviewees described difficulty finding the equipment code” is different from “Most staff cannot find the code.” The first may justify investigating the field. It does not establish the second. Likewise, a rise in satisfaction among respondents does not prove that a specific change caused it if other circumstances also changed.
Keep a concise distinction between evidence, interpretation, and proposed action. A decision record can explain why the team chose to revise the field and what it expects to learn next. A trackable issue can hold the implementation and its check, so the research does not end as an unused presentation.
Choose a sequence, not a permanent favorite method
If the team does not understand the problem, exploratory conversations may help it ask better questions. If it needs consistent responses to a defined question, a carefully designed survey may fit. If it needs to know whether people can complete a revised task, observation or usability work may be the next step. Several methods can be appropriate at different points.
Write the decision, the missing evidence, the relevant participants, and the intended use of the findings before collecting anything. Then choose a method whose limits you can explain. That makes the result more useful than a large response count attached to a question nobody can interpret confidently.
Sources
- GOV.UK: Plan user research for your service
Research methods should follow explicit questions, intended user groups, and the decisions the team needs to inform.
- GOV.UK: Using in-depth interviews
Interviews explore users circumstances, needs, and problems through planned topics and follow-up questions.
- Pew Research Center: Writing survey questions
Question wording, response options, order, and asking multiple concepts together affect survey interpretation.
- GOV.UK: Measuring user satisfaction
Feedback about one digital step can differ from satisfaction with a complete service journey; feedback should include different completion routes.