Acting on the notice should skip launching the app
Aliases: notification actions · inline reply · shade actions
What it is
An actionable notification puts the next step on the card: reply, archive, snooze, approve, mark done. The work finishes in the shade or on the lock screen without bringing the whole app forward. What is saved is not one fewer tap on an icon. It is a task switch: load the home surface, find the object, then do the action the card already named.
This is about which actions earn a place on the notice. It is not how the card acknowledges success afterward, and not which actions are too dangerous to live here.
Why it happens
Walking from a notice into an app pays a full resumption bill: a new information architecture, maybe an auth wall, the object buried in a list. When the next step is short, reversible, and already contextualized on the card (this sentence, this invite, this archive), that bill exceeds the action. Leaving the action on the card means working memory does not have to unload the primary task for long.
Not every event has such a short action. Comparison, long editing, images, picking people—the card cannot hold enough context, and opening the app is the right move. Stuffing "Open" in as an action does not save a switch. It adds a button.
Studying it
Deliver the same event class as "tap opens the app" versus "primary action on the card" while someone is doing something else. Compare time to finish the event, whether it is finished, and how long the primary task is down.
Independent variables: primary action on the card, extra input required (reply field), whether the lock screen allows the action. Dependent variables: completion without launching the app, primary-task down time, error rate.
If the lab makes "handle the notice" the assigned task, willingness to enter the app is overstated. Allow ignoring. Lock screen and shade often expose different action sets; measure them apart, and do not infer lock-screen success from shade success.
Where it stops holding
Managed devices may forbid lock-screen replies. Encrypted threads cannot show a body while locked; the only honest action is "open and unlock." On a weak network, a card action that submits optimistically and fails later in-app will be read as done. Broadcasts with no stable object ("you have new activity") cannot host a real action; skip the shortcut.
Applying it
- For types with a single short reversible next step, put that step on the card: archive, reply, accept, complete, snooze.
- For types that need long context, keep a deep link to the object; do not disguise "open the app" as an action.
- Name the object next to the button so adjacent cards are not pressed by mistake.
- Verify by pushing an archivable mail mid form-fill. If most people still open the app to archive, the button is invisible or does not look live; if shade archive succeeds and the form is intact, the shortcut actually saved a switch.