Have you ever meticulously set up a new, “simpler” system for your kids—a toy bin, a chore chart—only to watch them completely ignore it? You’re left scratching your head, thinking, “But it’s right there! It’s so easy!”
This is a classic real-world example of a powerful psychological principle: The Curse of Knowledge. As product people and creators, we are so intimately familiar with our solutions that we find it nearly impossible to imagine what it’s like to not know. In UX terminology, this translates to Assuming User Context—a blind spot where we project our own environment, knowledge, and workflow onto our users.
This exact scenario played out for me in a fascinating way this past season. For 5 years, our platform had a simple “Upload Photos” button. We tried different designs, placements, and labels, yet a significant portion of our kindergarten teachers—our primary users—were still using a clunky, time-consuming workaround. We were baffled. The button was obvious.
So this year, I rolled up my sleeves and went into the field, working side-by-side with them. During one session, instead of suggesting a solution, I just asked a simple question: “Why?” Why don’t you use this button?
The answer was a revelation. It had nothing to do with the software, the UI, or their motivation. The issue was physical context. At that specific stage of their workflow, they were using a device that simply didn’t have access to the photos they needed to upload. From their perspective, the button was irrelevant because, in their eyes, it couldn’t possibly work.
My insight was immediate: the problem wasn’t the feature, it was the bridge to the feature.
By enabling access from their end-point devices, we didn’t just fix a button, we dissolved years of friction.
This experience was a powerful reminder that you can’t understand the user’s map by looking at your own blueprint. You have to walk the path with them.
The most brilliant feature is useless if it doesn’t exist in the user’s actual, lived reality.
