Why Most Technical Discussions Fail to Solve Real-World Problems

fb78365e-c776-4621-9667-cab7cf49aa93.png

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 traffic prioritization makes information increasingly refined and expression more complex. However, at the same time, many issues that could be judged right or wrong at a glance are gradually "diluted" by seemingly rigorous technical discussions, losing their value for debate. Some originally clear common sense, after layers of analysis, becomes blurred or even disappears.

Yesterday, I discussed product design with a friend. He said he planned to deconstruct the interaction of an excellent product every day and share it as content, hoping to learn through this method and practice the Feynman Technique. For example, the recently popular psychological support app Rootd has an extremely simple design. When a user experiences a panic attack, the interface only shows a prominent red button. Clicking it enters a self-help process. It is said that this app has earned millions of dollars in revenue and is a learning template tested by the market.

This reminded me of a smoking cessation app I once conceived, which followed a similar logic. When a craving hits, the user clicks a large button and randomly enters a mini-game that requires both hands, aiming to divert attention.

From an interaction perspective, both adopt a "minimalist entry + strong guided behavior." However, after reasoning, I found this idea unfeasible.

In fact, digging deeper reveals that Rootd's premise 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 pain, and Rootd serves as a "lifesaving tool." In this context, the intrinsic motivation driving users to click the button is the survival instinct.

But smoking cessation is entirely different. When a craving strikes, the user's true psychology is often to escape the pain rather than actively fight it. Opening a smoking cessation app means confronting withdrawal symptoms and pain head-on. Therefore, the most likely action for users is not to open it, or to light a cigarette before even opening it.

I shared this insight with my friend. Often, whether an app can retain users does not depend on how eye-catching the button design is or how simple the interaction is, but on whether the user has the motivation to open it at that moment.

Overemphasizing surface-level interaction design can lead to overlooking this fundamental issue. When we focus on interaction forms, we easily mistake the problem as solved. But what truly determines whether a product succeeds is user motivation, not interaction structure.

Similar situations can be seen in many topic discussions.

For instance, some power bank brands register numbers like "20000" as product names. Ordinary consumers naturally interpret this as a battery capacity of 20000mAh, but in reality, it is just a name.

Discussions around this phenomenon often quickly shift to technical aspects. Some analyze the conversion rules between rated capacity and nominal capacity, while others debate whether such product naming complies with legal regulations. These discussions are not wrong; they can even be considered professional and rigorous.

However, the problem is that they all avoid addressing whether this naming subjectively misleads consumers.

When the focus of discussion shifts to "whether it meets standards" or "whether it is within legal limits," the issue of "justice" behind such actions is overlooked. Technical discussions transform problems that originally involve value judgments into issues that can be explained by rules. Once within this framework, it easily shifts 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 an obvious advantage: safety. This is a low-friction way of interaction. Judging "whether it is misleading" or "whether it is justified" requires taking a stance and may involve conflicts of interest. Discussing parameters, rules, and implementation methods, on the other hand, can maintain a surface-level neutrality, appearing objective, rational, and even more "professional."

But this technocratic style of discussion indefinitely postpones problems that should be resolved immediately, and the resulting costs are often far greater than the pain of solving the problem.

A disease should be treated at its onset; you wouldn't wait until it's terminal, forcing you to scrape the poison off the bone or amputate below the neck, would you?

Returning to more fundamental judgment methods, if there is a way to avoid falling into this "technical fog," the trendiest approach is probably the so-called "first principles."

In product design, first principles mean returning to user motivation. In real-world judgment, this means returning to the most basic common sense.

If an action objectively leads to misunderstanding, then even if it is fully compliant in process, it cannot simply be considered "problem-free."

These judgments are not difficult and do not require complex methodologies. But precisely because they are simple, they easily become invisible in "complicated" technical discussions.

Technology should be a tool to achieve goals, not a reason to replace judgment.

When we start to get used to discussing issues with more complex language, we need to be even more vigilant about whether we are using complexity to obscure common sense that was already clear.

Common sense is not sophisticated, but it is often closer to the answer.

Let's talk

Tell me what you think