Listen to the problem before choosing an event

Check the background against records first

Before the interview, gather the request email, evaluations of previous events, relevant enquiry records and the guidance currently available. Record the date and scope of each source, because they may have been produced at different times and cover different people. Filling gaps with assumed causes can turn an interview from fact-finding into persuasion.

Ask the requesting department about the background and expectations, and ask the people doing the work where the process breaks down. If the issue concerns participants, plan to hear from participants themselves. Do not establish the needs of the entire audience from the requesting department’s account alone.

Begin with a recent experience rather than an event format

Asking “What kind of event would you like?” tends to produce an event name. Instead, ask “Could you describe a recent situation when this problem occurred?” to learn the date, place, people involved and task underway. Then ask, in sequence, where they got stuck, how they responded, what the impact was and whether there are records to check. Ask about event ideas last.

Ask about observable actions behind evaluative labels

Do not simply record an answer such as “Participation is low.” Ask what participation means and what behaviour the person observed directly. The next evidence to check differs completely depending on whether people did not register, registered but did not attend, or attended without talking to others.

Record a statement such as “A large event would help” as a hypothesis about a solution. Ask what experience led to that view and what actions the person expects an event to enable. Take care not to put the answer into the question.

Separate the record into four categories

The note-taker records what was said, evidence checked, the planning team’s interpretation and proposed solutions separately. Mark words that cannot be recalled accurately as a summary rather than a quotation. After the interview, the interviewer and note-taker compare the record together and correct omissions and interpretations.

The following is a fictional record, unrelated to any actual organisation.

Compare people’s experiences with the evidence

One person’s experience can indicate that a problem may exist; it does not establish its prevalence or the views of everyone. If internal and participant accounts differ, retain both, record the difference and decide what further evidence is needed. When examining enquiry records, check whether the time periods and classification rules are comparable.

Check the summary before closing

Before finishing the interview, the interviewer summarises in their own words who was trying to do what, in which situation, and where they got stuck, and reads it back. Agreement with the summary does not mean the cause or solution has been verified. Retain points of disagreement. Attach the evidence needed, an owner and a deadline to each unconfirmed item.

Practitioner checklist

• Does the record describe a recent experience and blocked action rather than only the requested event format?
• Are direct experience, second-hand accounts, checked records and the planning team’s interpretation distinguished?
• Have evaluative labels been clarified as observable actions?
• Are the requested event and its expected effects recorded separately?
• Does every unconfirmed item have an owner and a deadline?

Use the form for the next handover

Use the [Event-request interview, evidence and unknowns log](/en/templates/request-interview-evidence.html) for the records described here. The XLSX contains Blank, Example and Instructions sheets. Write your event in Blank; the fictional example is a guide to what to enter.

Record the recent task and where it became blocked before considering event ideas. Distinguish direct accounts, hearsay, quotations and summaries and link evidence actually checked.

The interviewer sends the summary, evidence and assumptions to the problem-definition owner. The options reviewer treats the requested event as one possible response and follows up missing evidence.

Conclusion

The interview output is not approval to hold an event. It is a description of the problem, with evidence and outstanding questions. The event can be chosen at the next stage, after comparison with other responses. Before designing an event as soon as a request arrives, first check whether the problem can be explained.

*Reference: Adapted for event intake from user-research guidance in the GOV.UK Service Manual and the in-depth interview section of the Korea Institute of Design Promotion’s Citizen Design Group manual. The example is fictional and is not an actual research finding.*