← back

Empty Space Was the Wrong Word

#ai-product-management#ui-ux#product-decisions#user-research

Shipping a home screen redesign, and how a layout bug and my own vague feedback both pointed at the same real problem.

Tonight the home screen redesign I spent yesterday arguing about went live. It took two rounds of testing on my phone, and the second round only happened because I said something was wrong and used the wrong word for it.

Keeping the two themes that lost

The redesign shipped with a new colour scheme. I had lived with three candidates for a few nights, a warm brown that current testers know, a cool indigo, and a dusk gradient that runs from deep blue to a faint orange at the bottom of the screen. The gradient won. I checked it the way the app is actually used, in bed in a dark room, on a real entry.

What I did not do was throw the other two away. They all pass the same contrast checks, so keeping them costs me a little testing on every future screen and nothing else. And they are not only taste. The indigo has the most contrast room of the three, which matters for some eyes at night, and the brown is what the people already using the app are used to. So the gradient is the default everyone sees, and the other two sit in Settings. The choice is saved on the phone and goes nowhere else.

The lantern that would not sit still

The home screen has a small lantern at the top, the app's way of showing whether you wrote recently without turning it into a score. On a tall screen it sat centred above the count, and on a short screen it folded to the left, beside the count, so that everything still fit. That fold was designed to happen at one fixed height.

On my phone, in the browser, I saw both. Sometimes centred, sometimes on the left, on the same page.

The cause took a minute to see and is obvious once you do. In a mobile browser the address bar slides away when you scroll and comes back when you scroll up. That changes the height of the page by roughly fifty pixels, and the fold point sat inside that range. So which layout I got depended on what the address bar happened to be doing at that moment.

Any design that changes at a fixed height inside a browser tab has this problem, and I had read the measurements for four screen sizes without it occurring to me that one of those sizes moves while you look at it.

What I said, and what I meant

When I reported it, I also said which version I liked. The left one. The centred lantern, I said, "leaves too much empty space."

The response took that at face value. It drew both versions at the height of the installed app, where there is no address bar, and pointed out that the centred version actually leaves less empty space there. The left version leaves a band of about 170 pixels above the button at the bottom. The recommendation was a split: left in the browser, centred in the installed app, each filling its own height.

I looked at the pictures and said it differently. The empty space I meant was to the left and right of the lantern. It looked awkward.

That turned out to be the real reason, and the response named it better than I did. Every other element on that screen lines up on the same left edge. The date, the greeting, every section header, the intention, the card, the button. The centred lantern was the only thing not on that edge, so the page read as two layouts stacked together, and the space around the lantern looked like a hole instead of room. The left version has just as much empty space overall. It is just in one place, above the button, which is where the design said spare room should go.

So the recommendation changed, and I think that was the right call. I said "empty space" when I meant alignment, and a careful answer to the words I used would have shipped a layout I still did not like. The fix ended up being one form everywhere, with the lantern slightly larger so it holds its corner, and no fold left to flip.

I keep learning this from my own feedback as a user. Yesterday I called a bug "overwritten" when the real problem was that nothing was reading the right entry. Today I called a layout problem "empty space" when it was alignment. My description is what it looked like from where I sat. It is a good signal that something is off and a poor map of what.

Choosing the option that was not recommended

The greeting at the top also looked too small next to everything else, and it blended in. I got four options as pictures. The recommendation was the plain larger version. One option put my name in the same amber as the lantern, and that one came with a named cost: amber is the colour of the light and the main button, and spending it on a name dilutes what it means.

I picked the amber name anyway.

I am not sure the recommendation was wrong, and I am not sure I was right. What I liked about the exchange is that the cost was said out loud before I chose, so I chose it knowing what I was spending. If the amber starts to feel like noise, I know exactly which change to undo.

Mental Models

A layout that switches at a fixed height needs a height that holds still. In a mobile browser it does not, because the address bar moves it while the user is looking.

Feedback names the symptom, not the cause. "Too much empty space" was true, about the wrong space. Ask where, before solving for how much.

One element off the shared edge reads as a gap. Alignment decided this screen, not the amount of room.

Keep the options that cost you nothing but testing. A default plus two choices covers taste, contrast needs and habit, as long as every option passes the same checks.

Say the cost before the choice, not after. An option picked against advice is fine when the person picking it knows what it spends.