How to apply common GUI design guidelines to the industrial environment, from safety to user training.
Is there a simple way to determine what design principles should apply to industrial products and which should not? Certain design and development practices have made their way from consumer into safety-related markets over time. But as I discuss in my blog, 7 industrial GUI development trends, not every trend that’s applicable to consumer devices works for industrial software. In fact, some consumer design principles are completely contrary to how GUIs should be designed for industrial products.
What makes an industrial system different? I’m going to look at four trouble areas when applying commonplace GUI design guidelines to industrial practice and explain what to do about modifying or adapting them.
The biggest differentiator between industrial and consumer products is that of safety. Mistakes in industrial software can have massive scope, while by comparison, the impact of errors in consumer, web, or mobile software is trivial.
Nuclear power plants, chemical factories (PDF download), or hydroelectric facilities can have serious consequences or cause death when they’re not operated properly. Even if casualties aren’t likely, improperly operated industrial software can still lead to environmental catastrophes, destruction of equipment and materials, and huge financial and reputational losses.
The overwhelming importance of eliminating safety-critical mistakes leads to several key factors that are more important for industrial GUIs than for GUIs in other markets:
- Displays must be clearly readable under anticipated lighting and atmospheric conditions
- Displays must focus on the information of highest importance
- Information presented must be clearly and unambiguously interpreted
- Extraneous information should be eliminated
- Information presented must be consistent throughout the interface
While you can guess at how to properly implement these factors, many of these will require usability testing to be certain that the display’s use matches its intended function. As an example, the contrast between the display, ambient light, and average visual acuity may vary drastically between a young designer in a darkened office and an older worker in a brightly lit factory. Differing cultural or educational backgrounds can also be a big factor that can subtly insert design flaws that usability testing can uncover.
A current consumer GUI best practice is to hide lesser-used features and allow the user to “explore” the interface. Exploration in mobile or web apps is possible since nearly any action can be undone, and no accidental event is permanent.
Industrial GUIs don’t have this freedom. If you open a sewage plant’s effluent gates into the river, there’s no “undo” if you realize you’ve made a mistake. That’s why industrial designs need to promote less exploration and more deliberate action. For user-initiated events that have potentially serious consequences, there should be a confirmation, perhaps even two. This is a fine line – confirmations on a regular basis result in users who don’t bother reading them.
A clearly worded message about the consequence of the action should be included in the confirmation so the user can understand what they’re asking for and be certain that the action is needed. Another critical factor is to reserve those confirmations for serious situations, as we’ll discuss below.
Learn how Ventec Life Systems updated their ventilator GUI for Covid-19
3. Errors and alarms
Consumer software often responds to errors with a “throw up your hands” approach. That’s clear when you get smartphone or desktop PC errors that say things like “Critical error: program terminating” or get stuck in an endless loop of failures that forces you to reboot your computer just to stop them.
That’s completely unacceptable behavior for industrial applications. An error (software has detected a problematic situation) or alarm (software has determined the system is operating out of expected parameters) are things that an industrial system operator must deal with, not ignore.
That doesn’t mean bad error handling can’t happen.
The explosion and fire at the Milford Haven Texaco Refinery (PDF download of the Health and Safety Executive report here) went out of control because the system was throwing hundreds of alarms at the operators without any ability for them to filter the alarms to understand what was happening to the plant.
Here is one of the key recommendations from the investigative report after the explosion:
The use and configuration of alarms should be such that: safety critical alarms are distinguishable from other operational alarms; alarms are limited to the number that an operator can effectively monitor; and ultimate plant safety should not rely on operator response to a control system alarm." - The explosion and fires at the Texaco Refinery Milford Haven, Health and Safety Executive (PDF download)
Errors in industrial software often indicate problems in the system’s understanding of the physical world. Whether from failed sensors or unexpected external influences, these types of errors can snowball as one failed system starts generating errors within other connected systems.
Protect against these situations by having a consistent alarm/error management interface – preferably one that shows problems by severity, requisite response time, or earliest occurrence. Errors and alarms should explain the problem with as much diagnostic information as can be reliably inferred and list some possible recovery actions. This gives the user a way to troubleshoot when cascading failures occur. When it comes to alarms, the system should try to eliminate nuisance or redundant alarms whenever possible, so that the users don’t become desensitized to their presence.
The last major factor that differentiates industrial GUIs and consumer products is training. Consumer products aren’t built with the expectation that the user has any existing knowledge, while industrial systems often mandate user training. That’s a good thing, because as a system designer you can be assured that the operators will have a minimum baseline of knowledge.
Just because users will be trained doesn’t provide an excuse for designer laziness. The system should still be built with good design – simple and clear screens, commonplace design metaphors, and minimal cognitive load. If your training materials can focus on the areas that are critical to the particular problem space and areas where the program may need to work differently than “normal” desktop-like software, there will be less overall for the user to remember in times of crisis.
You can easily find hundreds of articles on best web, mobile, or desktop GUI design practices. But if you’re building an embedded GUI for an industrial product, it’s much harder to find information about what you should or shouldn’t do when designing the GUI. Since the safety-first aspect of many design principles for medical also apply to industrial, you may want to start with our blog, Usability meets safety: How to improve medical user interface design.
A great in-depth resource for Industrial GUIs is the Nuclear Regulatory Commission’s guide to building reactor HMIs (PDF link here). I know what you’re thinking – you’re probably not building a nuclear reactor HMI anytime soon. Fair enough. But this article is helpful for several reasons: it’s freely available (which many resources aren’t), it’s been updated recently, it’s comprehensive, and it’s industry generic (except in just a few areas).
We at Crank are another great resource. Our professional design services team has built GUIs for a wide assortment of safety-critical and industrial products (read our Alliance Laundry Systems case study). So, if you need some help with your industrial product – from answering specific design questions, through building a full GUI for a new product, to prototyping and usability testing – reach out. We’d be happy to help.