目录
大多数交互式原型都容得下"差不多“。如果按钮动画慢了一拍，或者屏幕滞后于点击，最坏的情况也只是带来稍显尴尬的用户测试。但航空领域则不同。当你设计的界面介于飞行员和飞机的控制装置之间时，“差不多”是远远不够的。交互必须与现实一一对应，因为这关系到人员的安全。
这就是我们的创意技术团队着手探索的问题：我们能否仅使用 ProtoPie、飞行模拟器和一些现成的硬件，来构建一个逼真到可以实际飞行的驾驶舱体验？
最近，我们在一次网络直播研讨会中完整演示了这一构建过程，创意技术专家 Eric Lee 带领我们了解了该项目标幕后细节。本文涵盖了其中的重点，而完整的研讨会视频则对实时演示、插件代码以及涵盖从模拟器兼容性到虚幻引擎支持等所有内容的问答进行了更深入的探讨。
挑战：要原型化的是驾驶舱，而不只是屏幕
团队选择了 Joby eVTOL 作为原型对象。eVTOL 是一种兼具直升机和固定翼飞机特性的飞行器，需要在悬停和向前飞行之间切换，这意味着驾驶舱 UI 必须能呈现两种截然不同的飞行模式，同时又不能让用户觉得这是两个不同的产品。
这次的任务要求超越静态稿，做出一个飞行员真的能操作的东西：真实的飞行操控、真实的飞行模拟器提供数据、屏幕对数据的响应方式与真实飞机完全一致。没有预录动画，没有模拟的"如果……会怎样"的场景。
如何用 ProtoPie 构建航空驾驶舱原型
航空驾驶舱原型的软件栈
在软件方面，技术栈如下：
ProtoPie Studio 用于设计界面
ProtoPie Player 用于运行界面
ProtoPie Connect 用于将所有内容连接到实时数据
Visual Studio Code 和 Python 用于桥接应用程序逻辑
Unity 用于 3D 图层
Microsoft Flight Simulator 2024 作为飞行数据的唯一真实来源
浏览器，以 Web View 形式承载原型
航空驾驶舱原型的硬件
硬件包括：
两块触摸屏显示器，用于两个主显示屏
一台平板，作为辅助面板
一个航空摇杆，用于实际飞行输入
一台电视，用于运行模拟器本体
一台游戏 PC，GPU 性能足以同时运行飞行模拟器并驱动所有屏幕
ProtoPie Connect 如何将飞行模拟器连接到原型
整个架构比最终演示看起来要简单得多。飞行模拟器和摇杆运行在一台 PC 上。这台 PC 同时运行一个小型自定义插件，它监听模拟器的实时飞行变量——高度、速度、航向、飞行模式等——并将这些数据转发给 ProtoPie Connect。Connect 再把数据分发给所有需要它的原型，每个原型都作为独立的浏览器屏幕运行。
在这次构建中，一共是三块屏幕：
主飞行显示器（PFD）
多功能显示器（MFD）
一个简化的飞行计划面板
然而，Connect 的网页视图并不局限于三块屏幕；类似这样的项目完全可以用同一条管线驱动五六块屏幕。
三块驾驶舱显示屏的内部拆解
多功能显示器(MFD)
MFD 负责处理电源、飞行控制、已用时间和航程，此外还嵌入了一个用 Unity 构建的飞机 3D 模型，直接集成在 ProtoPie 原型中。这个 3D 图层不只是装饰：当飞行器在悬停和向前飞行之间切换时，螺旋桨会真实地在垂直和水平之间旋转，实时同步模拟器中的状态。
主飞行显示器（PFD）
PFD 承载的是更关乎安全的关键信息：实时速度、高度、罗盘航向、俯仰和横滚，叠加在一个嵌入的 Mapbox 图层上，显示飞机在真实地图上的实际位置。
Garmin 触摸屏控制器
第三块屏幕——一块 Garmin 风格的触摸屏面板，显示飞行计划——是三块屏中刻意做得最简单的一块，因为它承载的安全关键信息最少。一旦团队开始考虑延迟问题，这个区分的重要性就比预想中大得多。
构建一个航空驾驶舱原型需要多长时间？
三个人做了大约一个半月——而且大部分时间根本没花在原型制作上。
其中两到三周用于调研：理解飞行员的工作流程、坐进飞行模拟器、在动笔设计一个像素之前先感受真实驾驶舱的布局。两块主屏幕各花了大约一周到一周半的时间来构建并接入实时数据。一个更简单的辅助面板，只显示飞行计划，花了一两天。
ProtoPie 帮助团队在几周内就从调研推进到了可运行、连接硬件的原型，而不是几个月。作为对比，团队估算，如果用传统流程构建同样的体验——写出完整的 UI 规格文档，交给工程师从零开始编码——现实中大概需要四到六个月，主要因为实现和打磨复杂、连接硬件的交互需要大量的来回沟通。
优势不仅仅是更快地做出 UI，而是更早地得到一个真实、可测试的体验，让团队在投入完整工程开发之前，就能看到设计在实时数据和物理操控下的真实表现。
航空驾驶舱原型设计：常见问题解答
问题 1. ProtoPie Connect 能与其他飞行模拟器协同工作吗？
Eric Lee：可以，这套方案适用于大多数飞行模拟器。对模拟器的类型没有严格要求。唯一的要求是，只要你能从模拟器中提取遥测数据，并能编写代码把数据发送到 ProtoPie，那么任何模拟器都可以用。
问题 2. 将飞行模拟器数据连接到原型需要多少代码工作？
Eric Lee：其实不多，相当简单。我们为 ProtoPie 构建的自定义插件，底层基于 Socket.io，这是一个非常简单的收发库。对于像摇杆这样的实际硬件，ProtoPie Connect 里已经内置了专门的插件。如果某些摇杆不工作，你也可以为它们创建自定义插件。
问题 3. 更新一个连接硬件的原型有多快？
Eric Lee：改动几乎是即时的。你在我的屏幕上看到的所有内容，我都可以在 ProtoPie Studio 里即时改动一个按钮、遥测数据或响应，它会自动反映到原型上。
问题 4. 飞行模拟器数据和原型之间有多大延迟？
Eric Lee：延迟基本上可以忽略不计。我们没有遇到延迟或卡顿的问题。
问题 5. 与真实硬件协作会如何改变设计师从用户测试中学到的东西？
Eric Lee：你能在整个产品生命周期中省下大量时间。你不需要回到程序员那里去改东西，而且你在体验中想要的大部分东西，驾驶舱里本来就已经有了，所以你可以直接用真实用户来测试，在产品生命周期中更快地发现错误、找到改进点。
问题 6. 模拟器主要用于飞行，还是也可以应用于其他行业？
Eric Lee：ProtoPie 最初是为手机和桌面端构建的，后来扩展到智能电视和智能手表，再后来是汽车，现在是航空，所以它当然也能轻松应用到像机器人这样更复杂的领域。
超越航空：原型化连接硬件的体验
这个驾驶舱背后的技术并不局限于航空。
同一套 ProtoPie Connect 配置可以用来把原型与其他系统的实时数据连接起来——ProtoPie 已经在汽车 HMI 原型中使用了类似的方法。
这个更广泛的模式适用于任何体验依赖于屏幕之外事物的产品：车辆、机器人、工业设备、联网设备，以及其他由硬件驱动的产品。
工作流从界面设计开始。设计可以从 Figma 或 Sketch 导入 ProtoPie Studio，现在也越来越多地通过 ProtoPie 的 MCP 集成进入 AI 辅助工作流。从那里开始，Connect 在原型和它周围的真实世界系统之间架起桥梁。
"任务关键型"对航空原型设计意味着什么
在一个连接硬件的原型中，并非每块屏幕都值得投入同等的工程精力，而这个项目给了我们一个有用的教训：哪些屏幕值得。飞行计划面板可以容忍一点延迟，没人会注意到。但主飞行显示器不行——速度、高度和航向需要足够紧密地跟随模拟器，才能让"飞这架飞机"真的感觉像在飞。团队最终把遥测更新频率定在大约每四分之一秒一次；他们也测试了一到两秒的刷新率，明显不够顺滑。这类调优，在屏幕稿上很容易被跳过，而一旦真实硬件和真实操控输入进入闭环，就变得不可能跳过。
你脑海中也有一个连接硬件的原型想法吗？与我们的团队聊聊，了解 ProtoPie Connect 能够为你的用例做些什么。
