You walk it through your software once, page by page, talking the way you would to somebody on their first day. It watches, asks, and writes a record of every screen — including the parts nobody has ever written a help article about.
The difference is that this one writes everything down, does not forget it in a month, and is not going to leave.
A screen share and a voice line, with someone from your team who knows the software. Not a form to fill in and not a spreadsheet of URLs — the actual application, signed in, with real navigation.
It sees the page and hears what you say about it. Where you explain something the screen does not show — a rule, a gotcha, why that field is disabled — the explanation is captured as taught, and outranks anything it worked out alone.
A record per screen, written as you leave it rather than all at the end — so if the call drops, nothing you have already covered has to be covered again.
One of them tells you what somebody wrote down. The other tells you what is actually there — including everything nobody got round to writing.
One record per screen of your product. The last two are the ones a summary of your help centre can never produce, because nobody wrote them down to be summarised.
Its job, who lands on it, where it sits in your product and what they arrived trying to finish.
Each control, what it does, and what state it is in — including the ones that are disabled and the reason they are.
What happens before this screen and after it, and which of the several routes through it is the one you intend people to take.
The rules and behaviour the screen reveals — limits, formats, what happens on failure. Most of this is nowhere in your documentation.
Stated explicitly, because half of support is somebody trying to do a thing on the wrong screen. Knowing where a path ends is what lets it redirect instead of guessing.
The open questions, kept as questions. A gap is never quietly turned into an answer — and this list is usually the most useful thing in the whole record.
Not through negligence — these are the things that are obvious to everyone who built the product, which is exactly why nobody documents them.
A button greyed out because the account is on the wrong plan, or because a previous step is incomplete. The screen shows the state and never the reason.
One of them is the one you intend people to take. Nothing on the screen says which, and every support conversation about it starts from the wrong one.
A row cap, a file size, a rate. Written down in your code and in nobody's help centre, and responsible for a surprising share of your tickets.
Your documentation still calls it the old name. So do half your customers. Something that has actually looked at the screen knows both.
Which is what lets it prefer what your team said over what it worked out — and refuse to hand a customer a guess with the confidence of a fact.
Somebody on your team explained it out loud. It outranks everything else, because it is the only one that carries intent — why the field is disabled, what the rule is for, which of two paths is the one you meant.
Directly visible, or stated on the page in so many words. A number printed on the screen is something it saw, not something it thinks — and it is recorded as the first, so it can be answered with confidence.
A reasonable reading of the evidence, marked as one. Anything worked out rather than seen or heard is at most this, and it stays that way — so it never gets quoted back to a customer as fact.
Carried over from an earlier walk and not looked at again this time. It never gets promoted back up — something that was true in March and was not checked in August is exactly as trustworthy as that sounds.
Something printed plainly on the screen is never filed as a guess, and the record is never allowed to ask a question it has already answered somewhere else. A label can be raised when the evidence gets stronger; nothing ever quietly promotes itself.
Every walk ends with a list of things only somebody on your team can settle. They stay open until one of you answers them, and then they close on their own.
Examples, in the shape the record actually takes. Questions like these never become answers on their own — answer one and it closes; leave it and it stays a question.
Good — that is the objection worth having, and it is the reason a walk is an afternoon rather than a project. You do the screens that changed, not the whole product again.
The four screens the release touched, not the forty it did not. What you cover is re-recorded; what you skip is marked as not looked at this time.
Anything carried over from an earlier walk keeps that label for the rest of its life. It is still used, and it is never used as though somebody just checked it.
When a screen changes and nobody re-walks it, your customers find out first — and what they run into feeds back as something worth looking at.
No engineering time, no data export, and nothing to prepare in advance.
Somebody who knows the product well enough to explain why things are the way they are. Usually support, sometimes the founder.
Signed in, with data in it. An empty demo workspace teaches it what an empty demo workspace looks like.
Less for a small product. You can stop and come back — nothing already covered has to be covered twice.
You will know within one page whether it understood your software. That is a faster evaluation than any trial you have run this year.
A map with nobody to ask. A conversation with nothing to draw on. A memory of a product it never learned. The system is the point.
A conversation inside the product, on the screen they are stuck on — spoken, and able to see what they are looking at.
read the page →Where it stops. It says it does not know, refuses the three subjects you never want answered, and promises nothing it cannot keep.
read the page →It walks your product screen by screen and writes down what it found, in a 22-section record per page — including what it could not establish.
you are hereYour maps and docs compiled into things it knows, held at two grains so a single fact inside a long document can still be found.
read the page →What it handled, what it learned, what it could not answer, and which accounts have gone quiet — for the people who own the product.
read the page →Where you set what it is, how it speaks, what it must never touch, and which pages it appears on. Settings that become instructions.
read the page →Your users are already having the conversation. Right now it is with nobody.