Mekael Wesley-Rosa

Redesigning the whole app without turning it off

Nine parts of a heating-control app, rebuilt one at a time while thousands of apartment buildings kept running.

Mekael Wesley-Rosa Runwise

This one waits for the guestbook. Leave your name and email and it opens.

Still shut after that? Email me and I’ll send it another way.

Runwise hired me as its first product designer. The app controls heat in thousands of apartment buildings. If we broke the wrong thing in January, somebody did not just see an error page. Somebody got cold.

Over six months I rebuilt nine parts of it without interrupting a single building during heating season. The first design decision was not color, type, or layout. It was deciding what could change first.

This wasn’t a two-year redesign with a big reveal. Surfaces shipped continuously, as soon as they were ready. More on that in a minute.

The rebuilt overview on a phone: a search and filter bar, a green banner reading $40,226,547 saved, then a list of buildings — the first one red and flagged boiler down at 82 degrees, the rest showing an indoor temperature and how many alerts are open.
The overview, which is the screen I rebuilt first. Every other area had to keep running through the heating season while it changed underneath them.
Screen areas rebuilt9
Downtime during heating seasonNone
Pageviews on the overview, today37%
Deals sourced by an empty state1

The product worked. That was the constraint.

The old app was inconsistent, but it was not a failure. Real buildings stayed warm because of it. Each area had simply been designed at a different time by a different person, until the app looked less like one product and more like a record of everyone who had worked on it.

A superintendent still had to run the heat on Tuesday exactly as they had on Monday. We could not disappear for six months and come back with a grand reveal. The old and new products had to coexist, route by route, through heating season.

This made the redesign a sequencing problem before it was a visual one.

I was the only designer, working with a product manager, four engineers, and our CEO. That meant I owned the system, but not every good idea inside it. A formal design system came about a year later and was built by the broader team. This project was the earlier, messier work of finding the patterns that system would eventually need.

Why the building overview had to be rebuilt first Nine screen areas were rebuilt over six months. The building overview went first because every screen below it inherits its structure, so getting it wrong would have meant redoing the other eight. The water tab, a screen that is empty for most customers, later sourced a closed deal. Building overview the shared foundation Heating Water List Graphs Targets Alerts Push Settings Store Every one of these inherits the overview’s structure. Get it wrong and you draw all eight twice. Build the shared structure once. Then replace each screen without interrupting the product. The overview still carries 37% of every product pageview.
Every other screen inherited the building overview’s structure. Rebuilding that shared foundation first let us replace the product one screen at a time without making the other eight twice.

Start where every task starts

Almost every job began on the building overview. A manager opened it to investigate an alert, find a building, change a schedule, or begin using the app for the first time.

Whatever that page taught them, they carried into every screen after it. The other eight areas would inherit its structure. Get the overview wrong and I would redesign the rest twice.

The old page showed the same information twice. It ranked the buildings that needed attention, then repeated them in a second list. One building could appear in both with two different reasons to click it. People had to decide which list to trust.

That sounds like a small interface problem. It took longer to resolve than designing the next four areas combined.

We ended with one list. Every building appeared once, its state sat beside it, and the next action was obvious. That became the grammar for the rest of the app: show one state, then the action that changes it.

Nine screens were replaced while the product stayed live A six-month migration with two lanes. Nine old screen tiles sit above nine replacement tiles, connected from the first old screen to the final new one. A continuous line through the middle shows that customers could keep operating their buildings throughout the migration. Migration Old product New product Month 1 Month 6 Customers kept running their buildings Overview first All nine replaced This was a migration, not a relaunch.
The old and new product had to coexist for six months. We replaced nine areas one at a time while building managers continued operating live heating systems.
The old overview showed the same building twice; the redesign gave it one trusted place A simplified before-and-after interface. The old overview contains a ranked attention list and a second all-buildings list with Building A appearing in both. The redesigned overview contains one list where each building appears once with its status and next action. Before Needs attention Building A Alert All buildings Building A Cold twice Which list should I trust? After Buildings Building A Cold · View alert Building B Comfortable One building. One place. One next action.
The old overview repeated buildings in two competing lists. The redesign gave each building one place to appear, with its status and next action together.
Three phone screens from the heating area. The first shows a building at 64 degrees with heat on, a Cool down and a Heat up button, and the day, mild weather and night targets listed below. The second is the day target editor, set to 76 degrees and warning that this is extremely above average. The third is a Heat up actions sheet offering a two-hour boost or a one-degree increase to the day, mild or night target.
A building’s heating area, which inherited the overview’s structure: one state, then the action that changes it. Setting a target directly says when the number is far outside what other buildings run, and the Heat up sheet turns “it’s cold” into a specific change a manager can apply.
The overview carries a little over three times an even share. Read the other way, the eight remaining areas divide 63% between them, so the average area outside the overview carries under 8% — and the screen that was rebuilt first is doing about five times the work of a typical one.

The empty page that produced a sale

Most customers used Runwise for heating but not water monitoring. When they opened the water tab, they found a screen built for somebody else’s account. There was nothing to show.

The normal answer is a gray icon and “No data available.” It is honest, quick, and completely useless. It closes the conversation at the exact moment a customer has told you what they are curious about.

After nine rounds with engineering, the empty state explained what water monitoring would do for that building and gave the customer one clear way to ask about it. Three weeks after launch our head of product traced a closed deal back to a customer clicking that page.

We did not target anyone or send a campaign. The customer went looking for something they did not have. The page was ready when they arrived.

The ladder is about who the page is for. On rung one and rung two it is for the customers who have the service, and the ones who do not are handled. On rung three it is for the customers who do not have it, and the ones who do never see it — which is the move, and the reason a deal came out of it.

Put the work where everyone could argue with it

I had no design team to review the work. So I posted it in the company product channel, where the people who built, sold, installed, and supported the product could pull it apart.

  • Lee, our CEO, argued with me about how charts behave when you touch them.
  • Two engineers talked me out of my chart-hiding logic, and were right.
  • Field staff told me what installers would hit before one hit it.

None of them reviewed like a designer, which was the point. They caught problems a design-only critique would have missed. I still work this way now that the company has formal design reviews.

Before each release we also taught the new behavior internally. If the support team cannot explain a redesign, it is not ready for the customer who calls them.

The part I got wrong

All nine shipped over six months with no interruption to any building. That was the hard requirement, and we met it.

I cannot tell you that the new screens made every task faster or easier. The product did not measure how people used each area before the redesign, and I did not add that measurement as I went. Shipping felt more urgent. I chose it every time.

That left us with no baseline. I can show that the overview now carries 37% of product pageviews, but not whether rebuilding it first made people better at their jobs. I might have been right. I might have been wrong and never known.

I now put measurement into the plan before the first design review, while there is still an old product left to measure.

What I can prove is narrower and still worth saying: nine areas changed while thousands of buildings stayed live through winter, with no interruption to their heat.

Nothing was lost during the migration. Measurement is where the record goes to zero.

The bigger picture

What I want you to take from this is the pace. This wasn’t a two-year redesign with a big reveal. Surfaces shipped continuously, as soon as they were ready. We weren’t just making the app look like one product. We were changing the speed at which Runwise could ship without turning the heat off.

I now put measurement into the plan before the first design review, while there is still an old product left to measure. Shipping all nine areas without interrupting the heat was the achievement. Leaving no baseline behind was the hole in it.

Screen areas rebuilt9
Downtime during heating seasonNone
Deals sourced by an empty state1
Share of all pageviews on the overview, today37%
Before-and-after data on any of itNone
The achievement and the hole, on the same scale.