Table Of Contents
Sometimes you discover an idea. You start out solving a small issue — and it quietly sends you down a completely different path.
This time, I was adding auto scroll in-view behaviour to my header navigation. Nothing groundbreaking. Just making sure it scrolls out of view when moving down the page and comes back when scrolling up. An eventListener on the window element, toggling a class with a transition.. It worked. Clean. Predictable.
While I was at it, I also wanted to implement a back-to-top button.
I had already tagged my main content with #main-content, so wiring that up would be trivial.
Technically, it was a non-event.
The Obvious Placement
Now visually, my header nav is a centered, pill-like shape floating at the top of the viewport. On large screens, there’s also a dark/light toggle fixed at the top right (on smaller viewports it lives in the dropdown).
So I thought:
Why not place the back-to-top button directly underneath the dark/light toggle? Let them form a little functional duo.
It was fine.
Looked decent.
Felt logical.
I placed it inside the navbar component. Styled it similarly. Nudged it down a bit with a larger top value.
All good.
The “What If” Phase
Then I wondered:
What if I position it halfway down the page?
Still on the right side.
It didn’t look bad. Maybe slightly unconventional, but that was the top positioning too — but if “the usual” was my benchmark, the whole site might as well look like every other site.
But there was something off.
Because my header nav moves out of view while scrolling down, the back-to-top button (being inside that same container) inherited that vertical movement.
It wasn’t broken.
But it wasn’t intentional either.
So I pulled it out of the header container.
Placed it center-right.
Higher.
Lower.
All the way at the bottom like most sites do?
Nothing felt quite right.
The Accidental Insight
Then something clicked.
If I put it back inside the header nav…
but align it to the bottom of that container…
It would move along with the header’s scroll behavior.
Which means:
I could position the back-to-top button outside the viewport initially — and it would scroll into view exactly when the header scrolls out.
Two behaviors.
One motion system.
Zero extra logic.
So I tried it.
It worked.
Perfectly.
Brilliant.
Not because it was complex.
But because it emerged naturally from the system that was already there.
This Was Never in the Wireframes
Here’s the thing:
This is not something you design up front.
Unless you’ve seen someone else do it.
Or you’ve stumbled upon it before.
It didn’t come from a mockup.
It didn’t come from a UX brainstorm.
It came from moving things around.
From experimenting.
From breaking the “proper” structure.
From asking “what if” one more time.
I often tell people:
You don’t learn by reading.
You don’t learn by watching.
You learn by doing.
By building.
By placing things in slightly wrong spots.
By observing the side effects.
This was one of those moments where my own advice came back and proved itself.
Build First. Discover Second.
Sometimes a feature isn’t just a feature.
Sometimes it’s a door.
And the only way to find out what’s behind it
is to start building.
Even if it wasn’t in the wireframes.