Skip to content
Clark & Soma
Field Notes

Graphics That Match the Building

Operators stop opening front ends that have lied to them; a graphics pass that verifies every displayed point, makes overrides visible, and rebuilds navigation around the way operators think can win the screens back without redrawing the whole building.

Alex Clark

Watch an experienced operator handle a hot call. If the first move is a raw point list, a bookmarked address on the controller, or a phone call to the controls contractor, the front end has already failed. The graphics exist. Nobody trusts them, because somewhere along the line the screens stopped describing the building, and an operator burned by a picture twice stops looking at pictures.

Why operators go around the graphics

The bypass is learned distrust, not preference, and it usually traces to three failures. The screens were drawn from submittal drawings, so they show the building as designed rather than as built: equipment that changed during construction, zones that were resized, a unit that was value engineered away but still has a picture. Points died or were never bound, and many platforms keep painting the last value they heard, so plausible numbers sit frozen for months with nothing to flag them. And overrides are invisible: a fan commanded by hand at the controller looks identical on screen to a fan running in auto, so the graphic misleads during exactly the events that matter.

  • Screens drawn from submittals, showing equipment that changed before startup.
  • Dead or unbound points rendering stale values with no visual distinction.
  • Overrides in effect at the controller with no indication on the graphic.
  • Navigation that mirrors the installer's folder tree instead of the operator's day.

What a real graphics pass changes

A graphics pass is not a re-skin. Prettier screens that lie are worse than ugly ones, because they invite trust the data cannot repay. The work that changes operator behavior is verification and visibility. Every equipment graphic gets walked against the installed machine, so the picture matches what is actually bolted to the pad. Every displayed value gets proven live: exercise the point and watch the screen respond, and where a binding is dead, repair it or remove the element rather than leave a number that looks alive. Every point that can be overridden shows that state plainly, backed by one page listing everything in hand building-wide, so forgotten overrides have nowhere to hide. And navigation gets rebuilt around how operators think: floor plan to zone, zone to terminal unit, terminal unit to the air handler serving it, so the path from a complaint to the equipment behind it is a few clicks, not a folder hunt.

Scoping the pass without boiling the ocean

A rebuild of every screen at once is how graphics projects die in the estimate. Scope follows use, not inventory.

  • Start from the screens operators open in a normal week; that shortlist carries nearly all the value.
  • Fix one equipment type end to end, turn it into a template, and replicate: one verified air handler graphic becomes every air handler graphic.
  • Treat point verification as the deliverable, not a checkbox: a graphic is done when every element on it has been demonstrated live.
  • Leave rarely visited screens for a later phase, and mark them honestly so nobody mistakes an unverified screen for a verified one.

The finish line has a simple test: when the next complaint comes in, does the operator reach for the front end first? Graphics that match the building earn that reflex back one verified screen at a time, and everything else a modernization hopes to deliver, from tighter sequences to alarms worth believing, lands on that trust or not at all.

  • graphics
  • operator experience
  • modernization
Next step · Assess

Have a system like this to untangle?

Scope is defined before work begins.