I design what the car says back.

Two people speak at once. Who wins, and where do they see it?

Premium cabins are split into zones, two or four, each with its own voice and touch controls. When two occupants speak at the same time, the system has to have a defined behaviour or it fails unpredictably. There was no pattern to copy, so the model had to be built from first principles.

I defined the interaction priority logic: which signals establish who is speaking and from where, what the system does when that is ambiguous, and how it tells both occupants what it decided without confusing either of them.

Priority was only half of it. Where the answer appears has to follow cabin layout, not the priority rule:

• Dual zone. Feedback surfaces on the central screen, left or right according to who issued the command.
• Four zone. Rear occupants get feedback on the rear screen; the driver gets it on the driver display. Never on a screen the person who asked is not looking at.
• One production programme used an ambient light animation on the driver display as a lightweight confirmation that the command had registered, without taking the screen.

How much screen a spoken command deserves

The native assistant covers media, phone, navigation, vehicle controls and climate. Treating those the same produces either constant interruption or silent uncertainty. I set the feedback strategy per command class, driven by one variable: how much the system already knows.

• Climate. Seat heating, ventilation, steering wheel heat and similar land in the status area already on screen. The climate screen never opens. No interruption at all.
• Media, weather, navigation, calling a contact. When a command matches more than one result, a carousel pick list offers the candidates. Same disambiguation principle as the multi-user case, applied to search results instead of speakers.
• Ambient lighting. “Change the ambient lighting” shows colour options. “Change the ambient lighting to red” executes with no screen at all, because nothing was ambiguous.

Two patterns follow from the same rule. Call a contact: the matches are surfaced, the driver picks, the call is placed; the system asks rather than guessing. Send a message: the transcription is shown back for confirmation or edit, and nothing is ever sent without that step.

Three mechanisms that had to feel like one feature

On estate-body vehicles the tailgate area splits into two menus, seat memory and “trunk and flaps”. Trunk, front trunk and charge flaps each run on different signals and each fail differently. To the driver they have to read as one system.

• TrunkThe brief asked for a single button to open and close. The available signals could not reliably distinguish the two, so I specified two dedicated buttons. Clarity kept, within what the vehicle could actually detect.
• Front trunkOpens from the system, but always closes by hand. The interaction has to make that asymmetry obvious instead of implying it behaves like the trunk.
• SafetyIf the vehicle moves with the trunk open, the cluster warns and the relevant control is surfaced with the warning, so the driver closes it from there instead of hunting through a menu.
• FlapsTwo flaps, one per side, with a hard rule that only one may be open at a time. Every valid state had to be legible and consistent with how trunk and front trunk already behaved.
• Vehicle stateSeat memory exists only in early HMI, before the vehicle reaches its comfort state, then moves to another screen entirely. Trunk and flaps is early-HMI only too, and is replaced by vehicle controls once moving, with the in-motion warning still able to override.

One menu entry, two incompatible state machines

Depending on how the vehicle is fitted, “tow” means either a trailer, where the system can only run a check, or a powered tow bar that deploys and stows. The logic is not interchangeable, and the driver should never have to know which one they own.

• TrailerStart and stop during the check, with the relevant warnings raised while it runs. Deliberately minimal, because that is all the hardware supports.
• Tow barDeploy, cancel mid-deploy and return to stowed with explicit feedback, stow, cancel mid-stow and return to deployed, from where stowing can be attempted again. Every transition needed feedback naming the direction of travel.
• Unsafe statesSpecific messaging rather than a generic warning, for example telling the driver the tow bar is not secure, to check the area, and not to tow.
• CopyEvery string defined in the specification. Nothing left as placeholder for engineering to invent.