When they conflict, keep conceptual consistency rather than visual sameness

What it is

“Share” should exist on every end and mean one job: hand the current object to another target on the system. iOS slides up a share sheet, Android uses Sharesheet, a computer uses a menu or drag-and-drop—different shells, one concept. On conflict, keep the concept, drop the form: what objects are called, how many steps a task has, how state lines up, stay aligned across ends; what a control looks like and which platform slot it occupies, follow that end’s convention. Moving an iOS toolbar pixel-for-pixel onto Android is formal consistency. Being able to send the same item into system share on both is conceptual consistency. When they fight, lose the pixels, not the object.

Why it happens

What people carry across a switch is objects and verbs (this item, download, share, account), not a button’s coordinates. Formal consistency freezes coordinates and skin too, and then hits platform slots: iOS has no system Back key, Android has no equivalent of Dock suggestions, desktop has hover and a menu bar. Locking the skin forces fake controls on one end, single-device cost jumps, and the objects are no easier to recognize. Conceptual consistency only locks the layer that exists everywhere: the same item is still the same item, the same account, the same kind of “hand to another app” exit. The exit’s shell can differ completely, as long as the verb learned on the source still finds it. Choosing form is usually because screenshots and a brand book look tidy. Choosing concept is because transfer measures “I can still find that job.”

Where it stops holding

When a platform has no matching slot (a watch with no share sheet, a TV with no drag-and-drop), the concept must degrade: say this device cannot hand content out, rather than draw a share-like button that opens no targets. Legal or store-mandated chrome (system purchase controls) outranks brand form and outranks cross-end skin. If an in-app name collides with system language (an app “Back” versus system Back), the concept layer should avoid the system word so the platform does not swallow it. On a brand-new platform with no stable convention yet, form may temporarily borrow one end; swap the shell later, keep the object table still.

Applying it

• Write the cross-end object table and verb table first, then pick a platform slot per end: share through each system exit, settings in each system’s usual place. Do not homemade a set so buttons line up.
• Audit every control that exists “to look like the other end.” If it occupies a slot the platform already owns, delete the custom chrome and wire the concept into the system control.
• Visual language may differ per end. Do not write “the icon must sit in the same corner” into a cross-end requirement.
• Verify five jobs that exist on every end (open the same object, share, account, download, search) on iOS, Android, and desktop. Check only that the same words find the object and that the result is the same record. Then ask everyday users of each platform to flag navigation that “doesn’t feel like other apps on this device.” Objects not lining up is a concept failure; navigation that feels foreign is form stealing convention. Trading the former for the latter is not a pass.

Related

• Within the group: K8.07.1 Cross-device consistency lowers learning cost · K8.07.2 Breaking platform convention raises the cost of using one device
• Adjacent: K1.04 Platform differences in back navigation · K1.07 System share sheet · K8.03 Division of capability across devices
• Search terms: conceptual consistency · visual consistency · inter-usability