Lufthansa Systems 用真实数据检验驾驶舱地图原型

设计师在画布上安排地图信息设计时，通常会选择一个合适的缩放比例，让标记、标签和路线各就其位。但飞行员使用驾驶舱地图时，看到的画面始终在变化。他们需要缩小地图查看更大范围的航路，再放大确认局部情况；原本分散的飞机标记可能挤在一起，清楚可读的标签也可能遮住路线。设计稿里看似妥当的信息安排，到了连续操作中，未必仍然有效。要判断哪些信息应该保留、哪些应该随缩放收起，设计团队需要让地图真正运行起来，观察飞行员能否在变化中找到所需信息。

2026 年 10 月 22 日，Figma 公布了航空软件公司 Lufthansa Systems 的原型实践。其 Lido Pilot Apps 运行在驾驶舱的 iPad 上，为飞行员提供航路、机场和天气等信息。团队从去年开始尝试 Figma Make，将既有设计与动态地图数据结合，用于测试复杂的地图交互。

过去，Lufthansa Systems 的设计团队主要用静态设计稿和手工制作的原型与飞行员讨论方案。这些材料能够展示地图的布局，却难以还原连续操作的过程。飞行员看着截图，可以指出某个标签太小、某处信息不够清楚；至于缩小地图后还能否找到目标，多个标记靠近时是否容易选错，就很难仅凭画面判断。设计师需要解释接下来会发生什么，飞行员则要根据这些解释设想自己的操作。双方讨论得再仔细，也可能遗漏实际使用时才会出现的问题。

1. 原型接入数据

为了让飞行员能够直接操作尚在探索中的方案，团队将已有的地图与设计稿接入了 Figma Make。作为基础的是一套内部使用的 Mapbox 网页地图，它与正式的 iPad 应用共享数据。设计师再把 Figma 中的顶部栏、底部栏和图层图标加入原型，让飞行员在熟悉的界面中尝试新的交互。这样，团队便有了一个可以修改和测试的环境，不必为每次探索重新搭建地图，也不必立即改动正式应用。

空中交通信息是其中一项研究内容。团队接入提供航空交通数据的 OpenSky Network，以一个模拟位置为中心，在周围五百海里内显示飞机标记。飞行员可以点击其中一架飞机，查看呼号、机型、速度和相对高度。这些数据让原型具备了可供观察的交通分布，也让点击、缩放等操作有了相应反馈。飞行员面对的仍是研究用的模拟环境，但已经能够亲自尝试一项操作，再判断结果是否符合预期。

2. 在变化中检验

有了这样的原型，地图的信息密度便可以在操作中讨论。缩小地图时，更多飞机进入视野，如果所有标记和标签都保留，航路可能被遮挡；隐藏得过早，又可能让飞行员找不到自己关心的目标。团队需要确定，交通信息应当从哪个缩放级别开始出现，以及不同尺度下应该显示多少细节。飞行员可以一边缩放，一边指出哪里需要更多信息、哪里已经难以辨认，设计师也就能够根据实际操作调整方案。

机场地图中的状态变化提出了另一个问题。受访者介绍，飞机起飞后，标记需要改变颜色，以区别地面与空中交通。把起飞前后的画面并排展示，只能帮助团队比较两种颜色是否容易区分。飞行员能否在查看地图时及时察觉变化，还取决于标记何时变色、周围有多少信息，以及当时的注意力在哪里。原型让这个过程连续发生，团队才有机会观察颜色变化是否传达了预期的信息，而不只是确认配色本身是否合适。

这些测试也会打破静态设计稿中经过安排的秩序。设计师绘制页面时，往往会选择足以说明方案的内容和位置；数据进入地图后，标记却可能集中在同一区域，标签也可能覆盖重要路线。原本在某个比例下清楚的布局，经过一次缩放便不再成立。让这些情况提前出现，正是动态原型的用途。团队可以在方案尚易修改时发现问题，而不必等到开发完成后，才重新讨论信息应该怎样组织。

不过，接入数据并不等于原型已经能够验证所有设计问题。研究标记是否过于拥挤，需要有代表性的数据分布和缩放行为；研究起飞后的颜色变化，则需要保留状态转换的过程。团队应当根据研究问题决定哪些部分必须接近实际使用，哪些部分可以简化。否则，一个运行流畅的原型仍可能避开最需要检验的条件，让测试得到过于乐观的结果。

Lufthansa Systems 的正式应用使用 SwiftUI 开发，Make 原型承担的是前期探索。团队借助它与飞行员反复讨论尚未确定的行为，确认方向后，正式产品仍需经过自身的开发与验证流程。

这项实践让设计师获得了更充分的讨论依据。过去，飞行员主要评价设计稿呈现出来的状态；现在，他们可以通过自己的操作发现问题。AI 在这里帮助团队缩短了从设计设想到可测试方案的距离，而原型是否有价值，最终取决于它能否让飞行员遇到那些真正影响使用的问题。