K4.01.2glanceable conclusion not entrydesignresearch

The first screen must state a conclusion, not offer an entry

Aliases: glanceable result · answer on wake · not a menu

What it is

The screen that lights on a watch raise must be a finished conclusion, not a doorway still waiting to be tapped. The question on a raise is “how are things now,” not “where can I go from here.” Heart rate 142, next bus in 3 minutes, meeting in 10 minutes—those are conclusions. “Open Fitness,” “see the timetable,” “enter Calendar” are entries. An entry postpones the answer until a second action that usually never happens. This entry is about the speech act of the first screen: assertion versus invitation. It is not about how many seconds a look lasts, and not about how many foci fit on one screen.

Why it happens

A glance is a closed loop: the question exists before the raise; the display only has to fill the slot. An entry page splits the loop into “see something tappable → choose which → wait for the next screen.” Each extra hop needs an aim and a confirm, and the wrist can drop mid-hop. Busy entry pages make it worse: icons, lists, and “view details” all imply that the information lives elsewhere, so people read the busyness as “no answer here” and give up. A conclusion page allows zero-input success—the eyes finish the task; the hands can stay still. For a display worn on the body, looking without touching is the default success path.

Studying it

Test first-screen answerability, not app open rate. Give a question written in advance (“will this run be late,” “is it time for the dose”), show only the first screen, forbid further taps, and see whether the person can judge correctly before the wrist drops. Contrast the same data rendered as an entry (buttons, rows) versus as a conclusion (one assertion plus a status color).

Independent variables: conclusion versus entry on the first screen, specificity of the conclusion, presence of a “see more” lure. Dependent variables: judgment accuracy from the first screen alone, rate of attempted taps onward, confidence.

“See more” contaminates the measure: failure shifts from “did not understand” to “I meant to drill.” Count attempted drills separately; do not score them as success. A lab that allows unlimited tapping is measuring navigation, not glancing.

Where it stops holding

Settings, pairing, and first-run consent are “go somewhere and do a thing”; an entry as the first screen is not an error because the question was never a query. Complications on a watch face are already summaries in conclusion form; this claim applies to the screen after a complication is opened. Multi-day forecasts and full threads have no single conclusion; compressing them into one sentence lies. Treat those as outside glance scope rather than dressing an entry as a conclusion.

Applying it

  • Write the question the wearer asks on raise, then write the sentence the screen answers; that sentence must not have “tap to view” or “open app” as its only readable content.
  • Finish the computation before wake: the phone or server produces “8 minutes late”; the watch renders that sentence, not a list still waiting to be filtered.
  • If depth is needed, put a secondary action beside the conclusion, at strictly lower visual weight, so the first screen is not read as a menu.
  • Verify by covering the watch, asking the user question aloud, then showing only the first-frame screenshot with taps disabled. Anything that cannot be answered was an entry posing as a first screen.

Related

  • Within the group: K4.01.1 A watch glance lasts a few seconds · K4.01.3 Wrist-raise angle limits the visible region
  • Adjacent: K4.05 Information Compression · K4.06 Watch Faces and Complications · K1.06 Widgets and Lock-screen Entry Points
  • Search terms: glanceable · first screen conclusion · zero-input success

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/K4.01.2