A Friend Couldn't Read the Button: Why a Word Beats an Icon
A reminder that landed on the wrong tab, a button a friend could not read, and the research that says a word beats an icon.
Yesterday's post ended on a look I had not taken yet. Sunday night's reminder was sitting in my phone's notification history with the eclipse icon beside it and the sentence I had hoped for, the one that says you started tonight's entry and it is waiting. So the picture and the words both held. What happened when I tapped it was the problem: it opened the sign-up page I had shown a friend that afternoon, not the draft. Three things this week had the same shape. In each one the app assumed a person would decode something, and the person did not.
One tap, the wrong tab
When I wrote the tap code it did something that sounded reasonable. It brought forward whichever Duskglow tab had been used most recently and told that tab to open the draft. Only the app's own page knows that message. The sign-up page I had left in front does not, so the tap "worked," the browser came forward, and nothing happened. From the phone it looked like a dead button.
I fixed it the next afternoon. Only a tab on the app's own page counts as the app now, and if there is no such tab the reminder opens the app straight to the draft. The rule I wrote down beside the fix is short. A reminder's tap lands on the thing it names, in one tap, every time. Landing without a reload is nice. Landing is required.
The friend who could not read the button
A friend who tried the app hit the second one. Under Luna's reply there is a row of buttons, and at the start of that row sat a small square with a shuffle icon in it. Its job is to ask Luna about something else. My friend had no idea what it did.
I knew exactly why. A few weeks ago I folded the label away to save a line of screen when the keyboard is up, and I told myself the first tap would teach it. It taught nothing, because a person does not tap a button they cannot read. The label was still there for a screen reader, which is the kind of thing that lets you tell yourself the design is fine.
That one went on a list with three other small things, including a row on the home screen that confused me rather than a friend. The plan was to look at them after the beta. Two things changed the plan. The beta start may move a week, which gave me build room, and I realised that a confusion someone hits in their first session is exactly the kind of thing that muddies a retention read. If a tester stalls on a button in their first session, the number I am trying to measure gets a little less honest. So I pulled two of the four forward.
What the research says
Before mocking anything up I asked for the general mobile practice, not the wellness-app version of it. The useful sources were older and plainer than I expected.
Nielsen Norman Group's icon usability article from 2014 is still the clearest. Only a handful of icons are close to universal, the house, the magnifying glass, the printer. Everything else needs a text label, visible at all times, because a label that appears on hover does nothing on a phone. They also give a five-second rule: if no icon for a meaning comes to mind right away, an icon is unlikely to carry that meaning. The quote they borrow is Tognazzini's. A word is worth a thousand pictures. A shuffle icon says "random." It does not say "ask about something else." My friend's confusion was predicted twelve years ago.
Google's guidance says the same thing in its own register. Icon-only buttons are for optional, supplementary actions whose meaning is unambiguous, and the icon gets its label from a tooltip on hover, which a phone has no hover to show. On labels, NN/g's writing advice lines up with it: lead with a verb, add a noun only when the verb alone is ambiguous, and keep it to four words or fewer.
The surprise was where the room came from. My first four mock-ups put the words back and all four were rejected in one line, the ones with words take up too much space, which was true. The research gave me the way around it rather than a compromise. The other two buttons on the row said "Wrap up tonight" and "Save entry." On a screen that is already tonight's entry, the nouns are doing nothing. They became "Wrap up" and "Save," and the width they gave back was enough for the third button to carry its own words, "Change topic," on the same row at the same height as before. Seven mock-ups of that one button over two rounds, and the answer was shorter words rather than a cleverer icon. Anything you already saved still reads the way it did; the buttons are what changed, not the saved text.
Dates, not letters
On the home screen there is a row that shows the last seven nights as seven small marks, one per night, each with the first letter of its weekday underneath. Tonight is always the last mark. That means every morning the letters shift one place to the left. On a Monday the row reads T W T F S S M. On Tuesday it reads W T F S S M T. I built it, I look at it every night, and it still read to me as the calendar jumping around.
I tried four shapes. A fixed Monday-to-Sunday week keeps the letters still, but on a Monday the row is almost empty and last week vanishes the morning it ends. A caption with no labels was the quietest and told you nothing about which night was which. A sentence lost the per-night view entirely. Dates under the marks won. The numbers climb from left to right, so when the row shifts it reads as time passing instead of the week moving. The row is still a view of moods and never a streak, which is the one rule about it I will not trade.
Both changes shipped tonight after a check on the phone.
Mental Models
A word is worth a thousand pictures. Unless an icon is one of the handful nearly everyone knows, it needs its words beside it, on screen, all the time. A label in the accessibility tree is for the reader, not the person tapping.
The screen is the noun. Buttons carry verbs. If the context already says what the verb acts on, the noun on the button is spending width for nothing, and that width is usually what the missing label needed.
Fix the first-session stumbles before the measurement. A beta that measures whether people come back is only as clean as their first night. A confusion you already know about is cheaper to fix before the read than to explain afterwards.
Landing is required. A notification's tap goes to the thing it names, every time, and the reload-free version of that is a bonus you earn after the basic one works.