J1.01.3understandabledesignresearch

Presentation is not the same as being able to understand the information and the action

Aliases: POUR understandable · predictability · consistent language

What it is

The envelope arrived and it can be torn open; the letter is a cipher that changes every page. “Submit,” “Next,” and “Finish” each appear once in the same flow; the error says only “invalid input”; a session dump happens mid-form with no mention of a timeout. Understandable is about decoding: the signal has arrived, the control can fire, and the person still cannot map them onto “what this is, and what happens next.” Contrast is not the missing piece. Neither is a keyboard event.

It is often shrunk to “write shorter sentences.” Short sentences do not stop a verb from changing between pages, or an icon from meaning delete here and archive there.

Why it happens

Understanding is model matching: lining up the word, the place, and the feedback with “how this kind of interface usually runs.” Matching needs stable wording, stable layout, and an error that still names which rule broke. Jargon, buttons that rename themselves, and failures with no sequel raise the matching cost until people quit — including people with no cognitive diagnosis, who are tired or working in a second language.

The second layer is that predictability outruns diction. Plain language helps; what makes an action understandable is the same action under the same words, the same place holding the same job. Every character can be readable and “why that click emptied the cart” still opaque. POUR lists this on its own because perception and operation can succeed and decoding can still fail.

Studying it

Run a copy-out-of-context comprehension test: print button names, labels, and errors as a list, no screenshot, and ask people new to the product what happens on press and which field to fix. Add a consistency audit: same action, different pages — wording, icon, placement. Readability formulae (Flesch and kin) are coarse filters, not proof — they do not know domain terms, and they do not know whether “Next” and “Submit” are the same move.

Independent variables: cross-page wording consistency, whether errors name the field and the repair, presence of a timeout explanation, whether the language is the user’s first language. Dependent variables: prediction accuracy by people who have not seen the UI, mid-task lostness, abandonment attributed to not understanding.

Cognitive walkthroughs and think-aloud fit better than automation. Checkers barely see “understandable,” because they do not hold a human model.

Where it stops holding

In professional tools used by trained operators, domain terms can be more understandable than forced colloquialism — then consistency and a lookup glossary matter more than “replace every word with a short one.” In live collaboration, state changes caused by other people cannot be fully predicted; understandable recedes to a visible log of who changed what, not to guessing in advance. Legal and clinical mandatory phrasing cannot be sloganised; a human-language layer has to sit beside the mandated text, not instead of it. Severe cognitive disability needs more than consistent verbs (step decomposition, memory support). The principle is a floor, not the whole of cognitive accessibility.

Applying it

  • One verb and one place per action across the product; rename globally, never “Save” on one page and “Write” on the next.
  • Errors name the field, why it was refused, and what to change. A lone “invalid” is not an error message.
  • Timeouts, autosave, and data-destroying actions must be named, before they happen, in the words the person is already using.
  • How to check: turn key buttons and errors into slips of text with no UI, and ask someone new to predict the consequence; then overlay the real pages and list every wording mismatch. Each wrong prediction and each mismatch is decoding failing — not a problem that larger type will fix.

Related

  • Same group: J1.01.1 Information must still be gettable when a sensory channel is missing · J1.01.2 Every function must be triggerable from an input method the person can use · J1.01.4 Content has to remain parsable by the assistive technologies people actually use
  • Nearby: J4.05 Plain language · J4.07 Cognitive accessibility · J4.11 Consistency as cognitive support
  • Search terms: understandable · POUR · predictability

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J1.01.3