Cross-device consistency lowers learning cost

What it is

Learning “Library / Shows / Downloads” on the phone should not require relearning “Favorites / Programs / Offline” on the computer. Cross-device consistency cuts the cost of picking up a second device: the same objects keep the same names, the same jobs follow the same conceptual path. A music app that cuts its library the same way on phone, tablet, and computer lets people carry learning they already paid for. Consistency here is objects and task structure, not a pixel-level move of the phone UI onto the desktop. It also does not license dropping a platform’s own back, share, or settings placement in the name of sameness—that raises the cost of using one device.

Why it happens

Skills and names built on one device become a global schema for the product. On a switch, people do not model from zero; they go looking for “downloads live here, account lives there.” Matching names, groups, and steps make the move recognition rather than new learning. Mismatches force inhibiting the old names and learning a synonym set, filling working memory with “what does this device call it.” Cross-device use already spends attention on the switch and on finding state; a second split in names makes the product feel like two products. The gain shows up on the second device and after. The first device never sees it, so single-device usability scores can erase the benefit.

Studying it

A cross-device transfer task: teach an object structure on device A (how the library is cut, how an item lands locally), then run an isomorphic task on device B with no tutorial. Compare “names and steps match” with “same functions, different names and grouping.”

Independent variables: whether object names match, whether step order matches, whether visual skin matches (to split conceptual from cosmetic consistency). Dependent variables: time to first completion on B, wrong-entry counts, times people use A’s names to point at B’s controls, a judgment that “this is still the same app.”

This is the usual inter-usability transfer probe, not a single-device SUS. Two devices side by side in the lab undercount memory decay; retesting B hours later is closer. Do not score “the desktop grew a menu bar” as inconsistency—that is a platform surface, as long as the objects remain.

Where it stops holding

Experts already hold separate schemas per platform; forcing one name set can slow them on that platform. Capability slices differ (the phone has no full timeline); consistency can only cover objects that exist on both ends, and must not pretend a missing step is present. White-label clients (a TV app that is a licensed lite shell) have a ceiling: keep core object names, not the whole information architecture. People whose first use is already on the “secondary” device gain nothing from transfer; there is no source schema.

Applying it

• Keep a name table for objects that exist on every end (library, downloads, account, share) and use that set everywhere. Do not let desktop say “Library” and phone say “My Music” for the same pile.
• Keep core task order isomorphic: find → open → save / download. An end that lacks a step should name the missing step, not invent another verb set.
• Do not fake consistency with a pixel port; lock names and objects first, then let layout follow each screen.
• Verify with people who have used only the phone for a week, opening desktop for the first time, tasked with “download last week’s show.” Record whether they walk to an entrance with the same name as the phone. Finding it only under “Favorites” or “Offline files” counts as a name mismatch.

Related

• Within the group: K8.07.2 Breaking platform convention raises the cost of using one device · K8.07.3 When they conflict, keep conceptual consistency rather than visual sameness
• Adjacent: K8.03 Division of capability across devices · K1.04 Platform differences in back navigation
• Search terms: inter-usability · cross-device consistency · transfer of learning