We are living in an era surrounded by data, terminology, and methodologies. The torrent of information mass-produced by self-media and netizens constantly bombards people's minds. The logic of social interaction and expression driven by the supremacy of traffic makes information increasingly refined and expression more complex. However, at the same time, many issues that could originally be judged as right or wrong at a glance are gradually having the value of discussion "diluted" by seemingly rigorous technical discussions. Some originally clear common sense becomes blurred or even disappears after layers of analysis.
Yesterday, I was discussing product design with a friend. He said he plans to deconstruct the interaction of an excellent product every day and share it as content. He hopes to learn this way and practice the Feynman learning technique. For example, the recently popular mental health mutual aid app Rootd has an extremely simple design. When a user experiences a panic attack, there is only one prominent red button on the interface; clicking it leads to a self-help process. It is said that this app has already generated millions of dollars in revenue, making it a market-tested learning template.
This reminded me of a quit-smoking app I once conceptualized, which followed a similar logic. When a craving hits, the user clicks a large button and randomly enters a small game that requires the use of both hands to distract themselves.
From an interaction perspective, both adopt a "minimalist entry point + strongly guided behavior." However, after reasoning it through, I found this idea is not feasible.
Upon deeper reflection, it becomes clear that the premise of Rootd's success is that the user is in a "state of seeking help" at that moment. During a panic attack, people instinctively look for any outlet to alleviate the pain, and Rootd is the user's "lifesaving tool." In this context, the primary driving force behind the user clicking the button is the survival instinct.
But quitting smoking is completely different. When a craving strikes, the user's true psychological state is often about avoiding pain, not actively confronting it. Opening a quit-smoking app means facing withdrawal symptoms and confronting pain head-on. Therefore, what the user is most likely to do is not open it, or have already lit a cigarette before even opening it.
I shared this perspective with my friend. Often, whether an app can retain users does not depend on whether the button is designed prominently enough or whether the interaction is sufficiently simple, but on whether the user genuinely has the motivation to open it at that moment.
Overemphasizing superficial interaction design can cause us to overlook this fundamental issue. When we focus our attention on the form of interaction, it's easy to mistakenly believe the problem has been solved. But what truly determines whether a product can succeed is user motivation, not the interaction structure.
Similar situations can be seen in discussions on many topics.
For example, some power bank brands register numbers like "20000" as product names. Ordinary consumers seeing this name naturally assume the battery capacity is 20,000mAh, but in reality, it's just a name.
Discussions around this phenomenon often quickly slide into the technical realm. Some analyze the conversion rules between rated capacity and labeled capacity, while others discuss whether naming a product this way is legally compliant. These discussions themselves are not wrong; they can even be considered professional and rigorous.
But the problem is that they all avoid the question of whether this naming subjectively misleads consumers.
When the focus of the discussion shifts to "whether it meets standards" or "whether it is within legal limits," the question of the "justice" of doing so is instead overlooked. Technical discussions transform issues that belong to value judgments into problems that can be explained by rules. And once within this framework, it's easy to shift from "whether it should exist" to "whether it is reasonable."
Why do we prefer "technical discussions"? Because compared to making direct value judgments, technical discussions have a clear advantage: safety. It is a low-friction way of interacting. Judging "whether it is misleading" or "whether it is justified" means one must take a stance, which may also involve conflicts of interest. Discussing parameters, rules, and implementation methods, on the other hand, allows one to maintain a surface-level neutrality, appearing objective, rational, and even more "professional."
But this technocratic style of discussion can postpone problems that should be solved immediately indefinitely, and the resulting cost is often far greater than the pain of solving the problem.
Treat an illness while it's still minor. One shouldn't wait until the disease is deeply rooted, forcing a drastic cure like scraping the bone or amputating below the neck, right?
Returning to more fundamental ways of judgment, if there's any method to avoid falling into this "technical fog," the trendiest approach is probably the so-called "first principles."
In product design, first principles means returning to user motivation. In real-world judgment, it means returning to the most basic common sense.
If an action objectively leads people to misunderstand, then even if it is fully compliant procedurally, it cannot simply be considered "not a problem."
These judgments are not difficult; they don't even require complex methodologies. But precisely because they are simple, they easily become invisible in technical discussions that "get complicated."
Technology should be a tool to achieve goals, not a reason to substitute judgment.
When we start getting used to discussing problems in more complex language, we need to be even more vigilant about whether we are using complexity to掩盖 those common sense truths that were originally very clear.
Common sense is not advanced, and it is often closer to the answer.