// case-study.gated · access-restricted
This case study contains confidential project details. A password is required to continue. Reach out if you need access.
Designing the cockpit interface for a new class of vehicle, and what a test pilot taught about the difference between fluency and novelty.
transportation · cockpit-design · hmi · 2024
A startup came to us with a vehicle that didn't fully exist yet. The sea-glider, a ground-effect craft that skims above the water using aerodynamic lift, had been proven at quarter-scale: sea-foam, sensors, radio signal. No passengers. No onboard interface. No cockpit. Our job was to design one from scratch, for a vessel that was simultaneously a boat and a flying machine, intended to be operated by mariners with no flight training.
The vessel would hover below FAA classification, which meant relative freedom from aviation regulation. That, combined with the speculative nature of the product, made the scope feel wide open. We were brought in to design the next-generation human-machine interface for a new class of vehicle.
It felt like science fiction. The kind of project Territory Studio designs for Blade Runner and Dune — except made real, made tactile, made to work.
The client's target operator wasn't a pilot. It was a mariner: someone accustomed to boat controls. Simple affordances. One wheel, one throttle. Push forward, go forward.
But the sea-glider wasn't a boat. It was also a flying machine.
The interface had to carry a lot: maritime navigation, electric propulsion diagnostics across twelve motors, battery health and load balancing, weather adaptation, obstacle detection, forward camera feed, route planning. Possibly a heads-up overlay on the windshield.
The operational scope was aviation-grade. The user mental model was maritime. That gap was the entire design problem.
We were well into concept development when a test pilot joined the project. Ex-Air Force. F-16s in service. 747s commercially. Tens of thousands of hours of flight time, military and civilian. We called him Bob Dylan. (His actual call sign was a folksinger's name. He'd probably appreciate the discretion.)
He liked our concepts. He really did.
Every single one of them was wrong.
Not because they were visually messy or unpolished. Because they didn't match the logic his body had spent decades building. Pilots don't read interfaces the way civilians do. They scan. They feel for what's off. They process system feedback faster than conscious thought because they've trained that processing into muscle memory, into peripheral vision, into reflex.
"That's not where I expect it to be" was, in various forms, his most common note.
We'd power up the projection environment, run the prototype screens in the sim room, and Dylan would look out at the fake water and tell us what he couldn't see — not because it was absent from the UI, but because it was absent from where his body expected it to be.
The shift happened slowly. It happened because we were willing to be wrong.
I spent time in Microsoft Flight Simulator — not for the flying, for the research. I needed to understand how different aircraft surfaces displayed the same categories of information. How altimeters behaved. Where attitude indicators lived. How situational awareness occupied the margins of a panel, somewhere between focus and periphery, but not quite either.
Every cockpit had a language. I needed to become fluent enough to design in dialect.
We weren't building a new interface anymore. We were translating.
The design goal became: fluency first, novelty only where it earns it. Every departure from established convention had to answer for itself. What does this new interaction give the operator that the conventional one didn't? How long does it take to trust? What's the cost of retraining the reflex if it fails?
That's a different design conversation than "what looks cool" or even "what's clearest." It's asking the interface to justify its departures against the weight of embodied habit.
The final interface wasn't the cinematic HUD we imagined at the start. No Blade Runner aesthetic. No Territory Studio polish.
It was tight. Familiar. Trusted.
The speculative layer was largely gone. What remained was a recalibrated vocabulary: conventional instruments re-contextualized for this specific vessel. Semantic color definitions maintained from aviation standards — teal for set values, magenta for actuals. Altimeters, vertical speed tapes, system health readouts, re-ordered and adapted but not reinvented.
A few novel, vessel-specific features made it in. Details I can't share without the NDA conversation. But they made it in because they'd earned it — because they'd answered the justification question.
The interface looked like something that had always existed. That was the goal.
The pivot is the obvious story here, and it is a good one. But what I'm most proud of is subtler: the willingness to let the dream brief go.
Early in the project, we were designing something genuinely exciting. Speculative. Novel. The kind of interface that gets you out of bed. Walking away from that — not because the client asked us to, but because we understood the stakes and the user better than our own enthusiasm — required a kind of design maturity that doesn't show up in a portfolio image.
What remained was a recalibrated vocabulary, not a reinvented one. And I've come to believe that's often the harder, more honest outcome. It requires you to understand the existing system well enough to know what's worth keeping, and to defend that position in a room full of people who want to ship something new.
The question this project left me with — where and when is it worth asking someone to learn? — is one I've carried into every mission-critical engagement since.
Specific interface details and client name available under NDA.
>_ discuss this project →