Interaction Design of a 3D Vehicle Model for Vehicle Function Control in Smart Cockpits

Vehicle lights, doors, windows, and trunks are increasingly controlled through central displays rather than physical buttons. Menu-based controls support classification and expansion, but can separate a digital entry from its physical component, increase navigation depth, and make state feedback less direct. A driving-simulator study found greater visual distraction for touchscreen than physical controls in its tested tasks, and a small change in control location impaired the first subsequent task[1]. In separate simulator experiments, an automotive-targeted interface and fewer visual-manual interaction steps per glance reduced visual demand and distraction potential[2]. Research on complex automotive interaction contexts likewise identifies distraction, workload, and situation awareness as core HMI issues [3]. The relationship between a component and its digital control must consequently be established in the interface. This study takes affordance theory as its basis and uses a 3D vehicle model as an interaction carrier. Direct manipulation, spatial mapping, and immediate feedback translate menu-based vehicle functions into component-oriented actions. The design addresses function mapping, interaction steps, state feedback, and accidental activation.

Affordances concern the relationship between an actor and an environment: what actions are possible for a particular actor in a particular setting[4]. In interface design, the issue is also whether users can discover those actions and recognize where and how to perform them. A recent application-design study based on affordance theory uses perceptible cues, functional hierarchy, and visual organization to make actions discoverable[5]. This study therefore considers both the organization of available vehicle-control actions and their visibility through component outlines, hotspots, and textual prompts. Vehicle control also requires a clear relationship between the entry and the component, as well as an understandable result after a command. Mapping and feedback are used here as related design principles for the spatial organization of entries and the communication of execution state; they are not treated as synonymous with affordance. The theoretical question becomes whether a user can locate an object, understand its available actions, and confirm its current state.

The Volvo EX30 and Tesla Model 3 were selected because both integrate numerous vehicle functions into a central display and have publicly available PDF test reports and operating manuals. These documents are used to trace concrete tasks after physical controls have moved into a digital interface. In its October 2025 test of the EX30 Cross Country, ADAC rated ease of operation (Bedienung) at 3.8 (Fig. 1); lower scores are better, and 3.6–4.5 falls in the ‘sufficient’ category[6]. The report describes mirror settings in a menu and entries that change dynamically. To adjust a wing mirror, the user taps the vehicle icon at the bottom of the screen and Settings, proceeds through Controls, Mirrors and Wipers, and Adjust Side Mirrors, taps Adjust, selects a mirror, and then uses the steering-wheel buttons. The EX30 manual presents this as five steps (Fig. 2)[7]. Selection and adjustment therefore occur in two different control regions. The case illustrates an indirect component–entry relationship, weak continuity between selection and execution, and inconsistent access to important functions. For the Model 3, the ADAC PDF score sheet reports ease of operation (Bedienung) at 3.7 (Fig. 3)[8]. The report also notes the distraction potential of central touchscreen controls. The Model 3 owner’s manual describes mirror adjustment through Controls > Mirrors on the touchscreen, followed by selection and adjustment with the left steering-wheel scroll button (Fig. 4). Although the mirrors occupy clear physical positions, the user first searches a text menu and then moves between screen and wheel. The glovebox opens through Controls > Glovebox, while closing requires a manual upward push (Fig. 5); opening and closing the same component thus use different input methods[9]. At the same time, the vehicle visualization shows openable vehicle regions and their states, demonstrating the potential of object-based state feedback. Across both cases, components with identifiable physical positions may still require searching by function name or menu category. Some tasks also separate on-screen selection from execution in another control region. Users must connect the object, control, and intended action. The correspondence between the control entry and component, together with continuity between selection and execution, therefore becomes the focus of the design.

