Critical-path analysis explains why removing steps did not make the task faster

What it is

Removing a button, cutting a click, or merging a form does not necessarily shorten total time, if the removed activity was already running in parallel with waiting, perception, or another necessary activity, or if the new path introduces a longer bottleneck elsewhere. Critical path analysis separates "number of steps" from "finishing time." This card is where the previous four cards' logic finally gets applied, and it is the phenomenon teams find most confusing and most in need of this analytical tool to explain — a redesign that clearly looks leaner, yet real measured time barely budges, and the answer is usually hiding in the distinction between the critical path and everything off it.

Why it happens

If the removed step originally sat on a non-critical branch, tucked inside the slack of a system response or another activity, then the time saved by removing it was never actually counted toward the finishing moment in the first place — whether it stays or goes, the task takes the same amount of time either way. This is exactly the logic of "shortening a non-critical-path operation does not change total time" showing up directly in a redesign scenario. A more easily missed case is different: reducing steps sometimes carries a hidden cost — merging two previously separate operations into one can lengthen the cognitive interpretation time a user needs to understand the new combined step, or raise the error rate and trigger more error-recovery flow. Once that new cognitive or recovery cost lands on the critical path, the bottleneck has simply moved from "number of clicks" to "understanding and recovery," even though the step count looks lower — total time may not shorten at all, and can even grow. An interface that visually shortens the path but requires the user to wait through a longer load is the same kind of bottleneck shift — the user sees fewer steps, but the chain that actually determines the finishing moment has a longer wait baked in; perceived simplicity and actual duration are two entirely different things. The only way to see clearly which of these is happening is to redraw the dependency graph before and after the change and measure exactly where the new critical path lands.

Where it stops holding

Fewer steps not making the task faster does not mean the redesign has no value — fewer steps usually also mean a lower error probability, a shorter learning curve, and lighter perceived load, all goals worth pursuing independently of "completion time," and a redesign should not be dismissed outright just because critical path analysis shows total time unchanged. What genuinely needs clarifying is the frame of judgment: if the redesign's goal was specifically to make the task finish faster, then critical path analysis showing "time unchanged" is a signal that must be taken seriously, and the bottleneck's new location needs tracking down; if the goal was reducing error and cognitive load all along, unchanged time is actually the expected, normal outcome. Also, an average completion time measured from a small user sample can mask the real picture: different users may have genuinely different critical paths, and an average can let "some users got faster, some got slower" cancel each other out, appearing unchanged overall while actually hiding a real bottleneck shift.

Applying it

• Draw a complete activity dependency graph both before and after a redesign, marking each version's critical path, bottleneck location, and each activity's slack, and compare the two side by side rather than judging by the impression of "it looks a lot simpler now."
• For every step that was removed or merged, explicitly record whether it sat in parallel slack before the redesign and whether it was covered by another activity's wait time — this determines whether removing it actually meant anything.
• Use timestamped operation logs to locate where real waiting and cognitive pauses actually occur, rather than counting a surface metric like click count alone — fewer clicks does not mean less cognitive or waiting cost.
• How to check: report completion time, error rate, learning cost, and subjective satisfaction together after a redesign, not time alone — if time is unchanged but the other metrics improved, the bottleneck genuinely lies elsewhere, and the change is still a worthwhile trade-off, not a failed optimization.

Related

• Same group: B4.13.1 Perceptual, cognitive, and motor resources can be occupied in parallel during skilled performance · B4.13.2 Total time is determined by the critical path, not the sum of all operation times · B4.13.3 Shortening an operation off the critical path does not change total time · B4.13.4 The model applies only to highly skilled performance; novice behavior is not parallel
• Nearby: B4.12 Keystroke-Level Model and Operator Constants · I1 State, Time, and Response
• Search terms: bottleneck shift · step reduction · critical path analysis · hidden slack