A crit on 2 surfaces that both reminded people what to do, the table that settled which one should, and the work a simpler rule moves somewhere else.
Notifications in our product used to be called reminders. That one word, picked years ago, taught people to treat the panel as a to-do list, and when it was renamed, the label changed and the habit didn’t. That history came up at this week’s design crit, where a designer and a product manager brought a proposal titled “Notifications and Homepage: one place to look.”
It’s a sequel to work I wrote about in Issue 25, where a team decided the home screen would be the prioritization layer. That decision exposed a problem next door, in notifications. The team counted dozens of notification types, and a good share of them had a twin on home: a to-do for the same thing. The two clear on different rules, so people see the same action twice, and the two can disagree. A few beta users were already confused. Nobody owns notifications today, which is how they drifted.
The board laid out 2 models.
- The event system. “Notifications tell you what happened. Anything that needs action lives on Home.” A payment arrives, it shows up in notifications, you read it and clear it.
- The alert system. Notifications show events, plus a nudge when something that needs action slips. A note isn’t finished within 24 hours, an email or a push goes out, and it opens the note.
Then came the move I’d hand to any team with 2 competing options: a table with the team’s principles as rows (one place to look, accuracy, how easy it is to define, upkeep) and each option as a column, including the way things work today. Today’s version was scored “not holding up.” The alert system could work, but it needs a deadline for every notification type, and most types have no natural deadline. The event system held up, and its cell for how easy it is to define read “One simple rule.”
The section I liked most came after the verdict, under the heading “What it commits us to.” Home to-dos have to be accurate and maintained, because nothing else will remind people. Anything that only exists as a notification gets promoted to home or dropped on purpose. People who use the panel as a to-do list today need a path across. The simpler model moves the work onto the accuracy of the other surface, and the team wrote that into the proposal itself, so nobody approves the simple rule thinking it means less work.
When you choose the simple rule, you’re signing up to keep the other surface accurate.
The pushback was good, and it came from every direction. A designer pointed out that some actions can’t be finished inside the product at all, like a phone call to someone outside the practice, so they behave more like notifications than to-dos. A product manager asked whether required and optional actions need to be split, using an expired card that updates itself as the example. On delivery, the board made a case I agree with: push is the most interruptive channel, so it needs the strongest reason to exist. And an email about something that’s already been fixed hurts trust, and you can’t take it back.
I came in with a different model, and it didn’t survive the room. I pitched something closer to the save-for-later list in a messaging app: one tap to save anything, and smart ordering that brings up what matters. The team answered with what they’ve seen in research. Clinicians work in distinct workflows, and they’ve resisted one giant list every time it’s been offered. I’d rather the team build on what clinicians have told them than on my analogy.
The proposal isn’t settled. The board marks its own weak spot, that the event system doesn’t hold up as cleanly for a home screen shared across a whole practice, and there’s a follow-up session on the calendar. Whatever lands, the reminders story is why I’d plan the transition as carefully as the model. A new name didn’t move anyone the first time.