Case Study: Technical User
ROV telemetry // 8-hour audit
It looked like an ROV cockpit. It couldn't be flown. Four failures, each one costing a pilot time in a darkened cabin or costing the vehicle. I spent eight hours rebuilding it.
DesignedHero composition, telemetry interface, and environment, built in Figma.
01Four Ways It Would Fail
I ran the generated screen against the conditions it would actually be used in: a darkened cabin, a moving deck, gloved hands. It broke in four places.
- 01 Scale Absence No 1:1 spatial reference anywhere on screen. Pilots judge distance visually, and there was nothing to judge against.
- 02 Buried Telemetry Tether and battery sat two menus deep. Those are the numbers you check before you lose the vehicle, not after.
- 03 Visual Glare High-luminance panels washed out the sonar feed and cost the pilot the night vision the cabin is darkened to protect.
- 04 Target Size Interactive elements under 60px, on a deck that moves. Missing a control mid-maneuver is the failure mode.
All four are mission risks, so none of them were negotiable in the rebuild.
Designed Comparison layout, callouts, and the redesigned interface. Built in Figma.
AI The before screen. Raw Stitch output, unedited.
02What I Changed
- Closes fault 01 Functional Grid The background grid runs 1 unit to 1 meter, so depth and distance read off the screen without opening a measurement tool. During precision welding that is one less thing to hold in your head.
- Closes fault 02 Active HUD Tether health and battery draw sit at the top of every screen. The pilot sees an entanglement risk or a power problem without leaving the task that caused it.
- Closes fault 03 Low-Glare Surface Panels sit on deep navy with accents carrying the signal instead of bright fills. The sonar feed stays readable and the pilot keeps the night vision the darkened cabin exists to protect.
- Closes fault 04 Modular Dock Vision, Flight, and Tools moved to a bottom dock at 60px+ per target. Sized for a gloved thumb on a deck that moves, and reachable at hour eleven of a twelve-hour shift.
03Why It Reads in the Dark
Type and color are load-bearing on this interface. Both were set against one condition: a pilot reading a screen in a darkened cabin, glancing away to a video feed, and coming back to it cold.
Category
Specification
Functional Logic
Typeface
Roboto Mono
Every character takes the same width, so a depth reading holds its position as the digits change instead of jittering. The glyphs also keep 0 and O apart in low light, which matters when the number is the whole message.
Titles
Bold, all caps
Category names stay findable when the pilot looks back at the panel after time on the video feed.
Data
Regular, sentence case
Values carry the reading load, so they get the most legible setting rather than the loudest one.
Tags
Wide letter-spacing
Secondary metrics read as separate values instead of one dense string, which holds up across a twelve-hour shift.
Color
Error
Critical failure and snag detection, nothing else. Spending it once is what keeps it meaning something when it appears.
Active
Verified flight path and autopilot state. Green means the ROV is flying clean, so the pilot can confirm it without reading a word.
Accent
Latency and secondary telemetry. Calm enough to sit on screen continuously, distinct enough to find without hunting for it.
Primary
Mechanical strain and power draw. Warm enough to pull attention without reading as an alarm, because most of what it reports is not one.
Background
Absorbs ambient light instead of throwing it back at the pilot. That is what keeps the cabin dark and the eyes adapted to it.
Designed Design system layout, interface, and composition. Built in Figma. The icon set is mixed: some drawn by me, some sourced and edited to fit the system.
04What I Took From It
The generated screen was competent. It had panels, readouts, a plausible layout. What it did not have was a pilot in mind, and no amount of visual polish would have surfaced that. It took asking what the job actually is before the four failures were visible at all.
That is the part I would bring to a team. Evaluating generated output against real operating conditions is a repeatable skill, not a one-time exercise, and it is going to matter more as more first drafts arrive this way.
Eight hours, self-directed, from a decorative concept to an interface I would defend to the person flying the vehicle.