Designing building health at Runwise

Between June and September I worked on a new way for Runwise customers to understand the health of a building. I want to share what that actually looked like, because the interesting part was not the component we ended up with. It was how long it took us to stop asking the wrong object to do the job.

The existing page could tell them when something was wrong. It had no way to confirm that everything was being watched and working as expected. On a quiet day it showed nothing at all. Silence could mean the building was fine, or that nobody was looking.

My first solution was a row of three cards for building alerts, network alerts, and action items. The categories made sense. The layout made every update feel equally important. As Shawn Hoffman put it, a boiler going down should scream while everything else stays quiet, like a smoke alarm.

That distinction is what the next thirty-six versions were actually about. More on that in a minute. First, the problem we were walking into.

The missing all-clear

Runwise monitors heating systems across entire buildings. When something breaks, it sends an alert. That system had worked for years, but it had also become noisy. Customers could be notified when a few apartment sensors dropped off the mesh, and support was fielding calls from people who wanted to turn the alerts off entirely.

The team spent the spring improving the foundation. Alerts became stateful and building-level, with criteria customers could edit. Notifications became a message log, and minor sensor outages stopped reaching customers altogether.

There was still a quieter problem. On a normal day, the building page showed nothing at all. A customer had no way to know whether that meant everything was working or nothing was being monitored.

The current building page has no way to communicate “your building is doing well.”

Max McCafferty, product review

Max said this during our August 4 review, and it became the clearest statement of the problem. A zero needed to mean more than an empty list. It needed to prove that the system was actively watching.

Finding the right names

The first version was simple: a large number, a category name, and a short description of what belonged inside it. I put three of those cards in a row.

The next five versions were mostly about language. We tried eleven labels—including Alerts, Building system alerts, Heating system, Runwise Network, Settings, and Optimizations—for three categories whose underlying purpose barely changed.

The naming mattered for a subtle reason. A zero beside a named system tells you that system was checked. A zero beside a generic label like “Alerts” only tells you nothing is happening—which is also what a broken feature can look like.

Making an emergency obvious

The middle of the project revolved around one question: how should the interface behave when a boiler is down? By that point tenants may already be cold and someone may already be on the phone. Two grey words below a category name were not enough.

My first attempt was to make the entire card red.

Red worked for a boiler, but not for every category. “Connect your utility account” should never carry the same urgency as “Your building has no heat.”

I tried giving each category its own colour: red for critical alerts, purple for action items, green for normal, and grey for warnings. Once all five hues sat beside a temperature chart that already used colour, the signals became harder rather than easier to understand.

The exploration made the limitation clear. Urgency could not live at the category level because the categories were not equally urgent. Red would mean something needs attention. Green would confirm that everything is okay. The rest of the interface would stay neutral.

The turning point

On July 23, I shared the full-width cards with Lee, Shawn, and Max. They sat above the temperature card and took over the top of the page. Lee said the layout felt too heavy and made it hard to know what to triage first.

Shawn agreed, then suggested a banner-style summary that could lead with a specific problem: “Boiler down,” followed by the number of additional alerts.

Separating categories from events

For the first five weeks, I treated this as a styling problem. I kept trying to make the three categories capable of carrying an emergency through larger type, chips, colour, and background fills.

The problem was structural. A category is a container. An emergency is an event. The categories could summarize the system quietly while a specific alert carried urgency.

It’s the categories in that position that feel wrong. Not categories as a concept.

Product and design review, August 4

We kept both layers but gave them different jobs. We also moved the component out of the top of the page and into the right-hand column beside the temperatures.

The inbox analogy

On August 24, I presented two versions: an expanded design with chips in each category and a compressed design with one alert above three counts.

Lee preferred the expanded version and said the compressed one felt like a report card. Shawn preferred the compressed version, but agreed that the two parts still felt disconnected. Then he explained why with an analogy I could use.

Seeing one email when your inbox says 47 unread.

Shawn Hoffman, design review

The counts said there were seven alerts while the component showed only one. Both described the same set of information, but they looked like unrelated components stacked together. Joe suggested one small change: put the alert below the counts instead of above them.

One small move

The second frame contains the same counts, red bar, and copy. The only meaningful change is that the alert moves below the counts and the counts sit inside a grey tray. That was enough to make the two sections feel like one component.

The next frame placed two narrower, fading alert cards behind the first. The stack made it clear that the visible alert belonged to the total above it. Instead of adding explanatory copy, the layout showed the relationship.

Where it sits

None of that is visible when the component is alone on a white rectangle. On the building page it is one of three cards in a 436-wide right-hand column, next to a 664-wide temperature card that already owns the blue, the orange, and the biggest number on the screen. The component does not get to be the loudest thing here. It gets to be the only red thing.

That is the whole argument for the tray. Seven, zero, seven read as a set because they sit on grey together, and the red card reads as one of the seven because it sits directly underneath them. Put the same two pieces beside a temperature dial without the tray and they look like two more cards in a column of cards.

What we left out

We left out category-specific colours and animation on the counts. I also explored a sparkline, but a chart explains a trend while a boiler outage is about what is happening right now.

Most importantly, an all-clear state did not need an illustration and a long reassuring message. When there was nothing urgent to show, the component moved below the temperatures and stayed out of the way.

Five decisions across thirty-six versions

The work did not progress through thirty-six steadily improving frames. It moved forward when someone named a problem clearly enough to change the next drawing.

1. 1Named systemsnot generic alerts
2. 2One loud thingnot a colour per category
3. 3A dedicated alert slotnot a louder category
4. 4The right columnnot across the top
5. 5Alert under the countsnot above them

What we do not know yet

This work has not shipped yet. We do not have engagement data, changes in support volume, or evidence beyond a small set of friends-and-family sessions that the component works as intended.

The first measure I would watch is not clicks. It is whether Customer Success receives fewer questions about whether a building is okay. I would also watch false-alarm reports. An increase could mean customers are paying attention to the system and helping correct it.

Customers trust the system exactly as far as they can verify it.

Shawn Hoffman, support summary

The bigger picture

What I want you to take from this is not that we found the right layout. I spent five weeks trying to make three categories carry an emergency. The breakthrough was to stop asking them to.

Structure and placement came first. No amount of larger type could make a category behave like a specific event. We kept the categories. We changed what they were responsible for.

I would also ask “What would you change?” much earlier. The word “disconnected” appeared in three sets of review notes without giving me a useful next step. Shawn’s inbox analogy turned the same feedback into something I could draw.

We’re a few months in and the foundation is starting to take shape. The largest open question is mobile, where most usage happens. The current principle is to surface a critical alert at the top and move everything else below the fold. That is still a rule rather than a finished design.