From Software Defined Vehicle to Customer Defined Vehicle - UX as a strategic turning point

14.04.2026

The automotive industry is at a turning point. For decades, the strength of European manufacturers was clearly defined: outstanding engineering, precise mechanics and technological perfection. But in the age of digitalization, the benchmark for innovation is shifting. It is no longer engine performance, chassis or manufacturing quality alone that determine the success of a vehicle, but increasingly the user.
While the concept of the Software Defined Vehicle (SDV) focuses on the technological basis, the Customer Defined Vehicle (CDV) puts the focus on people - and with them their needs, expectations and usage patterns. Digital services, personalized functions and a seamless mobility experience are becoming key differentiators. We talk about this with Michael Hayer, Portfolio Manager User Experience & Intelligent Cockpit at EDAG Engineering.

Today, many people talk about the "software-defined vehicle" as a milestone in the digital transformation. However, a new stage is emerging with the term "Customer Defined Vehicle". What does this paradigm shift mean for you - and how will it change the way vehicles are developed in the future?

Michael Hayer: The change from the Software Defined Vehicle to the Customer Defined Vehicle is leading to a massive rethink: it is not the technology that defines what is built, but the user who defines what is relevant to them. With SDV, the focus was on software as a driver of innovation. The CDV approach consistently expands this to include customer benefits and the context of use. It is no longer just about what a vehicle can do, but what it creates real added value for in the customer's everyday life.
This fundamentally changes development practice: instead of technology-driven specifications, the focus is on real user needs, usage situations and emotional expectations. Methods such as design thinking, co-creation and continuous feedback via digital channels are becoming standard. Functions are no longer designed exclusively from an engineering perspective, but rather in an interdisciplinary way along the customer journey.
In short, we are no longer just developing for defined user groups, but increasingly WITH the user, across the entire life cycle. This changes processes, roles, priorities and the culture of innovation.

To what extent is the focus shifting away from technical performance parameters towards real user values?

Michael Hayer: Technical performance values such as horsepower, engine capacity, driving dynamics or even exterior design were long regarded as key arguments in development and marketing. Today, the purchasing decision is clearly shifting towards personal needs, lifestyles and values. It is no longer about the driver as such, but rather about the user with their digital expectations, their mobility behaviour and their demands for comfort, connectivity, integration and individualization.
Michael Hayer: Many customers today no longer decide on classic vehicle features alone. The range of functions, assistance systems, integration into the digital ecosystem and the possibility of personalization are becoming more important. At the same time, values such as sustainability, transparency and data sovereignty are playing an increasingly important role. For OEMs, this means that they need to better understand the expectations and beliefs of their customers.
At the same time, the social significance of the car is also changing. Today, status and recognition are less often defined by brand or ownership, but are often created in digital spaces. Competition has also become much more intense. Asian manufacturers in particular have caught up considerably and are now regarded as serious players. In difficult economic times, the price-performance ratio is also coming more into focus.

The car remains important - but its role is changing. This makes it all the more crucial for manufacturers to really understand the needs, expectations and values of their users. What organizational or cultural adjustments are needed to anchor this customer centricity in development?

Michael Hayer: Customer centricity cannot simply be prescribed in a strategy paper. It must be anchored in the organization and lived in everyday life. Clear support from the top is crucial here. If customer experience is not represented at the highest level - for example by a Chief Experience Officer (CXO) or strong product responsibility - it often remains an individual project.
Above all, cultural change means less internal perspective and more listening. Instead of working in technology silos, interdisciplinary teams from areas such as UX design, engineering, data analytics and customer research are needed. Methods such as design thinking, agile development and early user feedback should become standard - not only in software, but also in traditional engineering.
Organization is just as important. The path to the software-defined vehicle and onwards to the customer-defined vehicle is not created by new technologies alone, but by clear responsibilities and structures. Development teams need direct access to user feedback and usage data. Measuring success must also change: In addition to technical milestones, KPIs such as customer satisfaction, usage or adoption rates should be given greater consideration.
Finally, a new error culture is also needed. Customer-centric development means testing, learning and iterating - and also allowing mistakes. This is the only way to quickly gain real insights from user behavior. This is an important step, especially for strongly engineering-driven organizations, so that the customer-defined vehicle becomes more than just a buzzword.

For a vehicle to be able to adapt to the customer, it needs a flexible technical basis. Which architectural principles, such as zonal control systems, centralized computing platforms or service-oriented software, are crucial to enable the step from SDV to CDV?

Michael Hayer: To make a Customer Defined Vehicle technically possible, a new vehicle architecture is needed, away from rigid control unit landscapes and towards flexible, updatable software platforms. Three principles are crucial here:
Zonal E/E architecture: Zone controllers bundle local sensors and actuators in spatially defined areas. This reduces complexity, simplifies the wiring harness and gradually decouples functions from specific hardware.
Central high-performance computer: A central computing platform takes over large parts of the vehicle logic. This turns software into a scalable platform; functions are bundled, distributed and updateable. This enables continuous further development over the life cycle.
Service-oriented software architecture: Functions are developed as decoupled services with clear interfaces, similar to an app ecosystem. In combination with modern runtime environments, such as Adaptive AUTOSAR, and modular update concepts, functions can be flexibly exchanged, configured and upgraded via OTA.
This means that vehicles are no longer delivered fully developed, but as platforms that evolve with the user and over time.

What role do new approaches such as virtualization, containerized software or adaptive AUTOSAR structures already play for you today?

Michael Hayer: These approaches are key enablers for the transition from a rigid ECU network to a flexible, updatable vehicle platform. They transfer IT principles to the vehicle without neglecting requirements such as functional safety, real-time capability and cybersecurity.
Virtualization makes it possible to run several separate software environments in parallel on one hardware - such as safety-critical functions and infotainment. At the same time, it speeds up development, as tests are carried out on virtual systems at an early stage and integration risks are reduced.
Containerization brings modular, clearly defined software units into the vehicle. This makes it easier to develop, test, version and update functions - with faster releases and the prospect of providing features flexibly depending on the vehicle or user profile.
Adaptive AUTOSAR can be a building block for the modern, service-based world on central computers, especially where high-performance computing, dynamic communication and more complex software stacks are required. At the same time, Classic AUTOSAR remains relevant for many real-time-critical and microcontroller-related functions. In practice, this results in a coexistence model: classic ECUs where it makes sense and adaptive, service-oriented platforms where flexibility and update capability are crucial.
All in all, virtualization, container principles and modern platforms such as Adaptive AUTOSAR create the basis for developing software faster, integrating it more securely and improving it in a targeted manner over the life cycle - a prerequisite for greater adaptation to user needs and thus a core building block on the way to the Customer Defined Vehicle.

Customer-defined vehicles require user feedback and real vehicle data to be continuously fed back into development. How do you manage to establish this cycle between driver, vehicle and development team, i.e. a genuine "user closed loop system"?

Michael Hayer: A genuine user closed loop system is created when feedback from the field is not only collected, but also systematically translated into product decisions and updates. This requires a repeatable end-to-end process: from recording usage and deriving findings to implementing improvements and feeding them back into the vehicle.

In the first step, a functioning closed-loop system begins by making the real usage context visible - even if external systems such as Apple CarPlay or Android Auto limit the depth of data. OEMs must therefore clearly define which parts of the user experience they record and control themselves.
Building on this, the second step requires clear responsibilities and structured processing of feedback so that usage data actually flows into development.
Thirdly, it is crucial to be able to react quickly: Only if improvements can be implemented iteratively and incorporated into the vehicle throughout its life cycle can a genuine dialog between users and developers be created.