Purpose and fit

Use this when an available AI-assisted workflow is used inconsistently, creates workarounds or adds unexpected effort. Low usage can reflect poor fit, missing access, unclear responsibilities or sensible avoidance. Investigate the task experience before asking people to use the tool more often. Focus on useful completed work and the people who receive it.

Before you start

Use existing authorised walkthrough notes, support records or participant accounts about a bounded task. A small qualitative evidence set is enough to identify hypotheses; no new dataset is required. Do not upload unnecessary personal or performance information.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

  • A specific workflow, intended participants and definition of accepted work
  • Approved observations or sanitised participant accounts of recent attempts
  • Available records of review, rework, fallback and support requests
  • A baseline process, relevant constraints and authority for a bounded improvement

Practical workflow

  1. Choose one task path and clarify when AI use is optional, expected or unsuitable. Establish what successful completion looks like, including required human review and downstream acceptance.
  2. Walk through recent completed, abandoned and avoided attempts with willing participants. Ask what happened at each step and what they did instead. Record evidence without collecting unnecessary personal data or assessing individual productivity.
  3. Locate friction: access, input preparation, unreliable outputs, difficult review, duplicate entry, unclear authority, lack of skill or insufficient support. Distinguish a reported cause from an observed one.
  4. Estimate the burden from available records: effort, delays, corrections and fallback work. Include work shifted to reviewers or other teams. If counts are incomplete, describe the gap instead of extrapolating a savings claim.
  5. Select one change that addresses the strongest supported cause. Define the owner, scope, review needs, expected observable improvement and conditions for reverting. Preserve required safeguards even when participants find them inconvenient.
  6. Try the authorised change on a bounded set of work and compare the same outcomes. Keep adverse effects and non-use visible. Decide whether to retain the change, revise it or investigate another cause.

Expected output

Expect an evidence-linked friction log and a proposed small improvement card, not proven prevalence, measured savings or a causal diagnosis.

A friction log and a small improvement card:

Workflow step | observed/reported problem | affected group | evidence/source | frequency known or unknown | burden/fallback | likely cause | uncertainty | owner

Improvement card: problem addressed; change proposed; supporting evidence; participants and scope; required approvals; accepted-work measure; review/rework measure; safeguard checks; observation window; rollback condition; owner; decision date.

Hypothetical example: staff stop using a summary tool because they must re-enter the same source information elsewhere. The proposed test simplifies the authorised input handoff and measures total preparation plus review effort. Higher tool usage alone is not the success criterion.

Human checks

Participants validate the account of their work and can explain deliberate non-use. Downstream teams check whether an apparent improvement shifts cost or risk to them. The process owner protects required review, accessibility and data boundaries. Do not use this exercise for covert employee monitoring or automated performance judgments. Consequential changes require the appropriate specialist and accountable-owner review.

Limitations

A few walkthroughs can reveal concrete problems but cannot establish their prevalence. Self-reports and usage logs each provide incomplete evidence. Several causes may interact, and an improvement may depend on temporary support. Some tasks are unsuitable for AI assistance; a legitimate outcome is to retain the existing process or narrow the proposed use.

Starter prompt

Analyse adoption friction in this bounded workflow using only these approved, sanitised observations: [notes]. The accepted-work definition, safeguards and available measures are [details]. Create a friction log with workflow step, problem, affected group, evidence/source, known/unknown frequency, burden/fallback, likely cause, uncertainty and owner. Separate observed facts, participant explanations and hypotheses.

Suggest a small improvement tied to the best-supported cause. Its card needs problem, proposed change, evidence, participants/scope, approvals, accepted-work and review/rework measures, human checks, observation window, rollback condition, owner and decision date. Include review, rework, fallback and downstream burden. Leave missing counts unknown. Do not label people resistant, equate usage with value, recommend removing required safeguards or infer individual performance from these records.

Adapt the structure to the information I actually provide. First identify essential missing inputs and ask targeted questions. If a useful partial draft is possible, produce it with explicit unknowns and labelled assumptions. When counts, baseline or outcome data are missing, describe the observation qualitatively and mark frequency and burden unknown. Ask what existing records could test the hypothesis.

Each proposed change must address a supplied observation or a clearly labelled hypothesis and retain safeguards. Never extrapolate savings or individual performance; leave trial results blank until a bounded authorised trial is observed.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.