Heya! Here to help you navigate quickly :)
Sections:
707 OS
Responsibilities
Responsibilities
Automotive UX/HMI Design
HMI Research
Brand Guidelines
Design System
Usability Testing
Prototyping
Automotive UX/HMI Design
HMI Research
Brand Guidelines
Design System
Usability Testing
Prototyping
Role
Role
Solo HMI Designer
Solo HMI Designer
Year
Year
2026
2026
Time to read
10-15 Minutes
TL;DR
A model for car interfaces that cuts driver distraction by knowing when a feature belongs on a physical button versus a screen, plus a full working prototype (707 OS) built to prove it. Scored 100/100 as my Masters Thesis, with usability testing landing within 0.04 seconds of a 2005 Volvo V70's 10 second best-in-test time, versus 44.6 seconds for a modern MG Marvel R on the same tasks.
A model for car interfaces that cuts driver distraction by knowing when a feature belongs on a physical button versus a screen, plus a full working prototype (707 OS) built to prove it. Scored 100/100 as my Masters Thesis, with usability testing landing within 0.04 seconds of a 2005 Volvo V70's 10 second best-in-test time, versus 44.6 seconds for a modern MG Marvel R on the same tasks.
Challenge
Car manufacturers have been moving essential functions, like climate controls and seat heating, off physical buttons and onto touchscreens, largely to cut manufacturing costs. The result is measurable: drivers spend longer looking away from the road to complete basic tasks, which directly increases crash risk. The obvious fix seems simple: bring back the buttons.
My own comparative research proved that instinct wrong. The Genesis GV60 has more physical controls than almost any car I studied, and it still performed worst in testing, because its layout was confusing, not because it lacked buttons. A car with far fewer physical controls, the Mercedes E-Class, performed near the top of the field instead.
So the real challenge wasn't screens versus buttons, it was building a model precise enough to say which medium a given feature belongs on, and realistic enough that a manufacturer under real cost pressure would actually adopt it, rather than an idealistic list of demands no business would ship.
Car manufacturers have been moving essential functions, like climate controls and seat heating, off physical buttons and onto touchscreens, largely to cut manufacturing costs. The result is measurable: drivers spend longer looking away from the road to complete basic tasks, which directly increases crash risk. The obvious fix seems simple: bring back the buttons.
My own comparative research proved that instinct wrong. The Genesis GV60 has more physical controls than almost any car I studied, and it still performed worst in testing, because its layout was confusing, not because it lacked buttons. A car with far fewer physical controls, the Mercedes E-Class, performed near the top of the field instead.
So the real challenge wasn't screens versus buttons, it was building a model precise enough to say which medium a given feature belongs on, and realistic enough that a manufacturer under real cost pressure would actually adopt it, rather than an idealistic list of demands no business would ship.
The Research
Vi Bilägare
Carbuyer
Comparative
Testing Findings
Comparative
Testing
Findings
Comparative Testing Findings
Testing 10 production infotainment systems against real usability data surfaced what actually predicts distraction, and it wasn't what I expected going in.
Physical controls alone don't fix the problem. The Genesis GV60 has more buttons than almost any car tested, and still performed worst. The Mercedes E-Class, with far fewer physical controls, performed near the top. Button count was never the variable that mattered, layout was.
Hybrid controls outperform pure screens or pure buttons. The Skoda Superb's "smart dials," physical knobs with an embedded display, combined tactile feedback with glanceable information, and it's part of why it posted the fastest average task time in the comparison.
A steep learning curve defeats good hardware. Cars like the Renault Scenic and BMW iX had capable feature sets undermined by interfaces that were genuinely hard to relearn. If a returning driver forgets where something lives, the control scheme has already failed.
Feature placement matters more than feature count. The single biggest offender across every system tested was ADAS controls buried multiple menu layers deep, exactly the kind of feature a driver needs fast, sometimes in an emergency.
Testing 10 production infotainment systems against real usability data surfaced what actually predicts distraction, and it wasn't what I expected going in.
Physical controls alone don't fix the problem. The Genesis GV60 has more buttons than almost any car tested, and still performed worst. The Mercedes E-Class, with far fewer physical controls, performed near the top. Button count was never the variable that mattered, layout was.
Hybrid controls outperform pure screens or pure buttons. The Skoda Superb's "smart dials," physical knobs with an embedded display, combined tactile feedback with glanceable information, and it's part of why it posted the fastest average task time in the comparison.
A steep learning curve defeats good hardware. Cars like the Renault Scenic and BMW iX had capable feature sets undermined by interfaces that were genuinely hard to relearn. If a returning driver forgets where something lives, the control scheme has already failed.
Feature placement matters more than feature count. The single biggest offender across every system tested was ADAS controls buried multiple menu layers deep, exactly the kind of feature a driver needs fast, sometimes in an emergency.
Academic
Research Findings
Academic
Research
Findings
Academic Research Findings
The comparative testing showed what worked. The existing research explained why.
Drivers have limited resource pools, not one pool of attention. Wickens' Multiple Resource Theory splits driver attention into visual, manual, and cognitive resources, each with its own limited capacity. Overload the visual pool with a screen-heavy task, and both the screen task and the driving task suffer.
Touchscreens measurably increase glance time. Virginia Tech's 2024 comparison of legacy and touch-based controls found touchscreen interactions produced significantly more time looking away from the road than physical controls, especially for functions like climate control.
Novice drivers carry the highest risk. Research on smartphone use while driving found screen-based tasks consistently produce slower reaction times and more lane deviation, with the effect most pronounced in less experienced drivers.
The comparative testing showed what worked. The existing research explained why.
Drivers have limited resource pools, not one pool of attention. Wickens' Multiple Resource Theory splits driver attention into visual, manual, and cognitive resources, each with its own limited capacity. Overload the visual pool with a screen-heavy task, and both the screen task and the driving task suffer.
Touchscreens measurably increase glance time. Virginia Tech's 2024 comparison of legacy and touch-based controls found touchscreen interactions produced significantly more time looking away from the road than physical controls, especially for functions like climate control.
Novice drivers carry the highest risk. Research on smartphone use while driving found screen-based tasks consistently produce slower reaction times and more lane deviation, with the effect most pronounced in less experienced drivers.
The Model
Model Explained
Model
Explained
Every feature in a car answers two questions: how often is it used while driving, and how much should the driver be able to customize it? Plotting those two questions against each other is what the model is built on.
Tier 1: Fixed Physical Controls. High frequency, safety critical, and never remapped. Drive modes, seat controls, and volume stay as pure physical controls, while temperature and fan speed use a hybrid dial, a physical knob with an embedded display, giving tactile feedback plus a glance able readout. These stay in the same physical place every time, so drivers build muscle memory and can operate them without looking, exactly the "eyes-free" behavior the research pointed to as the strongest defense against distraction.
Tier 2: User-Mappable. Still high frequency, but driver-specific. ADAS toggles, media controls, profile switching. Every driver's habits are different, so these live as configurable shortcuts rather than fixed hardware.
Tier 3a: Persistent Screen. Lower frequency, but always one tap away. Climate settings, ambient controls, the currently active profile. These don't need a physical button, but they can't be buried either.
Tier 3b: Deep Screen. "Set it and forget it" features, like navigation entry or ADAS startup state. Low frequency enough that burying them behind a menu costs nothing, since they're normally set once, before the car is even moving.
The model also includes a menu-depth penalty. If a feature is used often but takes more than a couple of taps to reach, the model flags it and pushes it up a tier, keeping the framework self-correcting rather than a one-time judgment call.
This structure isn't just how I organized my own prototype though. Next, how the same model holds up when applied to a completely different feature set.
Every feature in a car answers two questions: how often is it used while driving, and how much should the driver be able to customize it? Plotting those two questions against each other is what the model is built on.
Tier 1: Fixed Physical Controls. High frequency, safety critical, and never remapped. Drive modes, seat controls, and volume stay as pure physical controls, while temperature and fan speed use a hybrid dial, a physical knob with an embedded display, giving tactile feedback plus a glance able readout. These stay in the same physical place every time, so drivers build muscle memory and can operate them without looking, exactly the "eyes-free" behavior the research pointed to as the strongest defense against distraction.
Tier 2: User-Mappable. Still high frequency, but driver-specific. ADAS toggles, media controls, profile switching. Every driver's habits are different, so these live as configurable shortcuts rather than fixed hardware.
Tier 3a: Persistent Screen. Lower frequency, but always one tap away. Climate settings, ambient controls, the currently active profile. These don't need a physical button, but they can't be buried either.
Tier 3b: Deep Screen. "Set it and forget it" features, like navigation entry or ADAS startup state. Low frequency enough that burying them behind a menu costs nothing, since they're normally set once, before the car is even moving.
The model also includes a menu-depth penalty. If a feature is used often but takes more than a couple of taps to reach, the model flags it and pushes it up a tier, keeping the framework self-correcting rather than a one-time judgment call.
This structure isn't just how I organized my own prototype though. Next, how the same model holds up when applied to a completely different feature set.
Built to be
re-usable
Built to be re-usable
The tier structure isn't just a description of the 707 OS prototype. It's a decision framework any manufacturer can apply to their own feature list.
For any feature, the process comes down to two questions: how often is it used while driving, and should it be fixed or configurable? Answering both places the feature on the same two axes the model is built on, giving it a tier without guesswork.
A third check catches anything the first two questions miss. If a feature is used often but takes more than a couple of taps to reach, it gets flagged and pushed up a tier, regardless of where it first landed. That's what stops the model from just describing my own prototype and turns it into something a manufacturer's design team could run their existing IVI through and get honest, specific answers about what to fix.
The tier structure isn't just a description of the 707 OS prototype. It's a decision framework any manufacturer can apply to their own feature list.
For any feature, the process comes down to two questions: how often is it used while driving, and should it be fixed or configurable? Answering both places the feature on the same two axes the model is built on, giving it a tier without guesswork.
A third check catches anything the first two questions miss. If a feature is used often but takes more than a couple of taps to reach, it gets flagged and pushed up a tier, regardless of where it first landed. That's what stops the model from just describing my own prototype and turns it into something a manufacturer's design team could run their existing IVI through and get honest, specific answers about what to fix.
The Prototype
Brand Guidlines & Design System
Brand Guidlines
& Design System
Testing & Results
Findings
To validate the model, I ran usability testing on a driving simulator rig, Logitech RS50 hardware running Assetto Corsa, with the 707 OS prototype mounted on an iPad beside the wheel. Five participants, aged 20 to 40, got three minutes to familiarize themselves with the interface before driving through simulated highway traffic.
Each participant completed five tasks while driving: turning on Lane Keep Assist, switching on interior lights, accessing axle lift, switching driver profiles, and shutting off the ambient smell setting. The tasks were chosen deliberately to mix easy-to-reach shortcuts with features buried deeper in the system, rather than picking tasks that would flatter the prototype.
The average completion time across all five participants was 10.04 seconds.
For context, that's 0.04 seconds off the 2005 Volvo V70's 10-second time, the best-performing car in the Vi Bilägare benchmark study and one built entirely on physical controls. Against a modern comparison like the Tesla Model 3 at 23.5 seconds, the 707 OS prototype was over 13 seconds faster, despite being a hybrid interface rather than a pure button layout.
To validate the model, I ran usability testing on a driving simulator rig, Logitech RS50 hardware running Assetto Corsa, with the 707 OS prototype mounted on an iPad beside the wheel. Five participants, aged 20 to 40, got three minutes to familiarize themselves with the interface before driving through simulated highway traffic.
Each participant completed five tasks while driving: turning on Lane Keep Assist, switching on interior lights, accessing axle lift, switching driver profiles, and shutting off the ambient smell setting. The tasks were chosen deliberately to mix easy-to-reach shortcuts with features buried deeper in the system, rather than picking tasks that would flatter the prototype.
The average completion time across all five participants was 10.04 seconds.
For context, that's 0.04 seconds off the 2005 Volvo V70's 10-second time, the best-performing car in the Vi Bilägare benchmark study and one built entirely on physical controls. Against a modern comparison like the Tesla Model 3 at 23.5 seconds, the 707 OS prototype was over 13 seconds faster, despite being a hybrid interface rather than a pure button layout.
What I'd do next
Conclusion &
parting thoughts
Conclusion &
parting
thoughts
Figma can only take a hardware concept so far. The physical controls in 707 OS exist as renders, not functioning inputs, and the usability test happened on a simulator rig rather than in a real vehicle, for obvious safety and legal reasons.
The natural next step is testing the model in a real vehicle under controlled conditions. I'd also want to run it against an existing manufacturer's IVI, ideally one known to be distracting, to see whether the framework actually improves a system I didn't design, not just my own prototype. Longer term, extending the model to cover features intentionally left out of scope, like the gauge cluster, would round it out further.
None of that changes the core result. A model built on two simple questions, backed by real comparative testing, got a hybrid interface within 0.04 seconds of the best physical-control car in the benchmark study. The point was never to remove screens. It was proving that the right feature, on the right medium, still matters more than which medium wins. This was a very fun project for me and I have a 64 page thesis with much more info, so if you'd like to learn more please reach out!
Figma can only take a hardware concept so far. The physical controls in 707 OS exist as renders, not functioning inputs, and the usability test happened on a simulator rig rather than in a real vehicle, for obvious safety and legal reasons.
The natural next step is testing the model in a real vehicle under controlled conditions. I'd also want to run it against an existing manufacturer's IVI, ideally one known to be distracting, to see whether the framework actually improves a system I didn't design, not just my own prototype. Longer term, extending the model to cover features intentionally left out of scope, like the gauge cluster, would round it out further.
None of that changes the core result. A model built on two simple questions, backed by real comparative testing, got a hybrid interface within 0.04 seconds of the best physical-control car in the benchmark study. The point was never to remove screens. It was proving that the right feature, on the right medium, still matters more than which medium wins. This was a very fun project for me and I have a 64 page thesis with much more info, so if you'd like to learn more please reach out!
More Projects
Let's Connect
![](data:image/svg+xml,<svg display="block" id="1696064197" role="presentation" viewBox="0 0 868 40" xmlns="http://www.w3.org/2000/svg"><path d="M 0 0 C 727.016 0 868 0 868 0" fill="transparent" height="1px" id="UrUoU2Nbj" stroke-dasharray="0" stroke-linecap="butt" stroke-linejoin="miter" stroke-miterlimit="4" stroke-width="1" stroke="rgb(255, 255, 255)" transform="translate(2.5 20)" width="868px"/></svg>)
Made with love by Soham Lodha
Made with love by Soham Lodha