Missing capabilities need explanation, not silent hiding

What it is

Pivot tables, plugins, and batch export that exist on the computer have no counterpart in the phone menu, and no sentence that says this device cannot do them. People conclude they are looking in the wrong place, or that the account lost a permission. A missing capability needs an explanation: a step this device cannot finish must be marked, pointing at a device that can, not erased from the UI. A meeting app that writes “screen share is unavailable here; join from a computer” is naming the gap. The same control simply not drawn sends people through settings again. The explanation is the gap itself, not what role the device usually plays.

Why it happens

Multi-device products almost never have equal capability sets: plugins, macros, hardware encode, external storage live on one end. Silent hiding keeps a small screen “clean” and destroys the feature map—“where that step lives,” learned on the large screen, becomes a hole. The default explanation for not finding it is self-blame: wrong account, feature retired, upgrade needed. If the gap is named as a capability reason (“pivot tables need a larger display and a pointer; open this file on a computer”), search stops and the person changes device. Hiding also blocks learning: new users never discover that the desktop has the capability, so the small screen looks like a broken product rather than an intentional slice. The copy has to name the step and a substitute device; “some features unavailable” says nothing.

Where it stops holding

Capabilities turned off by management policy (no download, no external send) are permission problems and should say policy, not “phones cannot do this.” A demo or lite mode that is intentionally browse-only should state its scope once on entry; per-gap banners become noise. When the capability exists and only the entry moved (menu bar on desktop, toolbar on tablet), treat it as findability and put a matching control, not as absence. Extremely small screens cannot list the desktop inventory; one summary (“full editing on phone or computer”) plus the few actions that do work is enough.

Applying it

• Leave a placeholder where a desktop-common step cannot run on the small screen: a disabled item, a banner, or “open on a computer.” Do not delete the step from the information architecture without a trace.
• Name the reason type (screen and input, a plugin, a piece of hardware) and a substitute device; deep-link to the same object on that device when possible.
• Do not hide the gap on one end and error on another; every end should admit the step exists and that this machine cannot finish it.
• Verify against ten capabilities actually used on desktop, searched on tablet and phone. Each “not found and unexplained” is a defect. After adding explanations, ask people who have never seen the desktop whether they now know the step exists elsewhere.

Related

• Within the group: K8.03.1 Allocate tasks by input capability and screen size · K8.03.2 The division of labor must be predictable
• Adjacent: K4.07 Division of labor and handoff with the phone · K8.07 Consistency versus platform convention
• Search terms: capability gap · feature unavailable · cross-device feature parity