Rethink Information Architecture of connected vehicles

The backoffice managed configurations for vehicle OTA updates through several interconnected elements. Think of it as a complex product catalog system where you need to match the right software with the right hardware in the right vehicle under the right conditions.

Scalability Crisis: With new vehicle architectures released every 6 months, the system became increasingly fragmented. Users faced growing lists of elements in every configuration section, making the interface overwhelming.

Configuration Complexity: Multiple independent selection steps created opportunities for incompatible combinations and configuration errors. Users had to navigate 5-6 separate configuration steps, each with validation dependencies that weren't immediately clear.

Hidden Dependencies: Some elements were technically subordinate to others due to shared enabling technologies, but this hierarchy wasn't reflected in the interface structure.

Action: Embedded Domains (Production, Preproduction, Integration) within Vehicle Architectures.

Rationale: Development environments were created in sync with new architectures every 6 months—it made sense to manage them together.

Impact: Further simplified the user flow and ensured environment-architecture consistency.

The Key Insight: Different device types had vastly different technical capabilities but shared the same generic configuration interface. Imagine trying to configure a smartphone screen, a battery management system, and a parking sensor using the same form—most fields would be irrelevant for each device.

Action: Created "Device Family" as a super-cluster grouping Device Models by their enabling technologies and capabilities. Devices with similar technical characteristics were grouped together.

Interface Impact: The UI now dynamically showed or hid entire configuration sections based on the selected Device Family's capabilities. When configuring an infotainment system, you'd only see display and audio settings. When configuring a radar sensor, you'd only see sensor-specific parameters.

Results:

• Simplified UI with contextual configurations
• Eliminated pain points from irrelevant fields
• Reduced configuration time
• Zero configuration errors from incompatible settings

This final step transformed the entire system philosophy from a rigid hierarchy to a flexible, composable system—think of moving from a fixed menu to a modular LEGO approach.

Two Major Shifts:

1. Extracted OTA Components: Previously, software components were locked inside Device Model configurations (like apps permanently bundled with a phone model). We made them independent entities that could be associated with multiple Device Models (like apps you can install on different phone models). Benefits:

   • Reusability: One software component can work on multiple compatible devices
   • Parallel work: Different team members can configure software and hardware simultaneously
   • Easier updates: Change one component without touching entire device configurations
   • Example: A Bluetooth firmware update component can now be associated with all devices that have Bluetooth, rather than being reconfigured for each device individually

2. Inverted the Vehicle Model Paradigm:

   • Before (Bottom-up): Each device declared "I work on these vehicle models"
   • After (Top-down): Each vehicle model declares "I'm composed of these devices"

   This shift aligned with how vehicles are actually designed—you start with the vehicle concept and define what components it needs, not the other way around. It's like creating a recipe (vehicle) that lists required ingredients (devices) rather than having each ingredient list what recipes it could be in.

Key Principles:

• Separation of Concerns: Each entity has a single, clear responsibility
• Loose Coupling: Independent components connected through configurable associations
• Composability: Complex configurations built from simple, reusable building blocks
• Parallel Workflows: Multiple users can configure different elements simultaneously

Before the refactoring:

• 5-6 independent configuration steps with hidden dependencies between them
• No validation layer — operators could create incompatible combinations without any warning
• Every new vehicle architecture added complexity to every configuration screen
• Configuration errors were discovered only during deployment, causing costly rollbacks
• Interface became increasingly overwhelming as the platform scaled

After the refactoring:

• Configuration steps reduced to 2-3, with contextual interfaces adapting to each device family
• Design guardrails introduced at every step, making incompatible configurations impossible — reducing configuration errors to zero
• New vehicle architectures can be onboarded without degrading the existing interface
• Teams can work in parallel on different configuration components
• The system scales with the platform instead of against it

The most significant outcome wasn't just the reduction in steps or the cleaner interface — it was the endless scalability and the introduction of design guardrails that eliminated the possibility of configuration errors entirely. In a system where a wrong configuration could affect thousands of vehicles, making mistakes structurally impossible was more valuable than making them easy to fix.

Expand

Expand