The health code mess didn’t stop at green, yellow, and red. There turned out to be a fourth state too: a code that simply couldn’t be viewed at all.

I had already gone for a PCR test on my own initiative, yet by that night my health code had effectively vanished. It’s easy to imagine the logic behind this design choice. If too many people with uncertain status were all dumped into the yellow-code category, that would create confusion for testing and follow-up. So someone built a separate state for people whose condition couldn’t yet be confirmed.

On paper, that probably looked like a careful solution. In practice, the very first step collapsed. The people enforcing the rules clearly didn’t want extra trouble, so anyone with a yellow code and anyone whose code couldn’t be displayed were treated the same way anyway.

That is the recurring problem with systems designed around ideal logic but carried out by people trying to avoid friction: the nuance disappears immediately.

What made it even more absurd was what happened next. After my code was pushed into this "unable to verify" state, the epidemiological investigation call that was supposed to follow never came. Instead, the police station contacted me first. When they learned that I had proactively gone for testing and still had not been called by the community team, they were stunned.

Without a usable health code, daily life dropped into a half-frozen state. No mall, no public transit, no office building, no work, sometimes not even a straightforward way home. All I could do was wait and hope that at some point the community’s absurd workflow would finally get around to me.

The real mistake isn’t only treating users as fools

In product development, people often talk as if simplifying for users means assuming they are clueless. But there is another side to that. If you design a system that truly treats users like fools, the moment reality diverges from your process, the user becomes the one trapped inside your bad assumptions.

The expected flow here was obvious: once my health code changed, someone should have called quickly to confirm the actual situation. Instead, there was silence. The system didn’t just fail to help; it actively turned the health code into a barrier. Suddenly the user became someone who couldn’t enter commercial spaces, couldn’t take transportation, couldn’t get into office towers, couldn’t work, and couldn’t move through ordinary life.

Naturally, a user in that position will try to find another path: an appeal channel, a manual review, a hotline, anything. But this is where overconfident system design becomes laughable. The complaint channels exist in name only. You click the appeal option and it either doesn’t work, leads nowhere, or has no matching process behind it. Even when a contact number exists, the answer is the same: keep waiting for the community investigation call.

At that point the user realizes something important. The designers didn’t merely simplify the process. They really did assume the user would passively sit there and accept whatever happened.

The moment users start thinking for themselves, bad systems are exposed

Once users stop behaving like obedient placeholders and start acting intelligently, they immediately uncover the stupidity built into the process.

If the designers still insist on treating everyone as passive and helpless, the system is bound to break down. Why? Because the original workflow never considered the possibility that users would actively search for solutions on their own.

And the more alternative routes people discover, the more obvious the holes in the system become. Every workaround, every side contact, every unofficial explanation is evidence that the official process doesn’t actually function.

That creates risk for the people who designed it. If accountability ever enters the picture, all of those bypasses point back to the same conclusion: the process was never really designed to solve the problem.

So how do bad systems protect themselves?

There is a familiar saying: don’t argue with a fool, because they will drag you down to their level and then beat you with experience.

That is more or less how this kind of system operates.

Once users begin identifying flaws, the goal is no longer to fix the exposed problem. The more effective strategy is to neutralize the people raising it. If users are becoming too resourceful—looking for solutions, asking hard questions, making suggestions—then the easiest response is to design a process that forces everyone back into helplessness.

Want to appeal? Fine, appeal through the community channel. But when you open it, you discover that because the community has never contacted you, you are not allowed to submit the appeal. So you find another general hotline. They tell you that if you want to appeal, you still have to wait until the community contacts you before anyone can even define what your appeal is about.

What if the community never calls? You can try contacting them yourself. Except that phone line never connects.

This is where the system reveals its final move. If you become anxious, if you keep trying to reach someone, if you get angry, eventually you will hear the moral lecture: there are too many people to investigate, everyone is under pressure, can’t you be considerate of how difficult this is for others too?

It’s a perfect shield. Once that line appears, the operational failure gets recast as a test of your empathy.

Moral pressure becomes the easiest way to shut people up

That kind of emotional blackmail works because it shifts the burden. The system fails, but the user is asked to behave nobly in response. You are expected not only to tolerate dysfunction, but to feel guilty for objecting to it.

And unless your situation is extreme enough to outmatch that moral pressure, there is almost no way to push back. Only when the consequences are dramatic enough—something urgent, irreversible, and socially legible—does the moral advantage swing back toward the user.

Otherwise, the default expectation is simple: endure the problem quietly, because everyone is struggling.

The issue was never that users were too stupid

In the end, whether the slogan is "treat users like fools" or "don’t treat users like fools," the deeper problem is elsewhere.

The problem is that the people designing the process may themselves be thinking in an extraordinarily shallow way. If the workflow starts from narrow, lazy assumptions, it will produce a narrow, lazy system. And once that system is deployed, everyone inside it is forced into the same degrading role: waiting, guessing, being blocked, and then being told to be grateful for the effort.

The tragedy is that humane design is treated as a sunk cost. Thinking through edge cases, building real appeal channels, allowing users to clarify their own situation, and respecting the fact that people need to move through society—those things all require effort.

It is cheaper to flatten everyone into the same category, cheaper to remove flexibility, cheaper to make people wait, and cheaper to rely on social pressure instead of competent process.

From that perspective, making everyone feel powerless isn’t a bug at all. It is the cost-saving model.