The cases point to a need for visible, stable vehicle-control entries and a clear relationship between entry selection and action. An experimental study of in-vehicle touch keys found that button size and placement were related to workload and usability; it recommends 9–15 mm touch keys and locating common controls toward the left or enlarging their effective touch areas[10]. Earlier automotive-interaction research also frames the organization of controls around user context[11]. A cockpit interface should limit unnecessary search and cognitive switching during driving tasks while making frequent functions discoverable, paths legible, and meanings explicit. Users need to identify not only a function but also its target, physical position, and present state. Doors, lights, and trunks have clear locations. This study uses action cues grounded in affordance theory, spatial correspondence through mapping, and state communication through feedback. A 3D vehicle model provides the organizing object for these entries.

A cockpit interface should be organized around actual tasks and their relationship to the vehicle. The proposed 3D model serves both as a vehicle-status display and as an entry point for vehicle controls. In the default state it presents the overall vehicle, while fixed controls for climate, seats, and commonly used applications remain at the bottom. Touching the model activates vehicle-control mode and reveals hotspots at the corresponding lights, doors, windows, and trunks (Fig. 6). Unlike a text or icon menu, this layout maps physical components directly to functional entries and is intended to reduce the translation from a function label to a real object. Functions with no single spatial location or with many parameters, such as climate settings, retain menu and card-based entries. Object-based interaction complements rather than replaces menu controls.

A control interface should distinguish the present interface mode, component state, and outcome of an action. Situational-awareness-based automotive HMI research provides a related basis for structuring and communicating vehicle-state information[12]. Experimental work on multimodal touchscreen feedback further indicates that haptic augmentation can improve secondary-task performance compared with visual-only interaction[13]. The design therefore defines a default viewing state, a touch-activated control state, and an operation-feedback state. In the default state, the vehicle and high-frequency information are emphasized without persistent control symbols. After the user touches the model, background cards recede and available components gain hotspots, outlines, or local highlights, concentrating attention on vehicle control. Selecting an icon invokes its corresponding function. A light command, for example, can be accompanied by an illuminated lamp state; a door or trunk opening can be shown by a change in component angle. Lower-risk light functions may use a single tap, while door and trunk opening require a long press to reduce accidental execution (Fig. 7).

A recent study of interaction scenarios for intelligent in-vehicle robots identifies safety and function as core scenario-design concerns[14]. A simulator study of a less visually demanding multi-touch interface reported shorter secondary-task times and lower subjective workload than a control interface, although hazard-detection probability did not differ [15]. In this vehicle-control proposal, the interface therefore establishes consistent rules for entry locations, icon meaning, input method, and state expression. Major entries do not reorder as vehicle state changes. A component retains its spatial correspondence across viewing, activation, and feedback states. Similar functions use consistent input methods, with text or symbols distinguishing a tap from a long press. Unavailable functions are dimmed or accompanied by an explanation rather than silently removed. Visual coding differentiates component controls, vehicle-parameter settings, general applications, and entertainment functions while retaining a consistent icon language. Moderate color differences and internal symbols support recognition. Function category and execution status use separate expression rules so that a color does not communicate conflicting meanings. Highlights, in-progress indicators, completed states, and exception messages remain consistent across functions and are paired with text (Fig. 8).

Menu-based control uses labels, icons, buttons, and hierarchical categories. It suits climate parameters, driver-assistance settings, and other complex tasks, but a door, window, light, or trunk may require users to translate between a function name and its physical object. A 3D model places the entry on the corresponding component and confirms state through animation, highlights, and text. The approaches suit different task types rather than forming an absolute ranking (Table I).

This study addresses the separation of control entries from vehicle components, lengthy paths, and indirect state feedback in smart cockpits. It proposes a 3D vehicle model that maps lights, doors, windows, and trunks to their corresponding regions and links object location, function activation, command execution, and feedback. Component animation, highlights, and textual prompts support state confirmation. Spatially identifiable functions with visible changes are suitable for this approach, while complex parameter configuration should remain in menus. Complementary control modes can balance directness, functional coverage, and safety. Further work should assess the design in actual driving contexts with user testing.