Did You Show Up, or How Did It Go
Redesigning a companion app's home screen so it reports the user's state without scoring them, and what five rounds of mock-ups changed.
I spent this evening redesigning the home screen of my journaling app without changing a line of it. The session started with my own complaint, that the page looked like a website and not an app. It ended with an argument about a row of seven small dots, and what a row like that asks of the person looking at it at bedtime.
It looked like a web page
When I said "website", I could not say why. The reasons were in the layout once someone read it back to me. One scrolling column with the same gap between every block. A large serif headline with a button beside it, which is how a web page opens. Nothing sized to the screen. And the one button the screen exists for sat in the middle of the page and scrolled away with everything else.
Earlier in the day a written list of options had gotten "let's keep iterating" out of me. So this time the options came as pictures, drawn in the app's real colours at my phone's real screen size, which the app's own usage data already knew. Three concepts. I threw one out on sight (a raised panel that looked like it belonged to a different app), found the second too empty, and liked the section labels of the third but not the big gaps it left between them.
What I asked for was a mix, and the order was mine. Lantern at the top, then yesterday's intention, then the last entry, then tonight's button fixed at the bottom where my thumb is.
One detail in that came from the build side and I would not have thought of it. "At the bottom" and "fixed at the bottom" are different things. If the button only sits last in the page, a long intention pushes it off the screen, and that is worse than what I have now. So the button stays put and the part above it scrolls. Every version was then measured at four screen heights, from the installed app down to a browser tab, because a layout that fits one can still overflow in the other.
The number that stayed small
Some background. Earlier today I shipped a softer streak. The app used to show a flame and a count of nights in a row, and a streak has one job, which is to make you afraid of breaking it. It is now a lantern that dims a step for each night you are away and never goes out, next to a count that reads like "12 of the last 30 nights". Miss a night and the number drops by one. It does not fall off a cliff.
The first concept made the lantern a hero, large and centred, the way a fitness app shows its one big number. The obvious next move was to make the count big too. I did not, and I think this is the decision in the whole session I would defend hardest. A big number on a home screen is a score. The lantern is a state, and a state can sit in the middle of the screen without asking anything of me. So the lantern grew and the number stayed the size it was.
The lantern's glow got measured as well. The theme work earlier in the day had left me with a rule I can check by machine, that nothing on the page behind text may be lighter than the card surface the text colours were tested against. The first hero's glow broke it. The text was still easy to read, at better than seven to one, but the rule was broken, and the only way I know that is that the mock-up was rendered with its text hidden and the brightest pixel under each line was read off. The smaller glow in the final design passes in all three colour themes I am testing.
What a row of dots asks
I liked the week row the moment I saw it. Seven marks for the last seven nights, filled if I wrote.
The pushback I got was direct. A row like that shows every night I did not write, which is the gap I had just spent a session softening. There is also a legal neighbour. Washington's companion-chatbot law, in force from January 2027, lists engagement techniques an operator may not use on users it knows are minors, and prompting someone to come back for companionship is on that list. My app is for adults behind an age gate, so by my reading the duty does not attach, and no attorney has reviewed that reading. I design against the list anyway. If a legislature wrote down what manipulation looks like in my product category, I would rather be far from it than technically outside it.
So the dots were drawn to pressure as little as dots can. No empty rings waiting to be filled, no word like "missed" on a gap, and today not shown as a slot.
Then I asked a different question. Every entry already carries a mood, one small face chosen when the entry is saved. What if the face went where the dot was?
That changed what the row asks. Dots ask whether I showed up. Faces ask how the week felt, and that is a question a journal should be asking. The review that had argued against the dots agreed, and then listed what it costs, which I am glad it did. The mood is picked by the AI and not by me, and my own design notes had that wrong until today. A hard week will now sit on my home screen every time I open the app. And it puts more emoji on one screen than anything else in a product I had just cleared of decorative emoji.
I accepted all three, with one condition I will hold myself to. If an unlit night or a rough week feels like a nag when I am actually in bed with the phone, the row comes out.
Nobody starts at zero
With the layout settled I looked at the same screen for a brand-new account and did not like it. No entry and no intention means half the sections vanish. What is left is "0 of the last 30 nights" above seven empty marks. A zero, as the first thing someone reads after signing up.
The fix hides the count and the week row until there is one entry to count. In their place, an unlit lantern with a single line, "Your first entry lights it", and four short steps for how a night goes.
The wording of one step taught me something. I wanted it to say "intentions", plural, because I do not want to limit anyone to one. But today the AI offers one, the app saves one line, and the home screen shows one line. Copy that says "intentions" would promise something the product does not do. The line I ended up with is "Choose something small for tomorrow." It is true today, and it stays true if I later let people keep more than one.
"Overwritten" meant "not looked at"
While we were on intentions I mentioned something I had noticed as a user. If I write a second entry on the same day and do not set an intention, the one from my first entry is overwritten with nothing.
It is not. Nothing is deleted. The home screen and the AI's opening greeting each read only my newest entry, so when the newest entry has no intention, both act as if I never set one. Two readers had quietly assumed one entry per night. The same read turned up a second problem I had not seen. Open a second chat on the same evening and the companion is set up to ask how my intention went, on the night I set it, for a day that has not happened yet.
I used the word "overwritten" because that is what it looked like from the outside. If I had filed it that way, the fix would have gone looking for a write that does not exist.
The planned fix reads the latest intention of the night, and never says back something meant for tomorrow. My one condition was no duplicates on the home screen. The tempting way to guarantee that is to compare the text of two intentions, and it does not work here, because the AI tidies wording when it saves and the same intention can differ by a word between two entries. The design avoids the comparison. One entry is always the whole answer.
None of this has shipped. I am living with three colour themes for a few nights first, and I do not want a moving layout muddying how the themes feel.
Mental Models
A status display asks a question, so choose the question. Seven dots ask whether you showed up. Seven moods ask how it went. The data slot is the same and the pressure is not.
Make the state the hero and leave the number small. A big number on a home screen is a score, whatever the label under it says.
Nobody should start at zero. Hide a counter until it has something to count, and use the space to say what the thing is.
Copy cannot promise more than the product does. Look for the wording that is true before the feature changes and after it.
A user's word for a bug is what it looked like. "Overwritten" turned out to be "not looked at". Check the readers before hunting for a write.