Practical intelligence for accountable AI programmes.
A practical field-research method for testing workflow complaints against real cases before choosing an AI experiment or a simpler operational change.
ModelFold Editorial Team9 min read
A complaint is a research lead, not an AI use case. Imagine an operations team reporting that client-onboarding briefs take too long and asking for an AI summariser. A workflow map drawn from memory makes drafting look like the problem, yet completed cases may show that difficult briefs wait for missing commercial decisions and are rewritten when contradictory fields are resolved. Automating the visible writing step would leave that constraint untouched. The sounder starting point is a bounded sample of real work that connects reported frustration to recurring cases, operational consequences, counterevidence and a choice between AI and simpler changes.
What to carry into the field
Define the work by its trigger, end condition, output, downstream user, participating roles and relevant case types before discussing AI capabilities. Start with recurring work and real outputs, then write the questions the field round must answer. GOV.UK interview guidance likewise starts planning from the research questions and the processes or technologies to understand. Keep the boundary provisional: observing an apparently self-contained task may expose an upstream decision or downstream acceptance step that materially changes the unit of study.
For the onboarding example, the useful boundary runs from receipt of an approved sales handoff to acceptance of the brief by a delivery lead. It includes routine, incomplete and changed-scope cases, not merely the coordinator's drafting session. The evidence protocol here is a practical editorial synthesis, not a standardised package validated by one source. Choose the smallest proportionate mix of interviews, observation, artefacts, diaries and operational records that can answer the question and expose important blind spots.
Recent-case interviews reveal a sequence of actions, decisions and handoffs when they stay anchored to one completed instance. Ask what triggered the case, what arrived, what happened next, which decisions were made, who received each handoff, what output was accepted and where events departed from the expected route. GOV.UK guidance favours stories and concrete examples over accounts of how work should happen, using open, neutral follow-up questions. One reconstructed case remains illustrative, so contrast routine and difficult cases.
Probe the information cues, alternatives, uncertainty and difficult judgements behind visible steps, while presenting this as compact cognitive-demand probing rather than formal ACTA. In the running example, interview coordinators, sales operations and delivery leads so the handoffs are represented. People who deliver a service together may also be interviewed in pairs or small groups, and an interview can accompany an observed task. One original workflow study found that demonstrations and artefact inspection supplied details that verbal descriptions had not produced.
Watch the task with its usual equipment, documents, information, interruptions and dependencies. Note source switching, waiting, verification, rework, handoffs, workarounds and moments when someone interprets incomplete or conflicting material. Contextual research is valuable precisely because normal surroundings can expose barriers and support activity that retrospective descriptions miss. It is still a small, interpretive sample: the observer's presence may change behaviour, and a few observed cases cannot represent an entire workforce.
Choose the observation mode deliberately and record it. Silent observation preserves more of the natural flow but can leave motives unclear. Occasional questions provide context with limited interruption. Continuous explanation yields depth while changing the activity more substantially. Whichever mode is used, separate what was seen from what the researcher inferred. At the end, ask the participant to confirm, correct or dispute the reconstructed flow; shared interpretation improves the account without converting it into population-level proof.
Frame the exercise as research into the workflow, never as an assessment of individual productivity. Obtain informed participation, minimise researcher influence, reconfirm consent before introducing any new recording and store personal data securely. Collect only what the research question requires, restrict access and involve the appropriate privacy, security, legal, workforce-relations, accessibility or domain owners where relevant. These are safeguards for responsible research, not a legal or compliance determination, and sensitive or regulated work may require qualified professional guidance before observation begins.
Artefacts, brief task diaries and operational records reveal parts of work that a scheduled interview or observation may not capture. Ask participants to explain templates, checklists, spreadsheets, messages, drafts, paper notes and queue views used in a real case. Their format and markings may expose state, priorities, memory aids and coordination practices absent from an official process map. Confirm meaning with the participant: possession of an artefact does not show how, why or how often it is used.
Use a short diary when relevant task instances are intermittent or distributed across time, then follow entries with clarification. An applied GOV.UK project captured feedback during or just after real use and combined the diary with interviews and observed tasks; it does not establish a universal study duration or prompt frequency. Diary entries remain self-reported. Where usable case, activity and timestamp records exist, inspect recurrence, waiting, rework, duplicated handling, deviations, missed deadlines and recurring quality problems.
| Evidence method | What it can reveal | What it can miss | How to corroborate |
|---|---|---|---|
| Recent-case interview | Sequence, rationale, uncertainty and handoffs | Forgotten detail and recurrence across cases | Ask for artefacts, demonstrations and contrasting cases |
| Contextual observation | Tools, interruptions, workarounds and tacit support | Infrequent events and unaffected behaviour | Confirm the reconstruction and compare other cases |
| Workflow artefacts | State, memory aids, revisions and coordination | Meaning, frequency and unrecorded context | Ask the user to explain each item in a case |
| Brief task diary | Real instances spread across time | Unreported activity and retrospective interpretation | Clarify entries in follow-up interviews |
| Operational records | Timing, variants, queues, returns and rework | Offline activity, motives and inconsistent case definitions | Reconcile logs with people, observation and artefacts |
Logs are examples of recorded behaviour, not the whole workflow. They may omit negative cases and offline clarification, sit across disconnected systems or lack a stable case definition. A timestamp can show when a case waited but cannot establish why it waited. Less common exceptions also deserve examination before they are discarded: their effort or consequence may matter even when their frequency is modest. For onboarding briefs, compare intake material, messages, checklists, draft trails and correction comments with available queue age, returns and missing-field reasons.
A pain point becomes a credible bottleneck hypothesis when multiple relevant cases or evidence sources place a recurring constraint at the same workflow point and connect it to an observable consequence. Operational records can reveal waiting, deviations and rework, but incomplete logs must be reconciled with observation, artefacts and the interpretations of people doing the work. Keep cases that contradict the emerging account. Contextual inquiry supports checking researcher interpretations with participants while cautioning against broad inference from small, subjective samples.
This six-question test is an editorial decision rule, not a formal statistical test and not proof of causation. In the onboarding example, the hypothesis shifts from slow summarisation to missing decisions and contradictory fields in difficult cases. Routine briefs are completed quickly, longer briefs are not consistently slower, and system timestamps omit offline clarification. That counterevidence prevents an inflated conclusion. If recurrence, location or consequence remains unclear, retain the complaint as an open lead and gather more evidence rather than manufacturing a confidence score.
Do not ask where AI fits until you can show the recurring constraint, its consequence and the uncertainty that remains.
An opportunity card should be a bounded decision record, not a polished sales pitch for AI. Record the workflow trigger, end condition, output, downstream user and roles, followed by the observed period, case types, represented roles and method mix. Separate the stated pain from the observed pattern. Link substantive statements to field-note identifiers, redacted artefacts, diary entries or record queries; label anything else as an assumption. Preserve disagreement, negative cases, gaps and alternative explanations rather than compressing them into one score.
The NIST AI RMF Playbook's Map function calls for documentation of purpose, users, operational setting, business value, limitations, impacts, application scope and human oversight. It also asks teams to consider non-AI and non-technology alternatives, without prescribing a winner. The guidance is voluntary and context-dependent, not a compliance certification. Similarly, official use-case discovery guidance retains an evidence requirement, an owner, a next milestone and a later test rather than treating agreement in a workshop as evidence of value in operational use.
Finish with one decision: test AI, test a non-AI change, gather more evidence or stop. For the onboarding example, the next sensible test is required intake fields, an explicit handoff owner and a visible exception queue. Drafting assistance can be considered later for fact-complete cases, but it should not be presented as the remedy for missing upstream decisions. Propose AI only when the evidence supports a bounded task, a recurring constraint, an observable consequence, workable information and oversight, and a testable advantage over simpler alternatives.
Define a recurring workflow, inspect real cases and locate a constraint with an observable operational consequence. Preserve uncertainty and counterevidence, then compare AI with non-AI alternatives. Propose only the smallest test that can distinguish between the competing explanations or interventions.
A pain point is a valid report of frustration or difficulty. An AI opportunity is narrower: evidence places a recurring constraint within a bounded task, connects it to a consequence, identifies workable information and oversight, and gives AI a plausible advantage worth testing.
Frame observation as workflow research rather than individual performance assessment, obtain informed participation and state the observation mode. Minimise collection, restrict access and let participants correct the reconstruction. Involve the appropriate organisational owners before handling sensitive, confidential or regulated information.
No. This method is a practical synthesis, not a compulsory checklist. Choose the smallest combination that answers the research question and compensates for known blind spots; add another method only when it resolves a material gap.
No. Observation, interviews, artefacts and records can support a coherent bottleneck hypothesis, but they do not establish causation by themselves. Preserve contrary cases and alternative explanations, then run the smallest discriminating test instead of claiming proof.
This article was researched using the following sources:
We report on how AI actually lands inside a business. Our work starts from named sources, separates what we found from what we think, and uses AI assistance for research and drafting under documented editorial controls. We are not a substitute for individual expert review.
A practical method for mapping real workflows, testing controls, defining handoffs and resolving ambiguity before automation begins.
A practical method for mapping tasks, testing AI assistance, tracing redistributed effort and redesigning roles only when ownership and workload are clear.
Build an AI operating model that assigns decision rights, balances central control with domain ownership, and turns pilot evidence into strategy.
