To respect my non-disclosure agreement, certain details in this case study have been simplified, modified, or omitted. This case study focuses on my design process, problem-solving approach, decision-making, and contributions, while ensuring that no confidential product information is disclosed.

A Feature Proposal: Bringing Fuel Intelligence to the My Renault App

No OEM app in 2025 solves the complete trip fuel problem. I identified the gap, mapped the opportunity, and designed a five-capability system that would collapse six apps into one - projected to reduce fuel costs by 12–15% per trip and triple session frequency.

Client:

Renault Group

Domain:

Connected Car / B2C Mobile

My Role:

Lead Product Designer

Platform:

My Renault App (iOS & Android)

Users:

Car Owners (India)

Problem Statement

Planning a long-distance drive in India means managing fuel across highways where station availability is unpredictable, pricing varies by 10–15% across providers, and mobile connectivity drops out in rural stretches.

Most drivers today solve this with a combination of Google Maps for routing, a separate fuel price app, and mental arithmetic about tank range switching between tools at the exact moment they need to focus on driving.

For Renault's connected car users, this was a missed opportunity hiding in plain sight. The My Renault App already had vehicle telemetry data, real-time fuel level, range estimation, trip history. It just wasn't connected to any of the decisions drivers were making in the real world.

The design question:

If we already know the car's fuel state, the driver's route, and real-time station data, why is the driver still doing this math themselves?

How I Approached It

For a concept proposal, the design challenge is different from a shipped product: there's no user testing data, no engineering constraints yet defined, no live feedback loop. The risk is designing something that looks impressive but isn't buildable, or proposing a feature set that no one would actually use.

On usability: I mapped the three key decision moments a driver faces on a long trip route selection, refuel timing, and cost estimation and designed the five capabilities to resolve each without adding cognitive load. The test was simple: can a driver answer "do I need to stop now?" in under two taps?

Research & Competitive Gap

I audited six major OEM companion apps and looking specifically at how each handled the trip + fuel planning intersection.

The pattern was consistent: every app handled one layer well and dropped the others. Hyundai BlueLink surfaces fuel level but doesn't route around it. None connected vehicle telemetry, live station data, pricing, and offline fallback into a single flow.

The competitive insight wasn't just that the gap existed it was that the gap existed in every OEM app simultaneously. This wasn't a feature oversight. It was a structural blind spot: most OEM apps are built by teams optimising for vehicle function (diagnostics, remote start), not for the active driving experience. The opportunity was to cross that line deliberately.

Key finding:

No OEM app in the Indian market connected four data layers that Renault already had access to: vehicle telemetry + real-time fuel prices + station availability + route intelligence. Building the connector was the design problem.

The Proposed Solution

The proposal is built around five interconnected capabilities not five separate features. Each one solves a distinct layer of the problem; together they make switching between apps unnecessary.

1. Fuel-Aware Route Planning

Route options are scored not just by distance or time, but by total fuel cost calculated against the vehicle's current tank level and real-time station prices along each path. A driver choosing between two routes sees the cost difference before committing, not after.

2. Contextual Refuel Recommendations

The system calculates the optimal refuel window based on current range, station availability ahead, and price trends. It doesn't alert constantly, it surfaces a recommendation at the moment the decision actually matters, not 200km before it does.

3. Real-Time Station Intelligence

Stations are shown with live availability, current pricing, and operating hours filtered to what's reachable given the vehicle's current range. A station that's technically on the route but unreachable on the current tank doesn't appear.

4. Trip Cost Estimation

Before departure, users see a full fuel cost estimate for the trip broken down by route, based on their vehicle's actual efficiency data. This is the feature that replaces the mental arithmetic most drivers do before a long drive.

5. Offline Fallback Layer

In low-connectivity zones which cover significant stretches of Indian highway the system caches the last known station data and range projection, so drivers aren't left without information at exactly the moment they need it most.

The capability that best illustrates the system thinking: it doesn't just show where the nearest fuel station is. It calculates whether driving 2km extra to an HP station saves ₹500 given the current tank level and shows that comparison before the exit, not after it.

Strategic & Business Framing

The feature proposal wasn't just a UX argument, it was a business argument. I framed the case for stakeholders around three strategic dimensions:

Competitive positioning

India is the world's third-largest auto market and one where connected car app adoption is still forming. Being the first OEM to deliver genuine trip fuel intelligence not just a diagnostic app creates a positioning advantage that's hard to replicate once the expectation is set.

Revenue enablement

Fuel brand partnerships (HP, Indian Oil, BPCL) become viable once the app has influence over where users refuel. Post-trip data anonymised trip patterns, fuel consumption by route is a real data asset with API partnership potential. Neither revenue stream requires the feature to be perfect at launch; they scale with adoption.

EV transition bridge

The same architecture route + range + infrastructure availability applies directly to EV charging. Building Trip Fuel Advisor for ICE vehicles now creates the foundation for EV range anxiety solutions when Renault expands its EV fleet in India. The investment has a longer ROI arc than a single feature.

AI-Augmented Prototyping

For an internal concept proposal, the goal of the UI work was communication, not specification. Stakeholders needed to see the idea, not review production-ready screens.

I used an AI-augmented workflow - Stitch AI for layout generation, Claude and ChatGPT for copy and interaction framing, compressing the visual communication phase from days to hours. Every generated screen went through critique and refinement against Renault's design system before it went into a review session.

The speed advantage compounded: when stakeholders requested changes, I could iterate in near-real-time rather than returning in a week with revised screens. The result was a faster decision loop, not just a faster deliverable.

Projeced Impact

These are projected outcomes based on competitive analysis, user research, and stakeholder modelling not live metrics.

Technical Feasibility

API Strategy

To ensure the solution was practical, I worked closely with AI/ML and engineering teams to understand technical constraints, validate feasibility, and shape the experience around real system capabilities.

Mapbox/Google Maps API (Core routing and navigation)
Localized Fuel Price APIs (Real-time pricing data)
Renault Vehicle Telemetry (Internal API for car-specific data)

Phased Rollout Vision & Key Learning

Phased Rollout Vision

The proposal was designed with a phased rollout in mind starting with what's immediately buildable on the existing app infrastructure, then extending into deeper vehicle integration as confidence and data maturity grow.

Key Learning:

Concept work taught me things that shipped product work doesn't.

Without a live user base or engineering constraints to react to, the quality of the thinking has to carry the proposal. There's no "we tested it and it worked" to fall back on. This forced a level of upfront rigour mapping every assumption, being explicit about what was modelled versus measured that I now bring to shipped product work too.

The insight I didn't expect: fuel decisions are more emotional than I assumed going in. Cost visibility matters, but what builds trust faster is the feeling that the app already knows your situation your tank level, your route, your last refuel. Personalisation based on vehicle data creates a qualitatively different experience than personalisation based on preferences. The car knows things the user doesn't need to tell it.

The offline constraint reshaped the entire information architecture. Designing for intermittent connectivity on Indian highways isn't an edge cas, it's the base case for a significant portion of the target user base. Once that was treated as a first-class requirement rather than a nice-to-have, the caching and fallback logic became core features, not afterthoughts.

If this proposal moves forward: the first metric I'd want to instrument is task switching how often are users leaving the app to check a fuel price or station on Google Maps. That's the baseline that proves whether the consolidation is real or just perceived.

Other Case Studies

See All Projects