A friction walkthrough is a timed, observed session where someone who has never used your security tooling goes from a clean machine to a fixed finding while you log every stall. It takes an afternoon, needs no new software, and shows problems that dashboards miss.
Why do it
Adoption metrics tell you how many people use a tool, not why others do not. Usage dashboards show a drop, but not the confusing error message that caused it. Watching one person work shows the cause directly. For the longer measurement view, see friction as a security metric.
Before the session
- Pick a participant who joined recently or works in a different stack from the tool authors.
- Prepare a clean environment: a new user profile, a fresh clone, a clean container, or a spare laptop.
- Choose a real task: "Add a dependency, open a pull request, and deal with whatever the tool says."
- Tell the participant to think aloud, and tell yourself not to help unless they are stuck for five minutes.
During the session
Keep a simple log with a timestamp and a note for each event. Mark an event whenever the person:
- Stops to search or ask for help.
- Re-reads a message.
- Tries something that fails.
- Makes a wrong guess about what a message means.
- Says a negative word out loud.
| Time | Step | Event | Friction? |
|---|---|---|---|
| 0:00 | Install | Followed the docs, worked | No |
| 0:09 | First scan | Error about a missing token | Yes |
| 0:21 | Read finding | Unsure if "high" blocks the merge | Yes |
After the session
Count three things.
- Time to first scan. From start to the first successful run.
- Time to first understood finding. From first scan until the person can explain the finding.
- Number of stalls. The count of friction events.
Then rank stalls by how many people would hit them, not by how annoying they were to the participant. Install and first scan stalls affect everyone. A rare edge case affects few.
Fix in this order
- Anything that blocks the first scan.
- Messages the person misread.
- Missing or wrong documentation.
- Slow steps that cause waiting.
- Cosmetic polish.
Re-run the same session with a different person in a month. If time to first scan drops and stalls fall, the changes worked. If not, you fixed the wrong things.
Things to watch for
Do not coach. Every hint hides a real problem.
Do not test with the tool's author. Expertise masks friction.
Do not stop at one person. Three sessions across two stacks are enough to find the common problems.
Do not skip the pull request step. Many tools work in the editor and confuse people in review.
What to share
Publish a short summary: what you tested, the three biggest stalls, and the fixes you committed to with dates. Developers see that feedback leads to change, which makes the next round easier to schedule.
Safeguard's free scan at gold.safeguard.sh/scan is a useful low-effort first task for the walkthrough, since it needs no install.
Quick check
How many participants do we need?
Three is enough to surface the common problems. Pick people from different stacks and experience levels.
Can we do it remotely?
Yes. Use screen sharing, ask them to think aloud, and record with permission.
Last reviewed: 19 October 2026.
