Practical intelligence for accountable AI programs.
A practical field-research method for finding recurring workflow constraints, testing their consequences and comparing AI with simpler changes.
ModelFold Editorial Team9 min read
A complaint is a research lead, not yet an AI use case. Suppose an operations team says client onboarding briefs take too long and requests an AI summarizer. A workflow map drawn from memory may make drafting look like the problem, while completed cases may show that difficult briefs wait for missing commercial decisions and are rewritten after contradictory fields are resolved. The complaint remains useful evidence of the coordinators' experience, but it does not establish where the recurring constraint sits, how often it appears or what consequence follows. A defensible proposal starts by observing a bounded sample of real work, preserving evidence that challenges the initial story and comparing AI with simpler changes.
What to carry into the field
Define a provisional workflow boundary and the questions the field round must answer before discussing AI capabilities. Record the trigger, end condition, output, downstream user, participating roles and relevant routine and exception cases. In the onboarding example, the boundary runs from receipt of an approved sales handoff to a brief accepted by a delivery lead. Include routine, incomplete and changed-scope cases so a convenient happy path does not stand in for the work. If observation exposes a consequential upstream decision or downstream correction, revise the boundary openly rather than forcing the evidence into the original frame.
Begin with recurring work and real outputs: forms, briefs, messages, checklists or other items that people actually produce and use. Note how the output varies, where handoffs occur and which uncertainties the research must resolve. The method here is a practical synthesis, not a standardized protocol validated as one package. Choose the smallest proportionate mix of recent-case interviews, contextual observation, artifacts, short diaries and operational records that can answer the question and offset known blind spots.
Recent-case interviews reveal the sequence, decisions and handoffs of a specific completed case without pretending that one account represents every case. Ask what triggered the work, what arrived, what happened next, which decisions were made, who received each handoff, what output was accepted and where the path departed from expectations. Use open, neutral prompts such as “What happened next?”, “What told you that?”, “Who did you contact?”, “What was uncertain?” and “Can you show the item you used?” Do not ask the participant to design an AI feature during reconstruction.
Probe the cognitive work as well as visible actions: information cues, alternatives, uncertainty and difficult judgments can disappear from a procedural description. This is compact cognitive-demand probing, not the formal ACTA protocol. For onboarding, reconstruct one routine brief and one difficult brief with coordinators, sales operations and delivery leads. Interviewing across the handoffs helps expose mismatched expectations, while demonstrations and actual artifacts can surface steps that a confident verbal account omits.
Watch the work with its usual equipment, documents, data, interruptions and dependencies. Note source switching, waiting, verification, rework, handoffs, workarounds and moments when someone interprets incomplete or conflicting information. In the onboarding case, observe a coordinator assemble a live brief without scoring the person. A workaround may reveal a missing system function, but it may also reflect a rare exception or personal preference; ask what it accomplishes and look for corroboration before treating it as a shared pattern.
Choose and record the observation mode. Silent observation preserves more natural flow but can leave motives unclear; occasional questions add context with some interruption; continuous explanation produces depth while changing the activity. Keep field notes in separate fields for case context, observed action, artifact reference, decision or uncertainty, handoff, interruption, consequence and researcher interpretation. That separation lets another reviewer challenge an inference without disputing what was directly observed.
Frame observation as research into the workflow, not an assessment of individual performance. Obtain informed participation, minimize researcher influence, reconfirm consent before adding any recording and store personal data securely. Collect only what the research question requires, restrict access and involve appropriate privacy, security, legal, labour, accessibility or domain owners when sensitive work or information is involved. Ask the participant to confirm or correct the reconstructed flow at the end. This can improve the account, but a small interpretive sample still cannot describe an entire workforce.
Artifacts, short task diaries and operational records extend the field view across hidden state, time and additional cases. Ask participants to explain templates, checklists, spreadsheets, messages, drafts, paper notes and queue views from the cases under study. Their arrangement or markings may reveal memory, tracking and coordination practices missing from an official process map, but the participant must confirm what each artifact means and how it was used.
Use brief diary entries when relevant events are intermittent or unlikely to occur during scheduled observation, then follow up to clarify ambiguous entries. Diaries remain self-reported evidence. Where usable case, activity and timestamp records exist, inspect recurrence, waiting, rework, duplicated handling, deviations, missed deadlines and recurring quality problems. Document work outside recorded systems as carefully as recorded events. Less common paths should not be discarded until their effort and consequence are understood.
| Evidence method | What it can reveal | What it can miss | How to corroborate |
|---|---|---|---|
| Recent-case interview | Sequence, experience, decisions, uncertainty and handoffs | Unnoticed actions, recall gaps and recurrence across cases | Ask for artifacts, observe a task and compare contrasting cases |
| Contextual observation | Tools, interruptions, workarounds, verification and support activity | Infrequent events, private reasoning and behaviour outside the session | Ask neutral questions, review the reconstruction and inspect other cases |
| Workflow artifacts | State, priority, memory cues, revisions and coordination practices | Why an item exists, how often it is used and work performed elsewhere | Have participants explain the artifact in a specific case |
| Short task diary | Real instances spread across time, including intermittent work | Unreported events, ambiguous shorthand and participant attrition | Follow up with an interview, artifact review or observed task |
| Operational records | Event sequences, waiting, rework, deviations and recurring patterns | Offline clarification, inconsistent definitions and reasons behind delays | Reconcile records with observation, artifacts and practitioner interpretation |
A pain point becomes a credible bottleneck hypothesis when evidence places a recurring constraint at a specific workflow location and connects it to an observable consequence. The mechanism must remain plausible after people doing the work have confirmed or corrected it, and counterexamples must stay visible. Operational records can reveal waiting, deviations and rework, but they may omit offline activity and cannot establish why the pattern occurred. Use the following six questions as an editorial decision rule, not causal proof or a formal statistical test.
In the onboarding example, the hypothesis shifts from slow summarization 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. Those negative cases and record gaps matter. If recurrence, location or consequence remains unclear, keep the complaint as an open research lead. If the pattern is coherent but causal certainty is limited, design the smallest test that could distinguish the leading explanation from its alternatives.
Do not ask where AI fits until you can show where a recurring constraint appears, what consequence follows and what remains uncertain.
An evidence-backed opportunity card records the bounded work, observed pattern, operational consequence, uncertainty, constraints, alternatives and next test. Begin with the trigger, end condition, output, downstream user and roles, then state the observed period, case types, roles represented and method mix. Separate the stated pain from the observed pattern. Link substantive assertions to field-note identifiers, redacted artifact identifiers, diary entries or record queries; label anything else as an assumption.
Compare every intervention against the same evidence rather than asking AI to clear a lower bar. The NIST AI RMF Playbook supports documenting purpose, users, operational context, limitations, impacts, scope and human oversight, while also considering non-AI alternatives; it is voluntary guidance, not a compliance determination. For onboarding, first test required intake fields, an explicit handoff owner and a visible exception queue. Consider drafting assistance later for fact-complete cases. End the card with one decision: test AI, test a non-AI change, gather more evidence or stop.
Bound a recurring workflow, reconstruct real cases and connect a recurring constraint to an observable consequence. Preserve counterevidence, document information and oversight constraints, and compare AI with simpler interventions. Propose only the smallest test that could show whether AI has a practical advantage.
A pain point is a valid report of frustration or difficulty. An opportunity is a bounded task supported by evidence about recurrence, workflow location, consequence, constraints and a plausible intervention. The evidence may still justify more research or a non-AI change.
Frame the work as workflow research rather than individual performance assessment, obtain informed participation and collect only proportionate evidence. Record the observation mode, restrict access and let participants correct the reconstruction. Involve appropriate privacy, security, legal, labour, accessibility and domain owners where applicable.
No. This protocol is a practical synthesis, not a universal checklist. Choose the smallest mix that answers the research question, then add another method only when it compensates for a material blind spot.
No. Observation and operational records can support a bottleneck hypothesis, but small samples, researcher influence, missing events and alternate explanations limit causal claims. Preserve negative cases and run the smallest discriminating test instead of presenting the hypothesis as proof.
This article draws on 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 work, classifying exceptions, testing approvals, defining handoffs and deciding when automation is ready.
A practical guide to mapping tasks, testing AI, tracing redistributed effort, preserving expertise, and changing roles only after a measured pilot.
A practical method for assigning AI decision rights, routing evidence through review forums, and turning pilot lessons into portfolio and strategy changes.
