Map what makes the work difficult before writing a learning objective. If employees cannot access the right tool, do not have permission to act, or receive conflicting instructions, a well-written objective will not remove the obstacle. It may simply describe something they still cannot do.
A friction map follows one task from trigger to completion and records where work stalls. It separates a possible knowledge or skill gap from a barrier in the surrounding system. The result is a set of actions with different owners, some of which may involve training.
Follow a specific task through its normal conditions
Use a task small enough to observe. “Improve customer service” is too broad. “Route a customer’s nonurgent service request to the correct internal team with the required information” is workable. Identify the person doing the task, the available information, the tools and the point at which responsibility passes to someone else.
The CIPD Learning at Work 2023 survey examines learning professionals’ approaches to performance problems. Its respondents were predominantly UK-based, and the findings describe reported practice rather than the effectiveness of this map. For a more direct design principle, the CDC’s training standards advise checking that training is an appropriate response to the gap.
In the fictional example below, a team reports that requests arrive in the wrong queue. The initial response is a proposed refresher course. Before agreeing, the designer traces how a request is classified, submitted and accepted. The map uses invented observations to demonstrate the method; it does not report a client investigation.
Distinguish the obstacle from its visible symptom
“Wrong queue” is the symptom. Several conditions could produce it. A coordinator may not recognize the request type. The correct queue may be missing from their menu. Two departments may use the same label differently. A supervisor may tell staff to choose the fastest option regardless of the written procedure.
These explanations can coexist. Do not force the project into a choice between “training problem” and “system problem” if the evidence supports both. Instead, record the obstacle at each step and ask what must change for the intended action to become possible.
Illustrative friction map. All observations and owners are fictional examples, not findings about a real organization.
Work step: Identify request type
Friction to verify: Coordinator cannot distinguish two similar categories in a realistic example
Likely action if confirmed: Practice with contrasting cases and feedback
Responsible role: Learning lead with process expert
Work step: Select destination
Friction to verify: Correct queue is not visible under the coordinator’s permissions
Likely action if confirmed: Correct access or define an authorized alternative
Responsible role: System owner
Work step: Add required details
Friction to verify: The form asks for an internal code the requester does not know
Likely action if confirmed: Improve the field, guidance or source of information
Responsible role: Form owner
Work step: Submit the request
Friction to verify: Written guidance and supervisor instructions conflict
Likely action if confirmed: Agree and communicate the current rule
Responsible role: Process owner and manager
Work step: Handle an exception
Friction to verify: No named escalation route exists
Likely action if confirmed: Establish an accountable route before teaching it
Responsible role: Operational owner
The “if confirmed” wording matters. A friction map should show what is known and what remains a hypothesis. It should not become a confident-looking table of guesses.
Test the explanation with the smallest useful check
For a suspected knowledge gap, ask the employee to work through a safe, representative example with normal reference materials available. If they can explain and perform the decision under realistic conditions, investigate why actual work differs. Do not remove references merely to manufacture a memory problem unless unaided recall is genuinely required.
For a permission barrier, observe the authorized view or ask the system owner to verify the role’s access. Do not request elevated permissions just to make the training exercise succeed. For an unclear expectation, compare the current approved rule with the instruction employees actually receive. For a process gap, ask who has authority to resolve it.
Use more than one case when the task varies. An ordinary request can appear straightforward while a common exception exposes the real difficulty. Include the conditions that matter, such as remote work, time pressure or incomplete information, without deliberately creating unsafe production conditions.
Write the objective for the remaining learning need
After the system and expectation checks, the genuine learning need may be narrow: coordinators need to distinguish two request categories when the description contains overlapping cues. An objective could be: “Given the current routing guide and a service-request example, choose the appropriate queue and identify the deciding information.”
That objective is teachable and assessable. It also names the reference available during the task. It does not claim that the course will fix missing permissions, rewrite the form or reduce organizational delay by a certain amount.
Plan practice around the uncertain distinction. Provide one worked comparison, then a new case where the superficial wording suggests one category but the deciding condition points to another. Ask for the reason as well as the destination. Check whether learners can make the decision with the actual guide they will use at work.
Keep nontraining actions in the same decision record
A common failure is to identify a process barrier in discovery and then let it disappear when course development begins. Record each confirmed barrier, its owner, the required decision and how completion will be checked. Mark dependencies clearly. Training that teaches a new queue cannot be ready for use before the queue is available to the intended role.
Some barriers will not be resolved within the project. Say so. If employees can complete only a limited version of the task under current conditions, define that scope rather than presenting the ideal process as universally available. Escalate unresolved operational risk through the organization’s normal channels; a learning team should not invent a workaround that bypasses required controls.
Review the map after a real attempt
Once changes are in place, observe whether the task can actually be completed. A correct practice response and a repaired permission setting are useful but different pieces of evidence. Check both before attributing improved work to training.
The map is not a formal causal study, and a small sample cannot establish the prevalence of every barrier. Its immediate purpose is to prevent an avoidable mismatch between the problem and the response.
Start with one task and one recent example. Add a row only when it names a specific obstacle and a check you can perform. Write the learning objective after that map has shown what people need to learn and what the organization needs to fix.
