Elipse Knowledgebase

Methodology for Developing HMIs with High Visual Performance.


In the past years, we have been witnessing a great revolution in interface design in general. Not so long ago, our interaction with the computer was based almost solely in command line interfaces, and yet nowadays even children operating a tablet are able to operate the device by themselves and browse the internet. This only shows how modern interfaces have become even more intuitive and easy to learn and use.

This leap in quality is the byproduct of several researches and studies performed in many different fields of knowledge. The results can be seen in our daily lives: with a smartphone, you can make a bank transaction in a few seconds, or compare a product's price in different websites at the same time. This usually happens intuitively, with no need for specific transactions on how to do so.

However, when we compare this scenario to the one practiced in industries, where any failure in the process could potentially endanger lives, the environment, and/or properties, it's very clear that this situation is far from ideal.

Usually, industrial interfaces are developed by technicians and engineers working in the industry, and not by design professionals. Consequently, it's common for these technicians to have no knowledge of design, psychology, and cognitive science studies to guide them when developing modern interfaces. Furthermore, industrial interfaces are usually developed under certain time and budget constraints, which may make them less efficient and user-oriented.

The methodology presented in this article comes to bridge this gap. It combines state-of-the-art interface design with aviation industry experience, the latter being universally regarded as a reference in the security area.

For example, the following screen has been developed with High Visual Performance for HMIs. Colors are generally muted, with only a few objects displaying bold colors. Objects' design is minimalist, reduced to its essential. There are also combined objects, such as Chart + Bargraph and Bargraph + Linegraph, with high-quality information with low cognitive processing cost. 

Results using this methodology go far beyond aesthetics. The interface, now even more efficient, starts help preventing failures and reducing operative costs. It can be used more comfortably, which in turn causes the user to learn and memorize the data better. It allows visualizing the effective information instead of just raw data. And these are only a few of the benefits.


Many companies resist migrating their system's current interface to a high visual performance one. Sometimes, they don't see the need for this change, or may even think that the great effort involved in it is not worth the benefits.

If that is your case, you may ponder this: tests have been carried out comparing high visual performance HMIs to traditional ones, and their results are so remarkable that they can't be ignored:

These figures show you that you can reduce costs caused by failure and even save lives by simply improving interface usability.

When you consider that this methodology can be applied gradually, or even to just a few parts of system that already exists, with no need to start everything from scratch, the cost/benefit ration becomes even more attractive.


A safe industrial interface is first and foremost a usable one. When developing this interface, your main concern must be the user; the process comes second.

For example, imagine a highway that was built without taking into account its final users: there aren't many warning signs on it, and the ones that do exist are not very efficient at night; the asphalt's quality is poor, and its draining system may cause the brakes to fail, especially in the rain; most of the road has no road-side rescuing system for emergencies. Even though many users will be able to use the road without any problems, it doesn't necessarily mean this road is safe. In this case, road usability under normal circumstances can be satisfactory, but in a critical situation the lack of concern for its users will be blatant.

The same analogy applies to interfaces: usability must be adequate both under safe and critical conditions, and this can only happen when the interface development prioritizes its users.

Standard NBR ISO 9241-11 defines Usability as the result of Effectiveness + Efficiency + User Satisfaction in a system. This same standard indicates as usability's measures:
  • Easy to learn
  • Easy to memorize
  • Low error rate
A great number of accidents happen due to human error. But when the interface is properly designed, many tragedies can be avoided. Below, there are two examples of accidents caused/worsened by interface design failures:

3.1 Accident at BP Texas Refinery

On March 23, 2005, a series of explosions took place at the BP Texas City refinery during a hydrocarbon isomerization unit's startup. Fifteen people were killed in the accident, and 180 were injured.
According to the final report, many factors have contributed to cause the tragedy, including a failure in the interface's design.

Source: U. S. Chemical Safety and Hazard Investigation Board - http://www.csb.gov/assets/1/19/CSBFinalReportBP.pdf

As it was designed, operators weren't able to detect the excess of flammable liquid in the unit during startup, because the initial screen only showed liquid as it went out, not as it came in. (There was actually an indicator of liquid coming in, but it was placed on another screen).

3.2 Accident with Indian Airlines flight 605

