Narrating What You Are Doing
The only verification available to the person watching. How to do it so it informs rather than bores.
The person cannot check what you are doing. Telling them is the substitute, and done well it is the difference between support and an intrusion they tolerated.
The practical lesson in “Narrating What You Are Doing” is to make responsibility visible without confusing visibility with certainty. A team reviewing visit the official site for time tracking with screenshots can add structured time and project context, provided the purpose is disclosed and the interpretation is checked with the people affected.
What to say
Where you are going and why, before you go there.
For an independent reference related to “Narrating What You Are Doing”, consult the ENISA cybersecurity resources; it provides a useful external check on security, privacy and operating assumptions before a process is adopted.
What you found when you got there.
What you are changing, and what effect it should have.
Three beats per step, each a short sentence.
The level
Plain terms, not jargon, and not baby talk.
"I am looking at which programs start when you turn it on, because that is usually why it is slow" is right.
"Checking the startup items" tells them nothing. "I am going to have a little peek at your computer's brain" is worse.
What not to do
Narrate the obvious while skipping the significant — commenting on the weather while silently changing a setting.
Use terms that describe nothing: "running diagnostics", "cleaning up".
Or go quiet during the part that matters, which is when people become uneasy and are right to.
Silence is the signal
A long pause with the pointer moving is the thing people report as uncomfortable.
If you need to concentrate, say so: "I need to read this for a minute, nothing is happening."
One sentence removes a minute of unease.
Explaining a command line
Terminals look alarming and are the most common source of alarm.
"This lists what is installed, nothing is being changed" covers it.
And where you are changing something, say what, because a command somebody cannot read, run silently, is indistinguishable from an attack.
The teaching version
Where it is appropriate, narrate so that they could do it themselves next time.
It takes a few seconds more and it converts a ticket into something that does not recur.
Not always appropriate and worth doing when it is, particularly with family.
At the end
Summarise: this was wrong, this is what I changed, this is what to watch for.
In two sentences.
That summary is the only durable record most people have of what happened to their machine, and without it the session leaves nothing behind.
Why this matters beyond courtesy
A person who has been narrated to knows what a normal session sounds like.
Which means they notice when a later one does not.
Good narration is, among other things, an inoculation, and that is the strongest argument for doing it consistently.
What to check
Do you narrate, or only answer questions?
Do you go quiet during the significant parts?
Could the person repeat back what you did?
And do you summarise at the end?