Is the Solution Actually Sound—or Have You Just Learned to Explain It?

Once a solution exists, it is very easy to keep adding explanations for it.

Why does this need to be here?
Because...

Why can’t we remove that element?
Because...

The list of reasons gets longer, and the solution starts to feel more complete.

But sometimes, what is happening is not that we finally understand the solution.

We are simply getting better at explaining it.

There is a concept in design research called design fixation.

Put simply, once one solution enters our field of view, it can begin to constrain the rest of our exploration. We get better and better at optimizing around it, while considering fewer alternatives.

I ran into exactly this while building the Hero section of my personal site.

I started inventing reasons for a storyboard

At first, all I wanted was a Hero with a scroll-driven effect.

Editing multi-layer 2D assets every time was cumbersome, so I started with simple line drawings to test the scrolling and storyboard.

During those tests, an interesting sense of depth appeared.

But when I replaced the sketches with actual 2D assets, the same effect was hard to reproduce. That reminded me of the 2.5D presentation in Danganronpa, so I kept exploring in that direction.

The storyboard gradually took shape:

A puddle.
A reflection.
Looking up.
Then a wider, more complete view.

So far, nothing was particularly strange.

The real problem began once that storyboard existed. Without noticing, I started assuming one thing:

I had to make this storyboard make sense.

Why would the character notice the puddle?

Because the clouds reflected in it were beautiful.

Why would seeing the reflection make them look up?

Because after seeing a beautiful reflection, they would want to see the real sky.

Still not enough motivation for the movement?

Then let a bird flash across the reflection.

The character notices the bird and follows it upward.

And once they look up, what should they see?

More beautiful clouds?

A forest?

I kept asking “why.”

And for almost every question, I could find an answer that sounded reasonable.

Then at some point I realized:

I was no longer looking for a sound solution.

I was learning how to justify the solution I already had.

The real change was not finding a better explanation

What eventually got me unstuck was not that I finally came up with the perfect storyboard.

I changed the question.

What does this Hero actually need to accomplish?

The answer was much simpler.

Catch a little attention.

Make someone want to keep scrolling.

Then guide their attention naturally toward the real content—the Topics.

Once I returned to that goal, many of the things I had been struggling with suddenly loosened their grip.

The puddle was not required.

The bird was not required.

The forest was not required.

Even the act of “looking up” was not required.

They became, once again:

just one possible answer.

This was closer to reframing

There is another useful idea in design:

reframing.

Design is not only about making an existing answer better and better.

Sometimes the most useful move is to redefine:

What problem am I actually trying to solve?

Looking back, design fixation explains well why I got stuck.

The storyboard became more concrete, and the more concrete it became, the easier it was to keep thinking inside it.

Reframing explains the opposite move: why so many difficult questions became simpler once I returned to the Hero’s actual purpose.

I did not finally manage to make the original storyboard work.

I stopped requiring it to work.

So having a reason is not enough

Since then, I have become more cautious about a particular state.

Once a solution exists, it is easy to keep adding reasons.

More logic.

More motivation.

More explanation.

Eventually, the whole thing becomes increasingly self-consistent.

But:

Being able to explain a solution does not mean the solution was actually derived from the goal.

This does not only happen in visual design.

The same thing can happen in products, technology, processes, and writing.

First comes an answer.

Then comes the work of proving why that answer deserves to exist.

So now, when I have revised a solution again and again—

when the details are getting better,

when the explanations are getting stronger,

but the whole thing still feels somehow wrong—

I stop and ask:

If I removed the current solution and kept only the effect I actually want, would I still arrive at the same solution again?

If yes, then it is probably worth continuing to refine.

If not, the problem may no longer be in the details.

It may be further upstream.

A solution can genuinely make sense.

Or it can simply become easier and easier to explain.