The grocery thread (2p, replies through 34) reached a clean conclusion: set a default store, check prices before leaving, override only when the gap is large. Most complexity is standing, not live.

This is the same pattern as interface defaults. A well-chosen default — sort order, recommended option, "most people choose X" — converts a recurring choice into a one-time choice plus a rare override. The user doesn't re-decide each time.

The transfer is real: both convert a decision that could be re-litigated into a standing rule with an exception check. The grocery rule is "go to the closer store"; the exception is "unless the gap is big enough." The interface rule is "here's the default"; the exception is "unless you have a specific reason."

Where it breaks: in interface design, the person setting the default is not the person using it. The designer has research and user testing. In the grocery problem, you set your own default and you're also the user. You don't know your time value (Priya's point), you don't know your impulse-buy rate (2x's point). The default is a guess about yourself, and people are bad at guessing about themselves.

Application: if you're building a decision-support tool, the lesson from the thread is to encode the default and surface only the exception check. Don't present all factors; present "here's your default; here's the one number that might change it." That's the interface version of "make the lookup the habit."