How Much Time Do You Actually Lose Switching Between Projects on a Mac?
TL;DR
In a June 2006 Gallup interview, Gloria Mark reported that work interrupted and resumed on the same day was resumed, on average, after 23 minutes and 15 seconds, with about two intervening tasks. This measured time to task resumption, not a universal delay until full focus or 23 minutes of inactivity. That finding does not establish a fixed cost for each app or project switch, or show that workspace software removes it.
What the 23-minute number actually measured
The figure is reported in Mark’s June 2006 Gallup interview, not the 2008 CHI paper. It concerns interrupted work resumed on the same day, with about two intervening tasks, rather than time to regain full focus.
A separate line of research looked at who's actually worse at handling interruption and switching in the first place. Ophir, Nass, and Wagner's Stanford study compared self-identified heavy and light "media multitaskers" and found heavy multitaskers were more susceptible to interference from irrelevant environmental stimuli and irrelevant information already in memory (Ophir, Nass & Wagner, 2009, PNAS). Worth noting: that finding has had a mixed replication record since - later studies didn't consistently reproduce the original switch-cost effect, and some found the opposite pattern in certain tasks (Cyberpsychology meta-analysis, 2020). Use it as evidence that heavy multitasking habits can correlate with worse filtering, not as a settled law.
Why a shared Mac desktop keeps re-triggering the cost
Both studies are about interruptions and switches that already happened. The practical question for someone managing multiple projects on one Mac is upstream of that: how many potential triggers are sitting on your screen at any given moment? If unrelated projects are open together, you may want to separate them to reduce distractions. That is a practical suggestion, not evidence that every switch restarts a 23-minute recovery period.
What a shared, unmanaged desktop actually costs you
Every open unrelated app is a standing decision point. You don't have to click it to pay part of the cost - noticing it and choosing not to click is itself a small tax.
Manual cleanup between projects is its own interruption. Closing twelve tabs and quitting three apps before opening the next project's set is a task-switch in itself, with its own resumption cost for whatever you were doing before you started cleaning up.
Because cleanup is annoying, most people skip it. The result is a permanently cluttered desktop that recreates the original problem instead of solving it.
Removing the trigger instead of managing around it
Batching similar tasks and asking "can this wait 25 minutes" are reasonable coping strategies for interruptions you can't prevent - a colleague's question, an unplanned call. They don't address self-inflicted switching caused by simply having every project's apps and tabs visible at once, because the trigger there isn't a person asking something, it's your own screen.
Ikuna addresses that specific trigger. A context defines the apps, browser tabs, and window layout for one project; switching into it quits or hides everything that isn't part of it, and switching back restores your exact prior state. Instead of a manual, error-prone cleanup between projects, the switch is a single action - so the environment stops being a source of unplanned interruptions in the first place, rather than something you have to resist every few minutes.
Comparison: coping with interruptions vs. removing the trigger
ApproachWhat it addressesWhat it leaves untouchedBatching tasks / the "25-minute rule"External interruptions you can deferSelf-inflicted switching from open apps/tabs you can see right nowManual desktop cleanup between projectsRemoves clutter, eventuallyCosts time and focus itself; usually skipped under pressuremacOS Spaces / Stage ManagerGroups or separates windows already openDoesn't quit apps or restore a saved multi-app stateIkunaRemoves/hides unrelated apps and tabs per project, restores prior state on returnDoesn't defend against externally-initiated interruptions (calls, questions)
FAQ
Does the 23-minute figure apply to every kind of switch equally?
The interview describes interrupted work resumed that day, not a fixed delay by switch type. Do not apply the mean to every tab check, meeting or project switch.
Is multitasking really impossible, or just less efficient?
For genuinely complex cognitive tasks, what looks like multitasking is almost always rapid serial switching rather than true parallel processing - the Stanford research on heavy multitaskers is about how well people filter and manage that switching, not about whether simultaneous deep cognition is possible.
Will removing open apps and tabs eliminate context-switching costs entirely?
No - it removes the self-inflicted, environment-driven switches. Externally initiated interruptions (a real emergency, a colleague at your desk) still carry a resumption cost; environment design reduces one major source, not all of them.
How is this different from just closing tabs manually every time I switch projects?
The mechanism is the same - remove what doesn't belong - but manual cleanup has to be redone from memory every time and is easy to skip when you're busy. A defined context makes the removal (and the restoration) a single repeatable action instead of an ad hoc chore.
Sources
Gallup (8 June 2006). Too Many Interruptions at Work? Interview with Gloria Mark. (Reported: interrupted work resumed on the same day, mean time to resumption and intervening tasks.)
Ophir, E., Nass, C., & Wagner, A. D. (2009). Cognitive Control in Media Multitaskers. Proceedings of the National Academy of Sciences, 106(37), 15583-15587. (Directly tested: self-reported heavy vs. light media multitaskers on filtering and task-switching tasks; later replication record is mixed.)
Cyberpsychology: Journal of Psychosocial Research on Cyberspace (2020). "Cognitive Control in Media Multitaskers" Ten Years On: A Meta-Analysis. (Directly tested: aggregate replication attempts of the 2009 finding.)
