Physical buttons still need a state model

A fixed surface is only part of the interface

A button is easy to count in an interior photograph. What it does at a particular moment is harder to establish. For a cockpit team deciding which tasks deserve a dedicated control, the useful distinction is between a control you can find by touch and an action whose meaning stays predictable.

Volkswagen's ID. Polo preview and BMW's Panoramic iDrive announcement illustrate different approaches. Neither announcement establishes which system is safer in use. Both give enough detail to examine where the driver's task still depends on software state.

Volkswagen gives several tasks a fixed place

In its January 2026 cockpit preview, Volkswagen describes separate climate and hazard-light buttons below the infotainment display. It also places an audio rotary controller between the phone tray and cup holders, with volume, track and station selection available there. The steering wheel has distinct button fields. The release identifies the illustrated vehicle as a near-production concept. These are documented design choices in that preview, not a test of a customer's delivered car. [1]

The useful property here is an identifiable task location. A driver looking for a climate control need not first choose a climate page to find the described strip. That observation says nothing about the number of inputs needed for every setting, or whether all climate functions are available outside the touchscreen.

Even an audio knob requires a more precise specification than its silhouette suggests. A review should distinguish rotation, pressing and any other supported action. Which operation changes loudness, which changes content, and where does the result appear? The physical presence of the controller does not answer those questions.

September's specification makes the comparison more precise

Volkswagen's 9 September 2026 interior description names the functions in the separate climate panel: temperature, blower, air conditioning, automatic mode, recirculation and window defrosting or heating, with the hazard switch in the middle. It also documents a persistent touchscreen bottom bar for climate and seat functions. Physical access and screen access therefore coexist; this is not an all-buttons interface. [3]

The same document says the steering-wheel View button selects a retro instrument presentation. The infotainment display changes its central presentation through a swipe while retaining its top and bottom bars. This provides a second useful comparison: a display can change appearance without moving every task entry point. [3]

For a review team, that means recording the physical panel and the persistent screen entry separately, then checking whether they present consistent settings. The January photograph illustrates the earlier preview, not a verified September production configuration. Neither document reports the latency between an input and an updated display.

BMW makes availability part of the control surface

BMW's January 2025 Panoramic iDrive announcement describes a steering wheel whose available functions are highlighted through illumination, with raised surfaces and active haptic feedback. Its example is an incoming call: the panoramic display shows the call, a steering-wheel symbol lights green, and the driver can press to accept or swipe on the right side to reject. BMW also describes haptic switches for functions including wipers, indicators and window de-icers. [2]

This is a concrete interaction to compare, rather than a general claim that one manufacturer prefers buttons and another prefers screens. The call introduces a temporary action and presents that action across a display and a steering-wheel surface.

For implementation, the display and input surface need a shared view of the call state. The announcement does not document their timing or failure handling. An engineering review should therefore separate the described interaction from questions that require software evidence or a vehicle test.

Compare the task, then inspect the transition

The following distinctions are an editorial framework, not measured outcomes for either vehicle.

Consider a call that ends just before a driver presses the illuminated control. The important implementation question is which state the command applies to. Silently reinterpreting that input as a different action would make the driver's expectation unreliable. A suitable response must be specified and then checked; neither press release reports that edge case.

The same review should consider a delayed display update. Does the illuminated control still represent an available action? Does the system reject stale input, and can the driver understand the outcome? A successful demonstration of accepting a call does not resolve those cases.

These examples are proposed review scenarios, not reported faults. They show why industrial design, interaction design and software behaviour need to be reviewed together. A button surface can be well defined while its activation rules remain incomplete.

One interrupted call, three different outcomes

Suppose the call disappears while a finger is already moving toward the control. There are at least three outcomes worth distinguishing. The system may accept the command against the original call and report that it has ended. It may reject the command because that action is no longer available. Or it may apply the input to whatever function now occupies the surface. The third outcome changes the meaning of a gesture after the driver has committed to it.

A defensible implementation proposal is to associate the command with the action the interface offered, then validate that action when handling the input. This is an architectural proposal, not a description of BMW software. The details depend on the input stack: when a gesture begins, when its meaning is resolved, and whether the call service can acknowledge the same action identity.

A review can make this observable without inventing a universal timing threshold. Record the call event, displayed symbol, gesture start, command dispatch and resulting state on one timeline. Repeat with the call ending before contact, during the gesture and after dispatch. A tactile click alone should not be counted as proof that the call was accepted. That distinction gives HMI and integration teams a specific result to inspect together.

What belongs in a design decision

For each driving task, document the intended action, its entry point, the states in which it is available and the feedback that confirms its result. Compare those records before comparing total button counts. A dedicated control may simplify access; a contextual control may offer the right action without permanently occupying space. Both decisions still need evidence about discoverability and error recovery.

The product conclusion is narrower than a verdict on touchscreens: retaining a physical input does not finish the interaction specification. If the driver must interpret a changing symbol or recover from an interrupted task, that behaviour remains part of the cockpit interface and should appear in its acceptance criteria.