K8.07.3conceptual versus visual consistency设计
冲突时应保持概念一致而非形式一致
别名: 概念一致 · 形式一致 · 跨端保对象不保像素
概念解释
「分享」在各端都要存在，指向同一件事：把当前对象交给系统里的另一个目标。iOS 用系统分享面板从底边滑出，Android 用 Sharesheet，电脑用菜单或拖放——外形不同，概念是一个。冲突时保概念、不保形式：对象叫什么、任务有几步、状态如何对应，跨端对齐；控件长什么样、放在哪一个平台槽里，跟该端惯例走。把 iOS 的工具栏像素搬到 Android 顶上，是形式一致；两边都能把同一条内容送进系统分享，是概念一致。当两者打架，丢掉的应是像素，不是对象。
机制
人迁移时带走的是对象和动词（这条内容、下载、分享、账号），不是某颗按钮的坐标。形式一致把坐标和皮肤也锁死，必然会撞上平台槽位：iOS 没有系统返回键，Android 没有等同的程序坞建议，桌面有悬停和菜单栏。锁皮肤就要在某一端造假控件，单设备成本立刻上升，而对象并没有因此更好认。概念一致只锁跨端都存在的那一层：同一内容在各端仍是同一条、同一账号、同一种「交给别的应用」的出口。出口的外壳可以完全不同，只要人还能用源设备上学到的动词找到它。选择保形式，通常是因为截图和品牌手册好看；选择保概念，是因为迁移测的是「我还找得到那件事」。
边界
平台完全没有对应槽位时（手表没有分享面板、电视没有拖放），概念也要降级：说清「这台设备不能把内容交出去」，而不是造一个看起来像分享、实际打不开任何目标的按钮。法律或商店规则强制的外形（必须用系统购买控件）优先于品牌形式，也优先于跨端皮肤。内部功能名如果会和系统用语撞车（应用里的「返回」和系统返回），概念层应避开系统词，以免概念本身被平台吞掉。全新平台上还没有稳定惯例时，形式可以暂时多借一端，待惯例形成再把外壳换过去，对象表保持不动。
怎么落地
- 先写跨端对象表和动词表，再为每端选择平台槽：分享走各端系统出口，设置走进各端系统设置或应用内设置的惯例位置，不要为了按钮对齐而自绘一套。
- 审查每一处「为了和另一端长得像」的控件：若它占用了该平台已有槽位，删掉自绘，把概念接进系统控件。
- 视觉规范允许各端皮肤不同；禁止把「图标必须在同一角落」写进跨端要求。
- 验证：列出五件跨端都有的事（打开同一对象、分享、进账号、下载、搜索）。在 iOS、Android、桌面上各走一遍，只检查对象是否能被同一套词找到、结果是否指向同一条数据。再让该平台的日常用户指出任何「不像这台设备上别的应用」的导航。对象对不上是概念失败；导航不像是形式抢了惯例。以后者换前者，不算通过。