The Spinning Beachball Problem

What organizations get wrong when they decide what users can and cannot do

When a Chromebook encounters a program too demanding for its hardware, it refuses to run it. When Apple's lower-cost laptop encounters the same problem, it runs the program anyway — just slowly. A user watching the spinning beachball indicator knows exactly what is happening: the machine is trying, struggling, and may or may not succeed.

This design divergence, apparently trivial, encodes a meaningful organizational decision. The Chromebook manufacturer decided to protect the user from a bad experience. Apple decided to let the user have it. Both choices carry costs.

The question organizations rarely frame correctly is not "should we support exploration or deflect it?" The question is: what commodity can we and our users actually spare?

Every product interaction involves two scarce resources: time and compute. On-product time — the user engaged, exploring, and building familiarity — has value that is easy to underestimate because it does not appear on a balance sheet. Compute, by contrast, has a cost that is easy to see. When an organization hits a constraint, it faces a tradeoff between absorbing that cost on behalf of the user or deflecting the user off-product to solve the problem elsewhere.

The deflection appears cheaper. It is often not. A user bounced off-product must be re-acquired. Re-acquisition carries its own costs: marketing expenditure, support load, the probability that the user finds an alternative and does not return. The Chromebook saves compute. It spends user goodwill, which is harder to restore than RAM.

The commodity the user can spare matters as much as the commodity the organization can spare. A younger user or one without budget for alternatives may have abundant time and limited options — the spinning beachball is tolerable because the alternative is worse. A time-pressed professional with ready substitutes will not wait. Organizations serving regulated industries or captive user bases often miscalculate here: they assume deflection is acceptable because the user has no immediate alternative. That assumption holds until it does not.

The failure mode of the hard cap — the Chromebook approach — is not that it protects the user from a bad experience. It is that it provides no path forward. Telling a user that something cannot be done, without telling them what would need to change for it to become possible, spends the user's time on a dead end. The cost of that dead end is not always recovered.

The failure mode of unlimited tolerance — the spinning beachball approach — is different: when the system actually fails, it takes user data and trust with it. There is a floor below which exploration should not be permitted, and it is defined not by what the system can technically attempt but by what failure at that point would cost the user.

The correct frame is not permissive versus restrictive. It is: what does it cost to absorb this, what does it cost to deflect it, and who bears each cost. Organizations that answer that question honestly design products accordingly. Those that answer it by default — by building hard caps because caps are easier to implement, or by tolerating all load because restriction feels hostile — pay the difference in ways that rarely appear in the original calculation.

The beachball spins. The question is whether anyone budgeted for what happens next.

What we’re into this week

Scott

Well, I’m clearly going plug for the article that kicked off all this discussion, Sam Gold’s This Is Not the Computer For You. I didn’t think so much angst would be generated by it, but as the kid who would sit through the spinning beach ball to get what I wanted out of a CPU, I totally empathize with Gold’s position.  

Aaron

I come at this from a data background, so I’m recognizing that there’s a vast difference between a defined problem that I want to solve, which is usually my perspective, and an exploratory project in which the answer could be any one of many acceptable permutations. I reacted to this article similarly to the way the IMF reacted when it recently found out that ChatGPT is really bad at economics…and for the IMF, this is a huge problem. If ChatGPT had a warning that said something like “we know our predictions are crap”, this wouldn’t have happened.

Ana

Yeah, I agree, these seem like two very different applications of products: in one, it’s the challenge of the build that’s important. In the other, it’s the accuracy of the answer that’s important. This is not a nuance I see many organizations getting into, however. Case in point: Killed by Google. Google: a company so smart it’s literally become a verb, and yet a company so perplexed at its own output that it keeps having to pull things down with no explanation or offramps whatsoever.  🙃

Credits

Host: Aaron Meyers
Guest: Ana Monroe
Producer: Ana Monroe
Article: A. Adams
Artwork: Ladies and Gentlemen Enjoying a Dutch Garden. 1739. Cornelis Pronk. Via the National Gallery

Why this artwork?
The obsessively tidy style of the Dutch garden in Pronk’s rendering reflects the user experience crafted by so many organizations. In an environment that could literally grow in all directions, organizations take great care to keep their users on designated paths. While this strategy works most of the time, it limits the user’s ability to understand the product layers and possibility, as, indeed, it limits the organization’s.