Friction log: meaning and application

When a new system, a campaign or a change is introduced, the same questions, doubts and snags keep coming back, but they disappear into inboxes, helpdesk tickets and scattered conversations. A friction log records them continuously in one place, with a label for each entry. This shows which resistance recurs and where you can make targeted adjustments.

A friction log is a continuous record of the questions, objections and blockers that people raise during a process such as an implementation, a campaign or a change. Each entry is labelled, so that patterns in resistance become visible and you can make targeted adjustments.

The friction log is a Neurofactor working tool, not a validated measurement method. It builds on documented practices: voice of the customer, friction in user experience, issue logs and qualitative coding. It shows what is said and when, not how common something is across the target group.

The friction log is not a scientific concept with its own original publication; Neurofactor uses the term for a working tool it applies in projects. In software practice, the term has a narrower meaning: someone works through a product step by step and notes every snag. That practice is mainly described in practitioner blogs and is not used as evidence here.

The tool draws on four documented related practices:

• Voice of the customer. Griffin and Hauser describe how to identify, structure and prioritise customer needs, and point to a self-selection bias in common satisfaction measures (Griffin & Hauser, 1993). A friction log also collects the voice of the target group, but spontaneously and during a process.
• Friction in user experience. Nielsen Norman Group, a user experience consultancy, defines interaction cost as the sum of the mental and physical effort users must make to reach their goals (Budiu, 2013). This is a practitioner publication, not peer-reviewed research.
• Issue logs. In programme and project management, an issue is any matter that needs to be brought to the attention of the project. A risk may still occur; an issue is already present. Issues are recorded in an issues log to track their resolution (Department of Finance, 2024).
• Qualitative coding and thematic analysis. Braun and Clarke describe six phases, from familiarising yourself with the data through generating codes to naming themes (Braun & Clarke, 2006). This is the methodological basis for labelling.

These sources describe related practices; they do not validate the friction log as a whole.

A friction log holds three kinds of entries. A question is a need for information. An objection is an expressed doubt about usefulness, risk or feasibility. A blocker actually stops someone, such as missing permissions, a technical error or no time for training.

For each entry, Neurofactor records seven fields:

An owner and action are often added. Verbatim wording matters most: a summary such as 'unclear about login' loses the tone and word choice you will later want to echo.

Labelling is coding: you give each entry a short description that captures its essence. Neurofactor follows the logic of thematic analysis here. Braun and Clarke distinguish an inductive approach, in which codes emerge from the data themselves, from a theoretical approach that starts from a framework chosen in advance (Braun & Clarke, 2006).

A friction log combines both. You start with a small initial scheme that fits the process, such as access, explanation, time, trust and usefulness. Entries that do not fit get a new code. After the first few weeks, you merge or split codes and define each label briefly, which keeps labelling consistent across people.

Labels describe entries, not people. 'Objection about data security' is a label; 'sceptical user' is a judgement about a person and does not belong in the log.

Analysis starts by asking which labels together form a theme. According to Braun and Clarke, the importance of a theme does not necessarily depend on how often it occurs, but on what it says about the question you want to answer (Braun & Clarke, 2006). So look at three things at once:

• Recurrence. Does a label recur across sources and moments?
• Severity. How many entries actually block people? Nielsen describes the severity of a usability problem as a combination of frequency, impact and persistence (Nielsen, 1994). That practitioner publication concerns usability problems, but the principle carries over: frequency is one factor, not a verdict.
• Shift. Does the pattern change per phase or after an intervention?

A rarely reported theme that blocks everyone it affects may outweigh a common question that one sentence resolves.

A friction log only works if findings reach the right people. Neurofactor agrees the rhythm per project. In intensive phases, such as the first weeks after go-live, a short weekly update with the main themes and actions fits. After that, a fortnightly or monthly overview often suffices. Serious blockers go straight to the owner.

Reporting back works both ways. The project team hears which themes are in play and decides what to adjust. Reporters hear what happened to their signal, for example through an updated instruction. This rhythm is a working agreement, not a researched standard.

The tools complement each other: an FAQ can grow out of a friction log, and a survey can test how widely a theme is shared.

Objections in a target group profile describe the doubts typical of a target group; a friction log is the continuous record from which you derive and update them. The resistance type, covered in a separate forthcoming article, is about the kind of resistance. The friction log supplies observations for it, not a classification of people.

1. Define the process and the question. What are you following, and which decisions should the log support?
2. Choose the sources. Agree which channels supply entries and who enters them.
3. Fix the fields. Use the seven fields; keep the form short.
4. Draw up an initial labelling scheme. Five to eight labels with a short definition are enough to start.
5. Agree the rhythm. Decide when you analyse, who reports back and what needs immediate action.
6. Review the labels after the first weeks. Merge, split and record changes.
7. Close the loop. Record per theme which action followed and whether entries then fell or shifted.

This example is fictional. The entries are illustrations, not research findings.

Situation. A software company replaces its support email with a customer portal where customers create tickets, download invoices and read documentation. The rollout takes place in three waves.

Decision question. Where does the switch stall, and what should change before the next wave?

Available information. Helpdesk conversations, webinar questions and account manager signals.

Suitable approach. The team sets up a friction log with the seven fields. Three example rows:

Possible interpretation. Access and customer policy stand out: both block people, though they occur less often than questions about usefulness. The team does not know how many customers share these problems: only reporters are visible.

Next step. Before wave 2, the team adjusts the activation procedure, writes guidance for customers' IT departments and surveys a sample of wave 1 customers about the switch.

A friction log easily ends up containing personal data, such as names, email addresses or traceable quotes. The General Data Protection Regulation (GDPR) requires personal data to be adequate, relevant and limited to what is necessary for the purpose, and kept in identifiable form for no longer than necessary (Regulation (EU) 2016/679, Article 5).

In practice: note the role rather than the name, strip identifying details from quotes, keep contact details for follow-up separately and only as long as needed, and agree a retention period. This is not legal advice; check the details with the organisation's privacy officer.

• Reading entries as prevalence. People who speak up are not representative. Research on online product reviews shows that people with pronounced experiences are especially likely to respond (Hu et al., 2017). A friction log is similarly prone to self-selection. Many entries about a theme therefore do not tell you what share of the target group has the problem.
• Confusing frequency with severity. A frequently asked question can be harmless; a rare blocker can halt the switch for an entire group.
• No feedback. Without visible results, people stop reporting and friction seems to vanish while it remains.
• Reading silence as agreement. Groups that seek little contact stay invisible; supplement the log with targeted conversations or a survey.

A friction log turns scattered questions, objections and blockers into a working list that reveals patterns. Neurofactor uses it in projects to make targeted adjustments, with fixed fields, an evolving labelling scheme and an agreed feedback rhythm. The log shows what is going on and in which words, but not how widespread it is. For that, you need additional research.