All tests green. Why does it still look horrible?

I wanted the portfolio’s mobile menu to arrive through smoke. The first procedural version was deterministic, responsive, accessible, and covered by tests. It opened and closed correctly. It cleaned up its animation lifecycle. It respected reduced motion. It did not disturb the desktop navigation.

It also did not really look like smoke.

The particles began near the center and expanded outward. The result read as a cloud or a soft vapor burst. The implementation had satisfied a long list of engineering requirements while missing the visual idea a person would recognize immediately: smoke rises.

That gap became more useful than a clean first attempt. It showed exactly where automated correctness stops and product judgment begins.

The tests were answering real questions

It would be easy to tell this story as “tests cannot judge design,” then dismiss the technical work. That is too simple. The automated checks protected important behavior while the effect changed repeatedly.

The renderer used a resolution cap so a small decorative transition could not consume an arbitrary amount of work on dense mobile screens. The particle sequence was deterministic, which made failures reproducible. Tests covered initialization, direction metadata, cleanup, keyboard focus, animated closing, breakpoint resets, reduced-motion suppression, and a native fallback. Later verification also confirmed that the production build and browser behavior still passed after the field grew denser and the motion changed.

Those guarantees prevented visual experimentation from turning the menu into an accessibility or lifecycle regression. They just could not determine what metaphor the motion communicated.

This is not a failure of testing. It is a mismatch between the question and the instrument. A browser assertion can confirm that the canvas exists, that animation stops, or that a menu item receives focus. It cannot reliably tell whether an irregular transparent field feels like smoke, fog, steam, dust, or a cloud.

A correction can carry more signal than a success

The useful user reply did not describe an exception or a broken button. It redirected the concept: the motion started in the wrong place and expanded in the wrong direction. That short observation changed the model of the effect.

The next pass emitted particles below the viewport in staggered columns and moved them upward. Vertical stretch, lateral curl, turbulence, rotation, and trails were tuned to reduce the cloud-like impression. The field became slower and denser. Automated verification kept the surrounding behavior stable as those parameters changed.

The final review still did not declare photorealistic smoke. It accepted the result as a convincing enough transition for the menu while naming the remaining limitation: it was directional vapor, not fully convincing smoke. That description is now part of the evidence rather than something polished out of the project history.

For a founder or product manager, the distinction matters because “working” is not one condition. A checkout may be technically complete while making the total price hard to understand. An onboarding flow may satisfy every event assertion while leaving a user unsure what happens next. A dashboard can display accurate data while directing attention toward the least important number.

For an engineer, the lesson is not to abandon automation. It is to name which risks each layer can actually detect.

Acceptance is not the same as perfection

Once the motion rose from the bottom and the supporting behavior remained safe, there was another decision to make: keep tuning, replace the approach, or accept the limitation.

Procedural smoke can absorb an enormous amount of time. More particles and turbulence do not guarantee a more believable result. At some point the work can drift from “make navigation feel distinctive” into “build a fluid simulation,” even though the menu is visible for a fraction of a second and the effect is not the product.

The accepted version met the communication goal well enough: it introduced the mobile navigation with an upward atmospheric cue. The remaining realism gap was documented and deferred. That was a scope decision, not a claim that the visual had become perfect.

1. 01Define non-negotiable behavior
2. 02Build a deterministic visual
3. 03Verify accessibility and lifecycle
4. 04Review the perceived metaphor
5. 05Redirect the motion model
6. 06Accept and document the remaining limit

This sequence is especially important in AI-assisted development. An agent can generate an impressive amount of implementation detail and a persuasive verification report. That output creates momentum. It can make a technically elaborate result feel finished before anyone asks whether it communicates the intended idea.

The antidote is not skepticism toward every generated artifact. It is an evaluation boundary: deterministic checks for behavior, direct observation for perception, and an explicit product decision for how much refinement the moment deserves.

Every test passing was good news. The smoke looking wrong was also good evidence. The quality came from keeping both facts in the same decision.