Start with decisions the interviews need to support
A request for a new website often arrives as a list of pages or features. Interviews help you understand the work behind that list before committing to a structure or design. For a small site, the aim is not to run an elaborate discovery process. It is to learn who the site serves, what those people need to do, what the organization can maintain and which decisions remain unsettled.
Before inviting anyone to talk, write down the decisions you need to make. These might include the site’s primary audience, the most important visitor tasks, the content needed at launch, who will approve it and who will maintain it afterward. Keep the list short enough to guide a conversation without turning it into a form. Ask for any existing brief, content inventory or support questions in advance, but treat them as starting points rather than settled requirements.
Speak with people who see different parts of the work
The project sponsor can explain why the work is happening and what a successful outcome would mean. They may not know which questions arrive by email every week or why staff avoid updating an existing page. Include someone who answers visitors’ questions, someone responsible for content and someone who will operate the site after launch. In a small organization, one person may fill several roles; ask them to distinguish what they know firsthand from what they assume.
If possible, make room for the perspective of actual visitors through existing feedback or separate user conversations. Staff can describe what they hear from visitors, but they cannot speak for every visitor. When time is limited, a few focused conversations across different roles are usually more useful than a large meeting in which the most senior person sets the tone. Individual interviews also make it easier to surface disagreements without asking anyone to challenge a colleague in public.
Ask about real tasks, not preferred features
Begin with open questions: Why does the website need attention now? Who most needs it to work well? What are visitors trying to find or complete? What happens when they cannot? Ask for a recent example whenever an answer stays broad. “People struggle to contact us” becomes more useful when you learn which contact method they tried, what information was missing and how staff resolved the problem.
Explore the work behind the website too. Ask which pages change often, who knows when information is out of date, who can approve changes and what the team can realistically maintain. Ask about constraints such as available time, existing systems, translation needs and accessibility concerns. Avoid leading questions such as “Would a booking tool help?” Instead ask how bookings work today and where the process breaks down. That leaves room for a simpler answer, including clearer instructions on a page.
Give each interviewee space to name one thing they would keep, one thing they would change and one thing they are unsure about. Record their words accurately, but do not treat every suggestion as a requirement. A requested feature may be one possible solution to a problem that has not yet been clearly described.
Turn interview notes into testable requirements
After the conversations, group your notes by visitor task, content need, operational constraint and open question. Separate observations from proposed solutions. For example, “Staff receive repeated questions about eligibility” describes a problem; “Add an eligibility quiz” proposes a solution. A useful requirement might be: “Visitors need to understand whether a service is suitable for them before they make contact.” That wording leaves the team free to consider a clear page, a short checklist or another manageable approach.
Look for patterns, but keep disagreements visible. If one person wants comprehensive detail and another worries that nobody can keep it current, the tension is a planning issue, not a note to hide. Mark each proposed requirement with its reason, its likely owner and any question that needs checking. Prioritize requirements that support essential visitor tasks and can be maintained with the people and resources available.
Confirm what you heard before design begins
Share a brief summary rather than a transcript. State the primary audiences, the tasks the site must support, the content likely needed, maintenance responsibilities, constraints and unresolved decisions. Use plain language so stakeholders can spot misunderstandings. Ask them what is missing and which assumptions need evidence. If a decision has an owner, name that role; otherwise, identify who must decide before the work can proceed.
The result should be a working brief, not a promise that nothing will change. Interviews cannot uncover every need, and some ideas will need checking as content and design take shape. They can, however, give a small website project a sound starting point: a shared understanding of the problems to solve, the limits to work within and the questions to revisit before they become expensive surprises.