On February 14, 1990, Indian Airlines flight 605 was on its way from Bombay, India, to Bangalore, India. Shortly before landing, the flight crew made a number of errors in flight control unit and flight director settings that caused the Airbus A320 to slow down. When the crew noticed the fact, the situation was already irreversible, and the plane crashed. Ninety-two people were killed, and 54 were injured.

After this accident, Airbuses implemented a simple yet effective improvement in their speedometers: the yellow line that indicated speed was extended, for best visualization overall.

Both at BP Texas and Indian Airlines accidents, operators and crew were not able to properly evaluate the situation in time for avoiding accidents. In these cases, as in many others, the operators lost their Situation Awareness.


This methodology's main purpose is to enhance the operators Situation Awareness via a better interface, and thus enhance safety immediately. 

"Situation Awareness is being fully mindful of your surroundings.
  It is when the perceived situation and the actual situation are in tune."

Becoming situationally aware involves three different aspects: Perception, Comprehension, and Projection.

First, you perceive the fact. Then, you comprehend it in its context, that is, you realize whether it is normal or abnormal according to what is expected of it. Finally, you project its consequences, and ponder which course of action should be taken, and how fast.

How do you incorporate these three aspects into your interface?

Raw data will let you Perceive the value, but it won't tell you if this value is within normality ranges, because there is no context.

Comprehension can be achieved by setting up the alarms' limits, in order to establish to the user what the operation range under normal conditions is. This context can be displayed in several different objects, such as charts, radar charts, or bargraphs, as seen in the example. However, you can't project the consequences of the monitored behavior with only these limits, because they can't point the variable's trend on a time line.

Projection can be achieved in a number of ways; charts are the most intuitive option to estimate the time variable's behavior.


An industrial interface's main purpose is to allow the users to interact with the process. It includes efficiently alerting the operator when something is wrong in the plant.

To accomplish this task efficiently, only relevant information should be displayed on the interface; superfluous information should not compete with the operator's attention when an error is being signaled, for example.

To increase its efficiency, be sure to use pre-attentive design techniques. But what are these?

Our brains process and store the visual information received by the brain. Researchers have created a model to simulate this mechanism. This model contains a memory called Iconic or Sensorial. During this step, the visual information being received is processed very quickly. This is when we glance something, or even when something catches our eye.

Then, the information is transferred to our short term memory (STM), where it can either soon be discarded or stored in our Long Term Memory (LTM).

STM is limited and temporary. The information doesn't last very long in this memory.

If the operator is overloaded with unnecessary visual information, the STM gets saturated and needs to discard old information to replace it with new data. That is, not only information is lost, but the discarded data could be essential to fix an emergency. In an industrial process, this is not recommendable.

This is why we should always avoid vividly colorful screens with too many objects, which can cause the interface to be less informative, and thus diminishes its usability.

So, when there is no need for rendering the actual values of all points, it would be preferable to indicate only similar analog values, or graphically correlated ones. See the next two examples:

Another object with good visuals on correlated variables or even KPIs is a Radar graph:

In this graph, the continuous line stands for the process' current situation, at every instant, while the dotted line stands for the ideal situation. Then, you can compare how close to the ideal values each variable of the graph is at each instant.


Important data must always stand out from less important data. To do so, choose more muted colors for your screen, and creating any gradients with them. To indicate critical statuses that are relevant to the process, pick colors that will call the operator's attention.

Objects rendered in a very realistic way may present two types of problems for the user: their colors may be too bold, and they may need too many pixels that will be used purely for decorative purposes. Therefore, instead of using this figure:

You might want to use a simpler, more efficient one:

Notice that the second figure has practically no decorative pixels or color gradients. Our goal here was to use as many Data Pixels as possible, and fewer Non-Data Pixels.

Another thing to be avoided is using color gradients as background, because this context may interfere with our color perception. In the example below, we have two rectangles with the exact same color, but they are perceived otherwise because of the variation in the background color:

We must also consider the colors being used in single lines. Initially, there are two options for background color:
  • Light background
  • Dark background
A lighter background emits more light, which can cause eye fatigue during longer exposure scenarios; they are only recommended when a shorter visualization time is required. Darker backgrounds, on the other hand, are more indicated when the screen is visualized for a longer time, such as in energy distribution centers.

Objects' statuses should be rendered as follows:
  • Object lighter than background: On
  • Object darker than the background: Off
  • Object the same color as the background: Another pre-set status
