A6.09.6Teaching methods don't transfer across memory systemsresearchdesign

Procedural and declarative memory are separate systems, so teaching methods don't transfer between them

Aliases: knowing how versus knowing that · procedural versus declarative learning

What it is

"Explaining something clearly" and "teaching a motion" run on two different learning mechanisms, and forcing the method suited to one system onto the other noticeably underperforms. Declarative memory — remembering a fact, a rule — can be established quickly through a single explanation or reading. Procedural memory — learning to execute a sequence fluently — mainly forms through repeated practice with feedback, and simply explaining the underlying logic once doesn't by itself make someone able to perform it. A common product mistake conflates the two: assuming that if the steps are written clearly and explained well, users will come away able to operate fluently. In reality, explanation builds "knowing what's going on," which is a whole practice process short of "being able to do it smoothly."

Why it happens

Declarative learning is fundamentally about forming associations between facts or concepts, and a single clear presentation is often enough for that association to be encoded and later retrieved through recall or recognition. Procedural learning follows a completely different path: it requires actually executing the action, receiving feedback on the outcome, adjusting the next attempt, and cycling through this repeatedly to gradually compress "knowing what to do" into the automatized representation that lets someone act without thinking. Mere exposure to an explanation doesn't trigger this compression process — explanation can give a user declarative knowledge about the task's goal and general logic, but that knowledge and the procedural representation that actually drives fluent execution are two different things, and establishing the former doesn't automatically produce the latter.

Studying it

A common way to compare the effectiveness of the two teaching approaches is to give different groups either "explanation only, no practice" or "explanation followed by several rounds of feedback-driven practice," then measure each group's performance on declarative questions about the task's logic separately from the fluency, speed, and error rate of their actual execution. Studies like this typically find little difference between groups on the declarative questions but a substantial gap in operational performance — explanation alone produces limited gains in operating ability, and practice is what actually closes the gap.

Where it stops holding

This doesn't mean explanation is useless for procedural learning — using it before practice begins, to help a user understand the task's goal and general logic, can give practice more direction and reduce blind trial and error, playing an organizing and focusing role even though it can't substitute for the practice itself. Conversely, teaching purely factual knowledge through heavy repetitive drilling is also inefficient — a direct, clear explanation is usually faster than repeated rehearsal. The point of this boundary is that which method to teach with depends on which kind of memory the goal actually targets, not that either method is the safer default for every goal.

Applying it

  • Before designing onboarding, decide what the actual goal is: if it's getting users to execute a sequence fluently (a gesture, a shortcut, a multi-step workflow), the core of the teaching should be guided, feedback-driven repeated practice, not a document that lays out the steps clearly — a document can only build declarative understanding, not fluent execution.
  • If the goal is just letting users know a one-time fact or what a setting means, a clear explanation or tooltip is enough; there's no need to force it into a repeated-practice teaching flow, which would only add unnecessary friction.
  • For actions that genuinely need to be practiced to fluency, schedule at least a few rounds of real attempts with immediate feedback (success confirmation, error correction) after the explanation, rather than assuming the explanation alone means the user has learned it.
  • Verification: test users who only read the instructions against users who additionally did a few rounds of feedback-driven practice, comparing their time and fluency on the actual operation. A clear gap between the two groups confirms the action genuinely depends on procedural learning, and explanation alone won't get users to the target performance.

Related

  • Same group: A6.09.1 Action sequences can be automatized into unconscious execution · A6.09.2 Automatized actions are extremely sensitive to interface change · A6.09.3 Forcing an automatized user to verbally describe their steps disrupts fluent execution · A6.09.4 Procedural memory resists forgetting and amnesic impairment better than declarative memory · A6.09.5 Automatized skills decay far more slowly than factual knowledge
  • Nearby: A6.06 Forgetting curve
  • Search terms: procedural versus declarative learning · learning by doing · feedback-driven practice

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/A6.09.6