What the Technician Knew

A UPS is the box that keeps the power on for a few minutes after the power goes off. Long enough for a server to shut itself down properly instead of dropping mid-write; long enough for someone to notice and act. The whole value of the thing is measured in minutes, which means the software watching it has one real job: tell me, right now, how many minutes I have and whether I need to do something about it.

That is what I wanted from the first screen. You sign in, and inside five seconds you know whether you have a problem, how bad it is, and what you do next.

The situation

Vertiv builds the equipment that carries a facility through a power event: uninterruptible power supplies, rack power distribution units, the hardware sitting under a server room or behind a shop counter. Power Insight is the software that watches it.

The version we were replacing had been built around Vertiv's own people. When something went wrong, a service technician either drove to the site or walked the customer through it over the phone. That worked, and it carried a cost: every question routed through a person, and the software never had to be legible to anyone outside the company.

It was also old. It sat outside the design system we were assembling, it ran on a one-off visual language, and it was failing in ways nobody had to be persuaded of. Support tickets. Service calls. The Product Manager. The technicians. When every group touching a product describes the same problem, diagnosis is not the hard part.

The prior version is publicly documented, so the starting point is a matter of record rather than memory. Getting a single alert to a phone required assembling five separate objects in sequence: contacts, then server configuration, then an action, then an action set, then an automation rule. There was no guided setup at all. You installed the software, registered an account, and were left facing an empty device list. And the dashboard was a census: how many devices are online, how many are in alarm, a pie chart that turned red in proportion. It told you how many things were wrong. It did not tell you what to do.

Human factors research commissioned before I joined the project went into the brief that won the work its sponsorship through Vertiv's new product development process. I did not run that research, and we had not reached interviews or usability testing by the time I left. What I had directly was support-call data from the legacy product, which is a decent map of where people got stuck.

The reframe

The new product put the customer in the driver's seat: sign in, see your own equipment, configure it yourself. Which meant something had to replace the technician.

Everything the technician used to supply, the interface now had to supply on its own, to someone competent but not a power specialist, who is very likely looking at the screen because something has already gone wrong. Not just the numbers. The interpretation: what this number means, whether it is bad, how urgent it is, what to do first.

I had seen the shape of this problem before. I started my career designing human-machine interfaces for control systems in oil refineries and chemical plants, where an operator has to take in a situation and act correctly under time pressure, and where a misread display carries consequences that do not stop at inconvenience. Different stakes here, same structure: situational awareness has to live in the screen, because there is no expert standing behind the person reading it.

The constraint

This was not one product. It was three editions of one product, sharing one interface.

Personal is a household or a very small office: a single UPS plugged in over USB, no network, no server to protect. Business is a real IT operation with devices on a network. Hyperconverged is a virtualized estate, with no direct-attached hardware at all, integrating with VMware, Hyper-V, Nutanix and VxRail.

Underneath those sat roughly eighteen UPS models across five different communication interfaces, split by region, many not yet tested. And the brief opened with a constraint that shaped everything: use the Vertiv UI, and use the same terminology, across the whole product family. This was not going to be a product that invented its own language.

So the design problem was not “make a dashboard.” It was: serve a person with one UPS in a closet and a team running a hyperconverged cluster, in one interface, without shipping three products and without making either user carry the other's complexity.

The three-edition split was the Product Manager's call, and it was one of the reasons the project got funded. What I designed was what happened behind each door.

The screens

The first five seconds

Three readings sit at the top of the dashboard: available capacity, battery status, battery health.

Those three were not chosen for balance or because three looks good in a row. They are the readings a service technician actually used to diagnose a unit, and they were the ones Engineering could give us accurately and wire to the alarm system. So they are the ones I put in front of the person who no longer has a technician standing next to them, whether they are going to fix it themselves or read the numbers out loud on a support call.

Battery status carries “68 minutes remaining” inside the ring. The percentage is the reading; the minutes are the decision. Alongside them sit the things that turn a reading into a judgment: temperature, voltage, battery age, replacement date. A battery at seventy-five percent means something different at 1.4 years old than it does at four.

The banner that is usually not there

Alarm state lives in the header, which is where we had settled alarming across Vertiv's applications, and it behaves in one specific way: when nothing is wrong, it is not there.

So its presence is the signal. You do not read the banner to find out whether there is a problem; if you can see it, there is one. Color tells you the severity, and the counts to the right tell you how many of each kind, so the sequence from noticing to knowing what to open takes about as long as it takes to describe.

One device, or two hundred and fifty

The single most repeated decision across these screens is what happens when you stop having one of something.

A radio-button list is a fine way to pick a device when there is one device. At two hundred and fifty it is unusable. So on the business path, list after list became a scrollable table with tick boxes, a select-all in the column header, and per-row settings; and the mass-configuration flow got a confirmation that asks the question directly.

Running the other direction, the Personal path got things taken away. IP address fields struck out, because a USB connection does not have one. The discovered-device list cut from three to one, and its label corrected from plural to singular, because a household is not going to have three of these. The five-object notification chain collapsed into a single screen: pick information, warning or critical, type an email address, confirm. And a Skip on nearly every step, so someone can get to a working state now and come back to the rest later.

That last one was a disagreement. Product's position was to leave optional steps visible but grayed out, so people could see what they were passing up and would be less likely to skip. Mine was that someone who cannot finish setup tonight should still end the evening protected. Both are defensible; the Skip buttons are in the wireframes because that is where we landed.

Telling people what happened

Discovery ends with a confirmation that says what happened and offers the step that logically follows, rather than returning the user to a list and letting them work out that they are not finished yet.

The delay field matters more than it looks. It is the difference between a server shutting down during a two-second flicker and a server shutting down when the power is genuinely gone, and the person setting it needs to know what they are trading.

How the work moved

My Product Manager was in the UK. I was in Ohio. There was not much shared working day, and design questions do not queue politely.

So I asked him whether he would be willing to work a different way, and he was. I annotated the open questions directly onto the screens, in a consistent color, at the exact point of ambiguity, and sent the deck. He answered in writing on his own clock. I marked up my decisions on top of his answers and sent it back. Where writing was not enough, one of us recorded a walkthrough for the other to annotate.

The questions clustered where you would expect: what is editable, what gets reported, and what information a person needs in order to make an informed decision. That third category is where it stopped being a status update and started being useful.

The clearest example: Product did not know how much data and functionality the platform could actually expose. Neither did I. Answering my questions meant going to Engineering to ask what was possible, and the answers came back larger than either of us assumed. Capability we had not known about opened options we had not considered, and the direction of the design changed because of it.

That is the argument for asking questions in writing, on the artifact, where they can be forwarded. A meeting would have produced “we will look into it.” This produced a list specific enough that Engineering could answer it, and specific enough that their answer changed the design.

The outcome

I left Vertiv in October 2022, partway through the project. I do not know which parts of this shipped.

Power Insight is a live Vertiv product and the work continued after me, but I was not there for it, and I am not going to claim an outcome I did not watch happen. What is here is the design as it stood: the problem, the constraint, the reasoning, and the screens.

What I did

Designed the interface: dashboard, device management, discovery, shutdown configuration, alarming, reporting, administration, and the two onboarding paths. Worked directly with the Product Manager, who drove the project and set the three-edition strategy, and with Engineering on what the platform could support. Grounded the work in support-call data and in human factors research commissioned before I joined. Introduced the annotated async review loop that the project ran on. Built to Vertiv's existing UI and terminology standards, and drew on the design system I had stood up across the organization.

Screens are prototypes from April 2022, shown as they were, working annotations included.