By the end of this lesson
- Design research questions around the next decision and choose suitable interviews, observation and record checks.
- Map a specific event as a workflow, separating quotations and verifiable records from your interpretation.
- Preserve differences between accounts, identify missing people and evidence, and update your judgment honestly.
Before you begin
- Bring the Lesson 2 working agreement and check permitted people and records. For self-study, use the published synthetic case; real access is unnecessary.
- Open Beichen's twenty introductory records. Locate E-004 and E-013, then read the night-shift account in the progressive practice scenario.
- Create three columns: what the material states, my interpretation, and what remains to confirm.
Read the Beichen case and introductory data
Decide what this round of research should help you choose
Do not start by collecting a large pile of opinions and deciding afterward what report to write. Begin with the choice at hand: should Beichen first improve document retrieval, specialist coordination or parts approval? Turn the information needed into questions: where does waiting occur, which tasks are affected, and who can change that step? This tells you whom to ask and what to inspect.
Interviews help explain experiences and concerns. Observation reveals actions and workarounds. Record checks describe the number and duration of recorded events. These methods do not substitute for one another: logs rarely establish why someone distrusts a suggestion, while interviews cannot directly measure waiting frequency across the service center. GOV.UK's discovery-research guidance also considers users, the whole service and existing records together.
Research may support the original judgment or change it. Do not force a change to make the research appear useful. Confirmation is valuable when the question affects a choice, the method permits counterexamples and the conclusion states its strength and limits. If the evidence is insufficient, say that you cannot yet judge rather than manufacturing certainty.
Ask about specific events rather than selling the assistant
'Would AI make this faster?' embeds a preferred direction in the question. Ask about a recent event and let the person explain it from beginning to end. Listen before following up on their own details. Hearing 'I couldn't find it' does not establish a need for better search, and a product demonstration can interrupt the account you need.
Arrange your discussion guide around the task, with opening questions and possible follow-ups. Check your understanding before finishing. GOV.UK's in-depth-interview guidance supports open, neutral questions and specific examples. The prompts below help you prepare. For self-study, only published material counts as an answer; leave unspecified answers open.
- Start with the trigger: 'Which recent incident required a remote specialist? What made you contact them?'
- Follow the actions: 'Where did you look first? What did you get? What information was missing then?'
- Separate possible problems: 'Were there no results, unsuitable results, or results you could not open because of access?'
- Ask about waiting: 'When did the wait begin? What could you do meanwhile? Who told you it was possible to continue?'
- Check the account: 'I have separated document lookup, waiting for confirmation and handling the incident. Which step have I missed or misunderstood?'
Record what is observed before interpreting it
A quotation supports 'this person said this,' not automatically 'everyone behaves this way.' A number supports 'this record contains this value,' while its definition and quality still need checking. Keep quotations, records and interpretations separate, with the source, identifier and context. The next reader can then see what can be rechecked.
For example, E-004 records 41 minutes of specialist waiting and the gap night_escalation. You can say that this introductory synthetic record contains a wait and points to a night escalation issue. You cannot yet conclude that no specialists are on duty on any Beichen night shift. That expands the claim. GOV.UK's analysis guidance separates observations from interpretation before identifying findings and actions; this course connects them through facts, assumptions, decisions and outcomes.
| Record type | A supported statement | Does not establish |
|---|---|---|
| Quotation | The scenario's supervisor says the process is uniform | Identical actual steps in every region |
| Data record | E-013 is labeled low and records a 46-minute specialist wait | Low actual risk or an accurate label |
| Interpretation / assumption | Waiting may relate to specialist availability | Changing shifts will necessarily resolve waiting |
| Proposed next action | Compare escalation times with specialist schedules | Customer approval to access those records |
Turn a Beichen account into a next step
Use the published progressive scenario for a complete walkthrough. It describes a high-temperature alarm on unfamiliar equipment: three minutes checking the system, a turn to private notes, then a 42-minute wait for a specialist. You did not observe or interview anyone, so identify the source as the published synthetic scenario. The time spent on private notes, overlapping activity and reason for the specialist's delay are not provided.
First, copy the actions in sequence and mark missing durations as unspecified. Second, form alternatives: suitable guidance may be unavailable, the valid version may be unclear, or professional confirmation may be needed. Third, propose different checks: search and access records, version applicability, and escalation timing with specialist availability. Fourth, draft a decision record: obtain the missing timeline and responsibility information before choosing retrieval as the priority.
This links a source, interpretation and action without declaring a cause prematurely. A real project needs permission and confirmation by the relevant people before executing the checks. For self-study, an honest outcome is that the available material cannot distinguish the causes, followed by what the next record must establish. That is a complete learning result, not a gap to fill with invented interview answers.
Map online and offline actions together
For each workflow step, record who acts, which information they use, whom they wait for, how they know they can continue and what happens in exceptions. You might sketch receiving the incident, checking records, contacting a specialist, preparing action, confirming the result and closing the ticket. This is a provisional diagram, not an established complete workflow. Mark unsupported connections as pending.
Include private notes, calls and message groups. They may be useful existing information channels or create version and record gaps; understand their purpose before judging them. Also mark where new work falls. Saving an engineer's drafting time may add specialist checking, data maintenance or support explanations. Work that does not appear in a log still needs investigation.
Keep conflicting accounts instead of voting for one
A supervisor's 'uniform process' and an engineer's 'different by region' may describe different layers: common policy but different tools or arrangements. Preserve both sources, ask where each applies, then identify records that can distinguish them. A majority view is not a reason to discard a minority's potentially serious experience.
Also distinguish material sets. The introductory JSON records a 46-minute specialist wait for E-013; the progressive scenario gives a 42-minute wait in its narrative. The published material does not establish enough about measurement boundaries or linkage to combine these automatically. Keep both sources, do not average them, and note that the relationship and time definitions need checking.
E-013 is labeled low severity, but its gap indicates a description involving a safety shutdown. Treat that as a reason to review label quality, not an invitation to make your own equipment-safety judgment. It shows why a low label alone cannot establish that a task is low consequence when selecting a pilot.
Find people who affect the research and the change
Extend the Lesson 2 contact list with the records each person can provide, decisions they can confirm and work they may gain. Do not rank people only by seniority. A senior engineer may lack budget authority but know exceptions. A newcomer may welcome suggestions yet hesitate to raise concerns before a manager. An operations owner may support the direction without having review capacity. These are possibilities to check, not personality judgments.
Real research should include differing working conditions and consider abilities, equipment and support needs. Enthusiastic users do not represent everyone. If a group cannot be reached directly, record that limit and seek permitted alternatives. In self-study, use the case responsibilities to draft questions; do not invent attitudes that the characters supposedly expressed.
Decide when there is enough information for the next step
At the end of each round, revisit the questions: which have support, which still have competing explanations, and which limitations affect the next action? Record whether to proceed, narrow scope, obtain more information or pause. Research need not always lead to building more software. Repeated descriptions can reveal patterns but do not replace checking important exceptions or missing groups.
Common mistakes are treating interview count as sufficient proof, equating the largest theme with the most important problem, deleting contradictions for consistency, and presenting synthetic records as real customer evidence. Your aim is a checkable basis for the next decision. If it is insufficient, identify the missing record, its owner and why it could change the choice instead of simply proposing more research.
Practice the method
Create a Beichen research note. Every established statement must point to published material. Write questions for interviews that have not happened, not supposed results.
- 01
State the choice your research should support: prioritize retrieval, specialist coordination or another step?
- 02
For E-004 and E-013, copy three record facts with fields and sources. Add what each cannot establish.
- 03
Map the progressive night-shift scenario. Mark missing durations and steps as pending; retain separate sources for 42 and 46 minutes.
- 04
Propose at least two explanations for waiting. For each, name a supporting clue, missing evidence and a neutral interview question.
- 05
List missing participants and the status of permission to contact them. Do not treat proposed contacts as completed interviews.
- 06
Recommend a next action and explain how different findings would change the research order or scope.
Check your understanding
Write your answer before opening the explanation, then check what you might have missed.
Is 'engineers often cannot find answers' an established frequency?
If it comes from one account, it is a statement rather than a measured frequency. Ask about a specific event and inspect records with defined scope and meaning before estimating how often it happens.
How should you handle the 42-minute and 46-minute waits?
Keep the progressive scenario and introductory JSON as separate sources. Their measurement relationship is not established, so do not merge or average them. Check linkage and timestamp definitions if further evidence becomes available.
Can you complete the exercise if synthetic material does not establish the cause?
Yes. State the clues, alternative explanations and missing evidence, then propose a conditional next action. Accurately identifying limits is more useful than inventing interview answers.
Your record and next step
A research plan, three sourced observations, an actual workflow and a map of the people involved.
Separate facts from guesses, include different perspectives and identify a finding that changes your next step. Do not present imagined interview details as established facts.
Lesson 4 uses your workflow, sourced notes and competing explanations to compare problems worth addressing. Carry uncertainties forward; do not turn them into facts when writing the problem brief.