I once sat in a panel discussion among 25 or so representatives from different contractors who installed building automation systems (BASs). Each person took a few minutes to describe his or her current focus area, and there were a wide variety of initiatives. Topics spanned from taking a hard look at his or her estimating practices to marketing tactics to specialized energy management programming techniques. One of the younger persons in the room spoke up and waxed poetic about user interface/user experience (UI/UX). He enthusiastically described how his company had made a name for itself and was doubling down on its UI/UX focus. He used jargon that very few in the room knew of, and there were several people who poked fun at him for it. I didn’t speak up in defense of him then, but I think his focus area was a good one.

From an end user's perspective, a BAS’s “graphics” are among the most heavily differentiating aspects from one vendor’s solutions to the next. As many of you know, I’m referring to the series of graphical user interfaces that are often served up on a dedicated computer with specialized software or via a customized web interface on mobile devices or workstations. A system can work well to maintain environmental conditions for months or years on end, but if a maintenance staff member is unable to use the graphics to troubleshoot and remedy an issue, he or she will certainly feel as if they’ve been underserved. I have been party to a sales call where a prospect was lamenting the need to replace the entire BAS that was only three years old, and, after all of the questions and answers, the truth behind it was that the original contractor had not included override capabilities of zone dampers in the graphics provided. We did the right thing for that customer and showed him what he really needed to do, but imagine if you were faced with a project worth tens or hundreds of thousands of dollars when a couple of hours of work would solve the issue.

BAS end-users possess a spectrum of domain-specific knowledge. One of the most tedious aspects of configuration for graphics is selecting and arranging images that represent the equipment being controlled and aligning all of the data display elements in a way that the screen is not too cluttered. On the other hand, when asked how they like the equipment graphics, I’ve definitely heard feedback from customers who have said, “Oh, they look great, but those are for you when I call you to come fix something.” Not all of the software offerings out there support customized experiences for individual users (those that do use this as a selling point); however, even when the software does support it, this can make future reconfiguration far more expensive than if a normalized package had been provided.

Construction plans and specifications often make use of language conventions to describe what graphics should include and be configured to do. For example, consider the following sentence: “The mixed air damper shall modulate to maintain the mixed-air temperature of 52°F (adjustable).” By convention of language, this sentence implies the graphics should include a set point the end-user can adjust in addition to the temperature sensor value and damper position. A situation that is all too common is that the programmer who isn’t familiar with this language convention has not configured the graphics completely yet, and a third-party commissioning agent files a deficiency because of it. In my personal experience, this sort of issue can account for a staggeringly large portion of a commissioning agent’s deficiency list.  Again, even though the system probably operates very well under automatic control, it matters a great deal whether the end-user can observe the operation and adjust settings when required.

I’ve found that graphics are implemented best when they are not limited to the “what” but rather when they also help with “where” and “why.” As for “where,” graphics can be extremely useful for navigating spatially within a building footprint to troubleshoot how pervasive temperature issues are and what equipment is likely to be responsible. As for “why,” graphics can be configured to make it very clear the reasons equipment is being controlled a particular way. Sometimes, this is accomplished by putting copies of the control sequences directly on a page. In other cases, the graphics go beyond showing only sensors and set points to emphasize current operating modes so that an end-user can make a conclusion, for example, “This air-handling unit is turned off because it’s in freeze-protection mode.”

The young man in the panel discussion knew that empathy goes a long way in delivering value to a customer and that focusing on his customers’ experiences are worthwhile. It’s a seemingly simple and ubiquitous concept, but it’s a nuanced one that can be hard to do well. I would love to find out what you as the reader have experienced with BAS graphics and whether those experiences were memorable for the better or for the worst.