In order to keep this visual convention consistent, don't use black or white: a black background will keep you from rendering darker objects, and a white background will keep you from using lighter ones. Instead, use intermediate colors, such as dark or light gray.

Another factor you have to take into account is the number of tensions being displayed on screen:
  • Up to two tensions
  • Three tensions or more
You also might want to consider distinguishing two different tensions by their lines' width. This could be easily done, and since it wouldn't require different colors, the color scheme would be maintained, since what would tell them apart is their width, not their colors.

When using three or more tensions, however, differentiating them by their width is not as safe, because not everybody will be able to distinguish them by how narrow they are. A possible solution would be using a dotted line to render the third tension; however, a dotted line gives the impression of lack of continuity, which is the opposite of how you want to render a continuously energized line.

That is why we recommend using different colors to render three or more tensions, which is actually the common practice in several operation centers. In such cases, you won't be able to use color schemes due to the amount of tensions required on the screen. Therefore, we recommend anchoring the colors of objects and background, so that all colors will be perceived correctly by the operator.


Variables' values can be rendered either analogically or digitally:

Render them digitally when the exact value is more important than its context:

Conversely, render them analogically when context is more important than the exact value.

When rendering values analogically, use length (and not area) to express quantity; the human brain understands the first better than the latter in this context.


Alarms are usually associated to their level of severity, which can be high (1), medium (2), or low (3). In this case, we recommend using a specific indicator for each case:

Notice that these levels are distinguished not only by their color, but by their shape too; this is important due to the fact quite a few operators may have a certain degree of color blindness.

According to Genetics Home Reference, up to 8% of males and 0.5% of females with Northern European ancestry are unable to tell red from green. Other people may be affected by other color combinations, but these deficiencies are not as common.

This is why it's important to design interfaces that allow color blind people to be able to differentiate safely between operative statuses and their visual conventions. 

One way to test the interface's accessibility is to use a black-and-white filter and analyze them in shades of gray.

The first two examples below rely on color changes to indicate which displays alarm condition, and therefore are not very good for being used in safer interfaces.

The last two examples rely on different shapes to convey the same information; even in shades of gray, they can be easily differentiated, which makes them a much safer choice for your interface.


Similarly to what you have done to alarms, to render devices you should also take into consideration potential colorblind operators. Therefore, we recommend using only three colors:

When using this methodology, avoid black or white backgrounds; go for shades of gray instead, and use darker and/or lighter shades for the objects.

Also, be sure not to use colors to indicate emphasis in the object's status. If the pump is on as expected, for example, you don't have to call the user's attention to it with a bold color such as red or green.

When you need to indicate more statuses, such as "leaving", "in transition", etc., the recommended course of action is creating additional indicators for them, similarly to what has been done for alarms. A simple icon next to the object, such as a gear or an arrow, can indicate a status more efficiently than many different colors would.


A visual hierarchy lets users compare the importance level elements hold against each other (more, less, or as important), indicating possible relations between them.

There are several ways you can create a visual hierarchy in an interface. One of the simplest is via objects' size:

Objects with the same size appear to hold the same hierarchical position; larger objects seem more important than smaller ones.


The human brain tends to consider any set of objects surrounded by the same shape or background as having characteristics in common.

Use this resource to convey the idea that they are a group:


Objects in motion are surely eye-catching, so movement is usually used as an entertainment resource. Animating conveyor belts, rotor blades, and liquid flows, among others, will only distract users from something more important.

Instead of using animation to indicate the process' status (such as "rotating turbine"), you should indicate this status with a static icon. Otherwise, your interface will look more like an entertainment center and less like a SCADA system.

One case where animation can be useful is making unacknowledged alarms blink, though. Use this resource sparingly.


To present data more clearly, prefer flat picture planes to tridimensional ones.  In the following example, even though 3D graphics are more eye-catching, 2D graphics are clearer when indicating quantities:

When projecting a screen or object with a vanishing point (one-point perspective), you have to distort objects to create the illusion of depth in the figure. This distortion violates visibility, clarity, and visual hierarchy principles, because in this case an object in the background tends to look smaller than the one in the forefront, even when both have the same level of importance for the project.


To choose between them, you must first set up the screen's goals to be able to decide which one is indicated.

