Unify the conceptual model, not control appearance

What it is

What actually has to match across platforms is whether an object is the same object, how the task is carved, and what the states are called: what a draft is, which fields share takes, whether “ordered” and “paid” are two steps. What does not have to match is the appearance of the controls that invoke those objects. An iOS back chevron in the navigation bar and Android system Back plus a top app bar can still be one conceptual stack. Unifying the skin—drawing the same custom back icon on both ends—asks for sameness on the wrong layer. Users recognize “this is still that draft,” not “the back button’s shape matches the brand manual.”

This is which layer consistency belongs on—not the mistake of one pixel set hitting both platforms, and not whether brand color belongs on content or on the frame. The conceptual model is the product’s language. Control appearance is a vocabulary the platform already lent the user.

Why it happens

People treat an interface as operations on real objects. Once object identity splits across ends—undo on one side becomes delete on the other, “Photos” on one side is “Space” on the other—cross-end users decide they are looking at two products. How the control is drawn does not enter that identity check. A system switch and a branded switch that both mean on/off share a model; two identical capsules, one a switch and one a button, have already split the model.

Appearance is left to the platform because that vocabulary was already learned in the system apps; teaching it again adds nothing. The conceptual layer has to be taught by the product, and can only be taught once: if object boundaries differ per platform, teaching cost doubles and does not transfer. The right unification is one object dictionary plus one task structure, wearing two platform shells. The wrong unification is one shell plus two quietly forked objects.

Where it stops holding

Platform-bound capabilities (share extensions on iOS, intents on Android, card messages in WeChat) cannot be forced into one action at the conceptual layer either—giving them the same name hides that they carry different fields. Games and brand campaigns that treat controls as visual expression have a thin model; unifying appearance hurts less than unifying an object layer that is not there. Accessibility names should follow the concept (“Draft,” “Send”), not the skin (“blue capsule”); skin unification can make the reader speak words that do not map to system control types. If a cross-platform framework wraps system controls into one look, the conceptual layer still has to be maintained on its own. A unified shell is not a unified object.

Applying it

• Write one shared dictionary of objects and tasks (what objects, states, actions, and failures are called, and where they end) before choosing system controls on each platform to say those words.
• Do not accept “the buttons look the same” as the consistency test. Accept “the same object can be recognized, and the same action changes the same state.”
• Keep platform-specific actions under platform-specific names and exits. Do not invent a name both ends would be lying about just to keep the dictionary tidy.
• Verify by reading the object dictionary—no screenshots—to people who have used both ends, and asking whether this is still one product. Then have them point to “draft” and “share” on each end, checking that they hit the same object and that the fields taken match the dictionary. Any end that needs the button’s shape to recognize the object unified the skin.

Related

• Same group: R4.06.1 Breaking platform convention raises per-platform learning cost · R4.06.2 Cross-platform unification can violate both conventions at once · R4.06.4 Convention draws its force from experience accumulated elsewhere · R4.06.5 Brand occupies the content layer; convention occupies the frame · R4.06.6 Departing from convention requires a visible compensating gain
• Adjacent: R4.14 The consistency cost of cross-platform frameworks · R1.07 Tension between design systems and brand expression
• Search terms: conceptual model · object identity · task structure · chrome versus content