When AI says "this is hard to implement," how can you tell whether that judgment is for the user's benefit or for development convenience?

The C-Suite System provides opinions on every response, but having 5 executives each making judgments from their own perspective wasn't enough. When judgment criteria are vague, "good opinions" can masquerade as "decisions that restrict users."

That's why we created the traffic light system. A structure that forcibly attaches a signal to every C-Suite opinion. Making the user-perspective impact of each judgment visually apparent, every single time.

Why a Traffic Light

The most frequent problem when collaborating with AI was "restrictions that sound reasonable."

"This feature has too many edge cases, so we should reduce scope." "This UI has high implementation complexity, so I'll simplify it." "This option might confuse users, so I'll remove it."

Each one sounds reasonable individually. But when these judgments accumulate, user freedom gradually shrinks. User choices being reduced for development convenience — this was the most dangerous pattern.

Writing "consider the user perspective" in text didn't work well at actual decision moments. So a structural enforcement mechanism was needed. A visual signal anyone could immediately judge. That's the traffic light.

Green: Proceed Freely

Green is the ideal state. This judgment does not restrict user freedom at all.

For example, code refactoring that improves performance. The user-facing interface stays the same while only the internal structure changes. Such work gets green. No negative impact on user experience.

When green appears, proceed normally. Execute after CEO approval without additional discussion. Most work should be green, and in practice it is.

But green doesn't mean "no review needed." Even if all C-Suite members assign green, it must be a green that went through user-perspective checks. Rubber-stamping green is equivalent to disabling the traffic light system.

Yellow: Discussion Required

Yellow is a tension state. User freedom is restricted, but AI judges the restriction as justified.

For example, strengthening password complexity requirements for security. From the user's perspective, it's clearly inconvenient. But there's a legitimate reason: security. In such cases, a yellow signal is attached.

When yellow appears, reasons must be explicitly stated. "Why this restriction is justified" must be documented concretely, and only the CEO's direct confirmation allows proceeding. The CEO can approve or reject through discussion.

The key point: only the CEO can make the final judgment of justified/unjustified. AI self-judging "this restriction is justified, so it's fine" and moving on is not permitted. Yellow must always go through human confirmation.

Red: Immediate Redesign

Red is an alert state. User freedom is restricted, and even the AI itself judges that restriction as unjustified.

This is a serious situation. It means the AI recognized "this is wrong" yet was proceeding in that direction anyway. When red appears, stop immediately and absolutely do not proceed until CEO confirmation.

There's a typical pattern that triggers red. "This feature is complex to implement, so I'll reduce the options." Implementation complexity is the development team's problem, not the user's. Removing choices users want because of development convenience — that's red.

The CEO's Core Principle

At the root of the traffic light system lies one principle:

Specific rules derive from this principle:

"Implementation difficulty" cannot justify restricting user freedom. A feature being hard to build is the development team's problem to solve. Telling users "we can't do this because it's too hard" is not acceptable.

"Scope explosion" is also not valid grounds. Reducing user features because the work scope grows. Scope management is a project management issue, not something to solve by sacrificing user experience.

"Edge cases" likewise. Even if only a few users encounter a situation, for those users it's 100% of their experience. Simplifying by ignoring edge cases is pushing development convenience onto users.

Shared Bias Detection

The traffic light system has one unique rule: When all C-Suite members point in the same direction, suspect shared bias.

If all 5 executives assign green, or all reach the same conclusion, that's actually a danger signal. It's a structure designed for review from different perspectives, yet everyone agrees? High probability something is being missed.

In such cases, re-examine from the user perspective. "Is there really no restriction on users?" "Are there usage scenarios we overlooked?" "Are we sharing the same bias?"

Since the multiple roles created by AI are ultimately the same AI, they can share identical biases. Recognizing this structural limitation and intentionally exploring opposing viewpoints during unanimous agreement — that's the core of shared bias detection.

Real-World Cases

Here are cases where the traffic light system actually worked.

Yellow case — Search result limits. A design emerged to limit the number of search results shown at once in the talent search feature. From a technical perspective, there was a rational reason: saving external data credits. But from the user perspective, the frustration of "why only 10 people?" arises. Yellow was assigned, and after CEO discussion, the direction became "unlimited searches, credit savings via caching."

Red case — Feature option reduction. A proposal emerged to remove some settings options from the email sequence feature because "users might be confused." Product and tech leads both agreed "simplification is right." But from the user perspective, this is a feature where expert users want granular control. Red was assigned, and an immediate redesign maintained the options while setting good defaults.

Shared bias detected. In a new UI design, all 5 C-Suite members assigned green. "Clean and good." But when re-examined per the shared bias rule, it turned out that for users in certain job roles, essential information required one additional click to access. Everyone had been looking only from a "developer perspective." Thanks to the re-examination, it was fixed before launch.