CS-02Product designVertiv Geist rack PDUEmbedded HMI + web
Nine Screens to One
Two interfaces for one device: a touchscreen the size of a postage stamp, and the browser you reach it from.
A rack power distribution unit is the strip of outlets that feeds every server in a rack. It is unglamorous and it is load-bearing: when it has a problem, everything plugged into it has a problem.
The work was two interfaces for the same device, designed in parallel. One is a 1.5 inch touchscreen physically on the unit, for the person standing in the aisle. The other is a web interface reached from a browser or a tablet, for the person managing many units from somewhere else. Both had to carry device status, error indication, and monitored values. The same information, two radically different amounts of pixel space.
The small screen is the interesting constraint. My canvas was 128 by 128 pixels. Everything a person needs to do at the device, including setup, alarm review, and acknowledgment, had to happen inside a square about the size of a postage stamp, using nothing but a fingertip, in a cold aisle, probably in a hurry.
Asking first
We started with workshops rather than prototypes. My manager and I facilitated, and the room held customers, product team members, and technicians together rather than separately. Three teams worked in parallel on landing page design, information architecture, and the commissioning flow, so the structural questions got worked through by the people who would live with the answer.
We also sat down with three external users and went through navigation, functionality, layout, interactions, and styling, marking pain points in one color and design ideas in another. That matrix is the reason the first prototype was not a guess.
Design, test, change, test again
I prototyped both interfaces and wrote the test protocol. Then two rounds of usability testing, twelve sessions in total across internal staff and external customers, each observation coded against four outcomes: task validated, task not validated, user confused, or design decision required.
Device touchscreen, seven sessions in August 2021: 152 validated, 27 not validated, 29 confused, 36 design decisions.
Web interface, five sessions in October and November 2021: 206 validated, 32 not validated, 32 confused, 151 design decisions.
Roughly half of everything tested came back validated. The next largest category was not failure but decision: places where users had shown us something and the team now had to choose. Confusion and outright failure were the two smallest categories in both rounds.
The constraint that arrived late
Round one of the device screen assumed scroll, swipe, and tap, borrowing the interaction model from a smartwatch because the sizes are comparable. That turned out to be a guess. Nobody had the touchscreen specification yet; Product did not have it either, and we were waiting on the manufacturer. So I designed against what similar hardware had supported in the past.
When the specification came back, scroll and swipe were not reliably available. That cost a full round of designs.
Designing forward on a stated assumption, and paying the iteration cost when it did not hold, kept the project moving through a gap that was not ours to close. What I do differently now is put the assumption in writing where the work lives: this design depends on scroll being available, and if it is not, these screens change. Then the rework is expected instead of a surprise.
Making the header do the work
Round three moved status into a colored header bar tied directly to alarm state, so the condition of the device is legible before you read a single value. That round also surfaced the question that matters most on a screen this small: what information deserves size and weight, and what can be smaller. Round four added a dark variation and pushed icons and status symbols in place of words, because on 128 pixels a word costs more than a symbol.
What testing changed
Users told us the menu naming was confusing, and they were right. “Inlet” became “Input.” “Protection” became “Breakers.” The event log moved out of Settings and into Alarms, where people kept looking for it.
The harder finding was alarm acknowledgment. Users could not tell whether acknowledging an alarm cleared it. Working through it with the team surfaced that acknowledgment depends on user permissions, and there is no login at the device, so acknowledgment could not honestly live there at all. The resolution was to show that an alarm had been acknowledged elsewhere without offering the action locally. A design problem that turned out to be a permissions problem.
Nine screens to one
The web interface started by borrowing the framework of an existing product, which got us moving and inherited a setup process nine screens long. Testing was blunt about it: the configuration process was too complex, priority data was not prioritized, and alarm status was inconsistent.
Round two turned configuration into a wizard and added graphical elements for faster reading. Better, still not right. The final round collapsed nine screens into one, offering three configuration methods and letting the user pick the one that matched how they already worked, rather than marching everyone down a single path.
The dashboard changed too. Gauges became bar graphs; the gauges looked good, but they made values hard to compare against one another, which is most of what a dashboard is for. Data was re-laid to put emphasis where importance was. Alarm notification was simplified down to color, clearer wording, and a count.
The outcome
The screens were signed off as ready for engineering, with the agreement that engineering would come back to the UX team for clarification as needed.
The device interface shipped. The rack PDU monitoring device sold in this line today carries the touchscreen I designed: the same 128 by 128 canvas, the status header tied to alarm state, tap-only navigation with menu and back sitting where the thumb already is. Some details changed in implementation. The structure and the interaction model are the ones that came out of four rounds and seven test sessions.
The browser experience carried the work forward as well, following the layout and the updated design system, and extending it the way it should: everything you can reach at the device, plus the functionality that only makes sense when you have the room for it.
A rack PDU is not a product anyone photographs for a design annual. It is a strip of outlets in a cold aisle. But somewhere right now a person is standing in front of one, tapping a square the size of a postage stamp, and finding out in a glance whether they have a problem. That is the whole job.
What I did
Designed both interfaces: the on-device touchscreen across four prototype rounds and a final, and the web interface across two rounds and a final. Co-facilitated the discovery workshops with my manager, running customers, product staff and technicians through information architecture, layout and commissioning flow in one room. Wrote the usability test protocol, and coded and analyzed twelve sessions across two rounds. Worked through the alarm acknowledgment finding with the team to its permissions root. Built to the existing UX standards so the device stayed consistent with the wider product family.
Prototypes from 2021 and early 2022, shown as they were. Customer names and site identifiers removed.