工业软件 UX 设计流程是怎样的

我们设计在设计工业软件的时候，不会只设计漂亮的线框图，信息层级清晰，配色克制，按钮精致，因为这些反而会让真个UI界面“花里胡哨”，下面一起看看关于工业软件 UX 设计的门道和流程吧。

第一步：别问需求，看动作

消费级软件可以靠问卷、访谈、用户画像起步。工业软件不行。用户嘴里说的“我希望查询更方便”，跟蹲在他背后看到的真实操作，往往不是一回事。

有次在化工厂中控室，操作工被问到“这个报警页面有什么不方便吗”，他说“挺好，习惯了”。但团队在身后看了他一个小时，发现报警弹出来后，他每次都要点好几层菜单去另一个系统里找联锁逻辑图，确认是不是误报。来来回回，一个报警处理要切三个画面。“习惯了”这三个字，不知道坑了多少设计团队。

所以我们后来的习惯是：先别提问，先看。看操作路径，看视线移动，看手上的东西——键盘、鼠标、对讲机、纸质台账，看环境里的温度、噪音、灯光。拍视频，记时间戳，画操作流程图。每一张流程图的拐弯处，都是可能的设计机会。

这个阶段不产出任何漂亮的图，只产出一个东西：对用户真实工作状态的理解。

第二步：把“经验”翻译成“规则”

工业软件的设计输入，很多时候不是一句“用户需要什么”，而是密密麻麻的业务规则、工艺流程、操作规范。这些东西如果不吃透，设计出来的界面就是花架子。

比如一个电力调度系统，线路停复役的操作顺序不是用户说了算，是安全规程说了算；一个配方管理模块，配方的下发权限和审核流程，可能涉及好几个国家和地区的合规要求。设计之前，团队会把相关规程的条目打印出来，拿马克笔标注哪些会直接影响界面结构，哪些会限制操作顺序，哪些会触发异常分支。

这步做不扎实，后面所有原型都是沙滩上的房子。而且通常会在这里就暴露出需求文档里没说清楚的地方——产品经理说“这个操作简单”，但规程里有且只有顺序错了就可能导致事故的约束条件。把这些提前挖出来，是设计公司能提供的核心价值。

第三步：纸笔先行，框架验证

规则理清楚后，不会直接打开 Figma。用最土的办法：白板画大框架，用马克笔在 A4 纸上画几种方案，或者用便利贴模拟界面的信息分区。把操作人员找来，指着纸上的框框问：“你要看的那个压力值，你觉得在这个位置能一眼找到吗？”

有一次做巡检 app，用 A4 纸画了扫描设备二维码后的状态页，结果几个老师傅看了看，说：“你们把这儿，就是那个 B 类振动值，挪到最上面吧，这是我们每次都要看的东西。”就这么一句话，省了好几天的开发试错。

这一步的核心是构建信息架构和导航框架，不纠结 UI 细节。让用户参与进来，在纸面上拉扯、修改，找到真正贴合他们心智模型的结构。

第四步：低保真原型——用复杂度去测试复杂度

框架定了，才进原型工具。但这个阶段依然是低保真，只关注交互流程和操作逻辑，不上颜色，不做图标。重点是模拟真实的操作复杂度：比如一个操作要切换多个页面，就老老实实把这些页面都做出来；一个操作要键盘和鼠标结合，就用原型模拟这种结合。

然后把这套低保真原型带到车间或中控室，让操作人员用真实设备在真实环境里测。通常让他们用自己的账号登录，做日常会做的工单。在一边观察，记下在哪个节点犹豫、哪个地方反复回退、哪个地方误触。

这个过程我们内部叫“复杂度测试”，看设计能不能承受真实业务的复杂度。过不了，改，再测。

第五步：视觉设计——克制，再克制

工业界面的视觉设计，最高境界是“不被注意到”。信息必须极度清晰、无歧义、在恶劣条件下可识别。

有几个原则是写进团队规范里的：

• 颜色不是装饰，是编码。红色只用于紧急停机、故障报警、禁止操作；黄色用于预警；绿色用于正常运行。禁用红绿搭配之外的所谓“品牌色”。

• 字体要能扛住劣质显示器。很多老厂房的屏幕，亮度衰减、对比度变差，字体小一点就糊了。正文最小字号一般会设得比移动端标准大两号。

• 信息密度要符合实际注意力分配。中控室大屏上，一个页面里操作员真正关注的可能就是中间几个关键参数，其余信息要收折或弱化。

• 响应指示不能只靠颜色。报警必须同时有声、光、色，甚至振动，防止任何单一感官在疲劳状态下失效。

这一步会沉淀出一套组件库和设计规范，之后每一个产品迭代都在这个基础上生长。不是束缚，是保命。

第六步：异常路径测试——工业 UX 的硬骨头

这一步，可能是工业软件跟消费产品最大的分水岭。消费产品测试，很多时候测的是“这条路能不能走通”。工业软件测试，重点要测“这条路如果走不通，会发生什么”。

操作员输错一个值会怎样？网络延时导致数据不刷新会怎样？误触了急停旁边的按钮会怎样？一连串报警同时到来，操作员能不能在 30 秒内识别出最关键的那个？这些场景必须抽象出来，形成专门的异常路径测试用例，在原型上逐条跑，而且是反复跑。

团队见过一个真实的教训：某厂的操作界面在断网后，失去连接的测量点不是显示“离线”或变灰，而是保持在最后一次接收到的数值不变。结果操作员看了半小时假数据，判断失误。这种问题在正常流程测试里永远不会暴露，但异常路径测试可以。

第七步：现场验证——在噪音里做可用性测试

终于到了现场验证。这次不是拿低保真原型，而是接近交付的版本，在真实的生产环境里跑。操作人员在旁边干他们的活，团队在旁边观察。在他们没有被指导的情况下，看能不能独立完成关键操作、遇到异常能不能恢复正常。

通常会带一张检查清单进去：关键参数读取时间、报警响应流程、高频操作步骤、误操作恢复等。然后记下每一个不符合项的严重程度：是影响效率？还是可能导致误判？还是存在安全风险？分等级，出报告，跟进修改。

这一步往往比实验室里做的可用性测试有用得多。仪器震动把字体晃到看不清、手套触屏导致误触、对讲机噪音盖过了界面提示音——这些问题只有在现场才会显形。

第八步：持续跟踪——迭代的时间尺度是“年”

工业软件的迭代周期，比消费端长得多。一个版本上线后，可能要过半年、一年才会做一次大改。但这不意味着 UX 在这段时间可以不管了。

团队通常会建立几个持续的信息渠道：培训部门的反馈，说新人在哪些界面上卡住；设备科的维护记录，看看哪些报警最常触发但实际没故障——可能是界面表达让人误判；一线班组的交接本，记录系统使用中“奇奇怪怪的问题”。这些信息持续收回来，就是下一个版本的需求池。

工业系统的 UX 优化，讲究的不是快，是稳。一次改太多，现场人员要重新适应，反而增加出错概率。所以倾向于一年做一次大的界面评审，中间只做针对性的安全相关的补丁改动。

最后，做工业软件 UX 这些年，团队最大的感受是：别太把自己当设计师。我们更像翻译，把复杂的工业知识、安全规程、操作经验，翻译成一个在四十度高温、八小时疲劳、突发状况下还能让人安全高效工作的界面。