3D screens have limited spatial perception, because 3D is a deceptive effect: the image appears to be deep, but it's actually flat. In addition, an over-realistic rendering has too many colors and decorative details, which can overload the operator's cognitive system with unnecessary information.

If the 3D screen uses one-point perspective, data rendering becomes even poorer, because object will look deformed as the vanishing point moves closer or further. This impairs both visibility and readability, in addition to violating the interface's visual hierarchy.

This can be seen in the next example, with excessive colors and realistic details. Also notice the two objects being highlighted; they are the same objects, with the same size, but they appear to be different due to perspective.

On the other hand, 3D graphics are very aesthetically appealing, which is why they are indicated for demonstrative screens, where presentation is the more important. Additionally, 3D graphics are more indicated for when a broader view of the process is preferred. This is very useful when you need a thorough view of the plant or an extensive area of land (map).

Based on this, you can set up your interface as follows:
  • A set of 2D screens for operating the process.
  • A smaller set of 3D screens for presentation purposes, with elaborate visuals and no operative needs.
  • One or more 3D screens for browsing, when you need a general overview of a broader area (main architecture or map).
One way of mixing 3D figures and operative objects can be seen in the next example:

Notice that this scenario is fragmented, and each drawing stands for part of this scenario. Its colors are soft, and don't compete with the colors on other objects in the operation. Even though, all objects are integrated with each other and with the process flow. In this case, all drawings were made with axonometric projection (with no vanishing point) instead of one-point projection (with vanishing point), in order to avoid distortions and to simplify its rendering.
Although this solution is more complex, it can be a good alternative for screens that need a different rendering, without sacrificing this methodology's principles.


HighPerformance Template Download.


ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 9241: Requisitos ergonômicos para o trabalho com dispositivos de interação visual: Parte 11: Orientações sobre usabilidade. Rio de Janeiro: ABNT, 2000.

ENDSLEY, Mica R. Toward a theory of situation awareness in dynamic systems. Human Factors and Ergonomics Society. p. 32-64. Mar/1995.

ERRINGTON, Jamie; DeMaere, Tim; Wade, Eric. Supporting key console operator interactions through the control system interface. Atlanta: Human Centered Solutions; NOVA Chemicals Corporation, 2005.

FEDERAL AVIATION ADMINISTRATION. Indian Airlines Flight 605, Airbus A320-231, VT-EPN. Available at http://lessonslearned.faa.gov/ll_main.cfm?TabID=1&LLID=71&LLTypeID=0. Accessed in Oct/2014.

FEW, Stephen. Information dashboard design: the effective visual communication of data. 1. ed. Sebastopol: O'Reilly, 2006.

GENETICS HOME REFERENCE. Color vision deficiency. Available at http://ghr.nlm.nih.gov/condition/color-vision-deficiency. Accessed in Oct/2014.

HOLLIFIELD, Bill et al. The high performance HMI handbook. 1. ed. Houston: PAS, 2008.

PREECE, Jennifer et al. Design de interação: além da interação homem-computador. 1. ed. Porto Alegre: Bookman, 2005.

U.S. CHEMICAL SAFETY AND HAZARD INVESTIGATION BOARD. Investigation report: BP Texas City, Texas. Mar/2007. Available at http://www.csb.gov/bp-america-refinery-explosion. Accessed in Oct/2014.

WARE, Colin. Information visualization: perception for design. 2. ed. San Francisco: Elsevier, 2004.

Artigos Relacionados

Este artigo não possui outros artigos relacionados.


Este artigo não possui anexos.

Comentários de Usuários

Nenhum comentário de usuário. Adicionar um comentário

Comentários do artigo 'Methodology for Developing HMIs with High Visual Performance.'

Para adicionar um comentário neste artigo, preencha os campos abaixo. Os campos marcados com asterisco são obrigatórios.

* Comentário:
* Digite o código abaixo:


Detalhes do Artigo

Última Atualização
27th of July, 2017

Helcker Ferrarezi Goetz

Você gostaria de...

Imprimir esta página  Imprimir esta página

Enviar por e-mail esta página  Enviar por e-mail esta página

Adicionar um comentário  Adicionar um comentário


Avise-me  Adicionar aos favoritos

Remover Marcação Remover Marcação

Editar este Artigo

Edição Rápida

Opinião dos Usuários

Nenhum usuário votou ainda.

Como você classifica este artigo?

Obrigado pelo seu voto.