需要同时保持全局与局部
别名: 全局与局部协调 · overview plus detail
概念解释
全局与局部并存（overview plus detail）指操作员在查看设备细节时，仍能判断该对象在整个过程、区域和任务中的位置与影响。它不是简单把一张全局图和一张细节图拼在一屏上，而是要求两张图能互相对应——选中局部的一个对象，全局图上要能立刻看出它在哪、影响谁；反过来也一样。做不到这层对应，两张图只是两份互不相干的资料。
机制
诊断任务要看清具体数值、具体接线、具体阈值，这需要局部精度；判断这个故障会不会连锁到别处、该不该现在处理，这需要全局结构。两类判断用的是不同尺度的信息，若只给一种，另一种判断就没有依据。
页面切换的代价不在“翻页”本身，而在工作记忆要承担尺度转换：从局部跳回全局后，得重新确认“我刚才那个对象在哪”。这一步转换的成本高低，取决于两张图是否共用同一个参照系。如果全局图和细节图画的是同一套空间坐标、同一套对象编号——比如都是同一张工艺流程图，只是缩放比例不同——切换只是一次查找，靠联动高亮就能补上，代价很低。但如果两张图的几何完全不同——全局图是厂区地理布局，细节图是回路原理图，两者的方位、形状对不上——操作员每次都要在脑内做一次坐标变换，光靠同步高亮解决不了这层代价，因为问题不是“找不到”，是“换算不过来”。这是判断该不该指望联动交互解决协调问题的分界点：两张图能不能投影到同一参照系，决定了联动能不能顶替专门设计。
由此也能解释三类常见技术各自的取舍：分屏并显不需要坐标变换但占屏幕面积；焦点加上下文（focus+context，如鱼眼变形）保留单一画面但几何失真本身会干扰精确读数；独立分页缩放代价最高，但能容纳的系统规模不受屏幕面积限制。选哪种不是审美问题，是由参照系是否统一、屏幕面积和系统规模共同决定的。
怎么研究
比较分屏、焦点加上下文与分页界面时，可测故障定位时间、跨层回退次数、全局状态问题准确率和错误操作次数。任务设计必须同时要求局部诊断和全局影响判断，两者缺一都测不出协调能力——如果任务只是“找到某个变了的读数”，那测的是局部搜索速度，不是全局与局部的协调，即便某种界面在这类任务里更快，也不能说明它在真实故障处理中更安全。
边界
小屏、移动终端和极高密度的过程图无法持续展示完整两层；强行并置会挤压关键细节的可读面积，这类设备上宁可选一种主视图配合按需查询，而不是硬凑两屏。
协调设计也解决不了表征不对应的问题：如果局部视图展示的是全局图里根本没有建模的对象——比如某个设备的内部固件状态、寄存器值——全局图上没有对应位置可以高亮，再强的联动交互也补不上这层缺口，唯一的办法是先在全局图里给这个对象留一个位置。
全局图也不是事实全貌：聚合展示可能把少数但严重的局部异常平均掉，看起来一切正常，靠全局图做风险判断本身就有这层局限。
怎么落地
概览应持续显示操作员当前所在位置、被影响的范围和关键全局状态，不能只在打开时显示一次；局部选中的对象要在全局图上同步高亮，时间游标要跨视图联动，避免两边看的不是同一时刻的数据。
选技术前先判断两张图是否共用参照系：共用的话优先用分屏加联动高亮，代价低；几何不同的话，与其做自动化的视觉扭曲，不如放一个明确的定位提示（比如缩略地图上标一个点），成本更低也更不容易读错。
验证办法：设计跨尺度故障演练，记录操作员定位到局部故障所需时间，以及随后回答“这会影响哪些区域”这类全局问题的正确率。两个指标都要低于基线才说明协调设计真的生效；如果只是定位变快了，全局判断正确率没有改善，说明改进的只是导航速度，没有解决协调问题。