Friction Mapping -- Understanding Work Before Recommending Solutions

Audience

Small-business owners, nonprofit leaders, managers, team leads, advisors, and facilitators who need to understand a current process before recommending a change. No diagramming, process-improvement, or AI expertise is required.

What Do You Need

• Format: individual, pair, small group, paper, whiteboard, or facilitated discussion.
• Tool: no AI tool or diagramming software is required.
• Materials: paper or a whiteboard and one ordinary, low-risk process that can be discussed without exposing confidential information.
• Preparation: choose a process with a clear beginning and end, such as handling an inquiry, approving a purchase, scheduling a volunteer, or preparing a recurring report.

Learning Outcomes

By the end of this module, learners should be able to:

• Explain friction mapping as a current-state discovery method.
• Identify inputs, outputs, transformations, actors, systems, handoffs, exceptions, and rework.
• Describe friction as a system signal rather than a personal failure.
• Treat workarounds as clues while preserving practices that work.
• Separate direct observations from root-cause hypotheses.
• Map a role’s decision loops before treating the role as an automation candidate.
• Set a recommendation boundary before proposing a solution.

What Is Friction Mapping?

Friction mapping is a disciplined way to understand how work actually moves today. It makes steps, decisions, delays, handoffs, exceptions, repairs, and missing context visible before anyone proposes a future state.

The core discipline is simple: current state before future state. The map is not a blame document, a performance score, or a list of AI use cases. It is a shared picture that helps people ask better questions.

Map the Current State

Set a boundary before mapping. Name where the process begins, where it ends, and whose perspective is included. Then follow the work in order:

1. Name the trigger that starts the process.
2. Identify the inputs that enter it.
3. Follow the transformations that change those inputs.
4. Mark the people, roles, systems, and handoffs involved.
5. Record decisions, waits, exceptions, workarounds, and rework loops.
6. Name the outputs and who receives them.
7. Mark what remains unclear and who might know more.

Map what happens, not what policy says should happen. If two people describe the process differently, preserve both observations until you can investigate the difference.

Inputs, Outputs, and Transformations

An input enters the process: a request, form, message, payment, file, question, event, or piece of context. An output leaves a step or process: a decision, response, record, product, handoff, or completed service. A transformation is the work that changes an input into an output.

These distinctions prevent vague statements such as “the team handles requests.” Ask what arrives, what changes, what leaves, and which judgment makes the change possible.

Friction Is a System Signal

Friction appears where work waits, repeats, conflicts, loses context, requires repair, or depends on an unclear decision. It may reveal a policy conflict, missing information, brittle handoff, inaccessible tool, capacity limit, or mismatch between formal process and real work.

Describe the condition without assigning character or motive. “The request returns twice because two required fields are usually missing” is more useful than “people fill out the form badly.” Friction is information, not blame.

Workarounds Are Clues

A workaround may reveal unmet needs, but it may also preserve speed, care, trust, accessibility, or local knowledge. Ask what the workaround accomplishes before removing it.

• What problem does it solve?
• Who relies on it?
• What would break if it disappeared?
• Is it a fragile repair, a valuable adaptation, or both?

Preserve what works. A recommendation that removes a workaround without replacing its useful function can make the system worse.

Observations and Hypotheses

Keep what you saw separate from what you think caused it:

• Observation: “Three requests waited for a manager because the category was unclear.”
• Hypothesis: “The categories may not match the decisions staff actually make.”
• Follow-up question: “Which categories create uncertainty, and what context resolves it?”

Labeling a hypothesis protects trust and directs the next discovery step. Do not turn a plausible explanation into a finding without evidence.

Map Decision Loops, Not Job Titles

A job title is not an AI use case. A role may contain several decision loops, each with a trigger, required context, remembered state, judgment, action, feedback, repair path, and person who owns the consequence.

Some context is formal and recorded. Some is physical, social, historical, relational, or tacit. Missing context is a gap to investigate, not a reason to invent facts or expand surveillance. A person-dependent practice can be valuable and functional while still creating a resilience risk.

Recommendation Boundary

Before proposing change, state what the map supports and what it does not yet support. A useful boundary names:

• The process and perspective examined.
• The evidence collected and the gaps that remain.
• The observations that appear stable.
• The hypotheses that still need testing.
• The people, constraints, exceptions, and consequences not yet represented.
• The decisions that should wait.

Not every friction point is an AI opportunity. The map may support a better question, policy clarification, training change, staffing decision, form revision, handoff repair, tool change, or a decision to leave the process alone.

Practice

Choose one ordinary process and trace a single fictional or low-risk example through it. You do not need to produce a formal record.

1. State the beginning and end of the process.
2. Name one input, one transformation, and one output.
3. Add the actors, systems, and handoffs.
4. Mark one wait, exception, workaround, or rework loop.
5. Write one observation and one separate hypothesis.
6. State one thing the evidence does not yet justify recommending.

If the map raises more questions than answers, it is doing useful discovery work.

Reflection

• What did the real process do that the expected process did not?
• Which friction point carried useful information?
• What function did a workaround preserve?
• Which statement is an observation, and which is still a hypothesis?
• Which decision loop or missing context needs another conversation?
• What should not be recommended yet?

Tool Boundary

No AI or diagramming tool is required. If a tool helps transcribe, organize, or redraw discovery notes, treat its output as a draft to compare with the source conversation. Do not let generated labels, diagrams, summaries, or recommendations replace direct observation, participant correction, or accountable judgment.

Privacy Boundary

Use fictional, public, role-based, or sanitized examples. Do not expose employee performance details, client records, health or financial information, credentials, confidential processes, private communications, or another person’s information. Collect only the context needed for the agreed discovery boundary. Friction mapping is not permission to monitor people or expand surveillance.