Breaking down something automatic into manual steps is mostly a waste of time until you hit an edge case
Tying shoes task analysis is the process of taking a skill that most people do without thinking and breaking it into discrete, observable steps. You write them down. You test them. You make sure no one accidentally skips the part where you cross the laces or the whole thing unravels after three minutes of walking. I spent about a week mapping out a shoelace task analysis for a vocational rehabilitation program. We had a student who had full range of motion in both hands but couldn't tie knots reliably. The existing curriculum just said "practice tying shoes" and called it a day. That didn't work. So we did the analysis and found the problem wasn't the shoe-tying itself. It was that he was consistently releasing the left loop too early, before the right loop was pulled through tight. One micro-step was causing the entire sequence to collapse.
Tying Shoes Task Analysis
The standard approach works like this. You pick a performer and watch them do the task from start to finish. Not once, multiple times, under different conditions if possible. Then you write out every physical action in order, starting from having untied shoes on the floor and ending with both shoes tied and ready to walk in. Each step needs to be something you can see and measure. "Make a knot" is not a valid step because two people will interpret that differently. "Hold the left lace between thumb and forefinger of the left hand" is valid. The actual steps look roughly like this. Sit down with shoes on feet or place shoes on a flat surface. Touch the aglets of one lace with each hand. Cross the left lace over the right lace to form an X. Push the left lace under both right and left laces and pull both ends tight to form a basic knot. Take the right lace and fold it into a loop, pinching it at the center with thumb and index finger. Take the left lace and wrap it around the base of the right loop. Push the left lace through the small hole created below the wrap and pull tight to form a bow. Adjust the loops and ends evenly. That looks simple because it is simple for someone who can do it. The value of a task analysis isn't in describing what happens. It's in catching the steps where someone actually gets stuck. I've seen task analyses for this exact skill where the writer completely forgot to include the step of maintaining tension on the initial knot while forming the second loop. That omission meant half the people following the instructions would have their knot unravel before they even started the bow. The student would think they were doing something wrong when actually the instructions were missing a dependency.
Here's the counter-intuitive part that beginners miss. A perfect task analysis for tying shoes is almost never useful for the person who already knows how to tie shoes. The person writing the analysis has procedural memory that operates below conscious awareness. They will skip steps they don't even know they're doing. I had to have my student record a video of himself tying his shoes from an overhead angle because his verbal description of what he was doing was completely unreliable. He thought he was forming the loops correctly. The video showed he was twisting one loop against his palm instead of holding it flat. That twist was invisible to him but catastrophic for the knot integrity. Another thing people get wrong is the level of granularity. Some analysts write steps so detailed they become unusable. "Move right hand toward right aglet" is a step nobody needs. Other analysts write steps so vague they're useless. "Tie the shoe" counts as zero steps in a proper analysis. The sweet spot is usually around 8 to 15 steps for something as routine as tying shoes. If your analysis has 40 steps, you're overcomplicating it. If it has 5, you're skipping important dependencies. The real bottleneck in task analysis is observer bias. You see what you expect to see. I once reviewed a task analysis written by a trainer who had been tying shoes since he was four years old. He wrote "pull both loops tight" as a single step. When I asked him to demonstrate it slowly, he pulled one loop, then the other, then adjusted them. Those are three distinct motor actions. His analysis compressed them into one because his nervous system had automated the sequence. The student he was training needed to see those as three separate steps. This is why you always validate a task analysis against someone who actually can't do the skill, not against another expert.
Get the Full Details
There are tools that help. I've used ABC Data sheets for step-by-step data collection, which track whether a learner completes each step independently, with physical prompt, with verbal prompt, or not at all. You can also use a simple checklist format where you mark each step as mastered or not. The choice depends on whether you need fine-grained prompting data or just a pass-fail check. For shoelace tying, I prefer the checklist because the skill is short enough that detailed prompt data doesn't change the intervention much. One edge case I ran into that took me three sessions to resolve involved a student with tremors in both hands. The standard task analysis assumes steady fine motor control when forming the loop and wrapping the lace. This student's hands would shake enough that the loop would collapse before he could wrap the second lace around it. The workaround wasn't to teach him a different tying method. It was to add a step where he uses his non-dominant hand to hold the loop in place while his dominant hand does the wrap. That extra hand-off step turned an impossible sequence into a manageable one. The original analysis would have failed him completely because it assumed bilateral hand coordination that he didn't have. Another common failure mode is assuming both feet are the same. A student might tie the right shoe using a mirror-image version of the left shoe steps and never realize it because the analysis didn't specify left versus right throughout. I've seen analyses that just say "take one lace and make a loop" without specifying which lace. On the left shoe, that means the right lace. On the right shoe, it means the left lace. If you don't track that, the student gets confused halfway through and the knot comes out asymmetric or not at all.
Task analysis also breaks down when the environment changes. Tying shoes on a wobbling chair in a busy classroom is a different motor task than tying them at a still table in a quiet room. I had a student who could tie his shoes perfectly during one-on-one sessions but couldn't do it during group time. The distraction wasn't cognitive. It was that someone would bump the table and his fine motor output degraded. The fix was adding environmental mastery as a separate phase, not as part of the initial skill acquisition. If you're building a task analysis from scratch, start by video-recording a competent performer and a struggling performer side by side. The differences between them tell you where the analysis needs to be most precise. Write the steps in plain language that a 10-year-old could follow without ambiguity. Test it on someone who can't do the skill and watch where they hesitate or make errors. Revise. Test again. The first version is always wrong in ways you didn't anticipate. The whole process for a simple skill like tying shoes usually takes me about 3 to 5 hours from initial observation to a tested, revised analysis. That includes the video review, drafting, pilot testing, and revision. A more complex skill like brushing teeth or fastening a button can take 8 to 12 hours because there are more variables and more potential failure points. Don't rush the testing phase. A task analysis that hasn't been validated against an actual learner is just a guess dressed up as a procedure.
There's no downloadable template that covers this well because every learner is different. But the framework is straightforward enough that you can build your own in a spreadsheet or on paper. The columns you need are step number, step description, mastery criteria for each step, prompt level needed, and error type if the step is failed. That's it. Nothing fancy. The structure does the work, not the tool.
