Over the course of my career, I have seen hundreds of different HMI applications. Some of them have been very good, while some of them have been painful to look at and worse to actually use. The most important purpose of an HMI application is to allow an individual to interface with the control system as effectively and efficiently as possible. When developing an application from start, I break the development process into two parts: functionality and layout.
Fulfilling specific functionality needs is really why an HMI will be developed. Ideally, the functionality required from the HMI would be clearly defined in the project functional specification or similar document. In instances where the functionality requirements are absent or poorly defined, the developer must communicate with the customer to define the scope prior to starting the HMI development process.
You might think the application’s functionality would determine if a project was considered a good HMI or a bad one, but I disagree. The functions the HMI will perform are defined by the scope and therefore should be included in a good and bad design either way. As a matter of fact, I would say that an application that provides more or less functionality than required would be a bad design. An effective HMI design provides an individual operator with the necessary functions quickly and easily.
In the world of the Internet, there are many websites that provide the same set of functions. I’m sure you have favorites that you use for weather forecasts, sports scores, stock quotes, etc. Did you ever think about why you tend to choose a certain website over another? For these simple tasks, each of the websites will provide the same data, and a lot of time it is from the same sources. The appeal of a certain website over another is probably not the functionality or data it is providing, but simply the layout or your positive user experience of the website.
In the same way, the secret to an effective HMI design is also the layout. In my experience, most project scopes include a lot of functionality requirements but very little about layout requirements. For example, let’s say a functional specification includes a requirement to set a bit in the control system using a button, but there may be no requirements about the button itself. Ultimately, both a good or bad overall design will have some sort of button that sets the value. However, what really sets the good and bad apart is the look, location, consistency, labeling, background colors, text sizes, navigation schemes, and so on.
Here are a few simple guidelines I keep in mind when developing a new HMI project:
1. Just because it looks good to you does not mean it will look good to the user. Remember, you are developing the application for someone to use every day, so it is not the time to use your favorite orange background and yellow text colors. Use color standards that contrast each other well. Review the published standards for proper color use.
2. Every object or function does not need to be on the main graphic. Too many times I have seen a project where a designer wants to fit as many objects as possible on one graphic. Those extra items can very easily inhibit an operator’s ability to see what is really important. Effective use of space is very important.
3. Navigation should be simple and effective. If the project is large, use both global and local navigation schemes. Group by process, area, device category, geographic location, or whatever makes the most sense for your application. The thing to remember is the user should not have to drill down more than two or three levels to get to any function. On the other hand, if the project is simple, keep it simple. Don’t use a different graphic for each function; instead separate a graphic into multiple areas with effective use of lines, boxes, or some other method within the graphic.
4. Keep consistency throughout the design. All of the components that create the final layout should be similar to one another. For example, all text objects should be the same font, color schemes, and size. Any header or navigation areas should be the same size and position on all graphics.
5. Finally, schedule frequent graphic reviews with an authorized representative of the customer. The customer should have the final approval over all details of the HMI project. Remember, you are developing the project for the customer, not yourself. Final presentation of the graphics is not the time you want to learn that the customer had something else in mind.
The tips here may seem like common sense to most you and hopefully you follow standard practices. Unfortunately, I have seen a blue and yellow HOME button on the lower left corner of one graphic, and a grey and purple HOME button on the upper right of the next.
Stay tuned to future discussions where we will take a more in-depth look at these tips and more.