VEDANT SHARMA
This website is currently under construction. Some projects may have incomplete visuals as updates continue.

I’m a Senior Product Designer based in Bengaluru, working across interaction design, typography, and vehicle HMI. I design rider-facing systems for electric two-wheelers, focusing on clarity under motion, legibility at speed, and behaviour that feels intuitive in real-world riding conditions.

With a background in typeface and graphic design, I approach interface problems through hierarchy, precision, and visual decisions that scale across vehicles and product lines.

Outside of work, I spend time on solo motorcycle rides, strength training, photography, and watching films that linger emotionally.


CV

vedant@vdnt.me

Instagram

LinkedIn
INFINITE CRUISE

Role
 Lead Product Designer

Scope
State model · Engagement logic · UI · Auditory feedback

Collaborators
Product · System Intelligence · HMI Engineers


On a two-wheeler in the city, your right wrist is never still. Throttle, brake, dodge, repeat. Cruise control was built to reduce this fatigue. 

But cruise control was designed with highways in mind, long stretches of steady speed with minimal interruption. Urban riding is different, especially in India. Here, cruise felt borderline dangerous. 

Throttle input is constant. Speed fluctuates. Braking is frequent and reactive.

The challenge wasn’t implementing cruise control. It was teaching it how to survive instability.


![Traditional Cruise Logic Diagram – Side by Side]

1. Designing for Instability

Conventional Cruise Control logic is binary:
  • Engage  
  • Hold speed  
  • Cancel on any input

This model assumes predictability. But in traffic, that behaviour feels brittle. Riders don’t move at constant speeds, they modulate constantly.

Treating every brake or throttle input as cancellation made the system fragile in real-world riding conditions. Instead of terminating on speed variation, we began exploring cruise as a **stateful system**, one that could adapt to variability without compromising clarity.

The design question became:

> How should our Cruise behave when the road is unpredictable?

This reframed the problem from just feature implementation to interaction design.


My responsibility was to define how this system behaved at every micro-interruption:  
  • Brake tap
  • Partial throttle
  • Speed dip
  • Mode switch
  • 0 km/h stop

Not just what the vehicle does, but what the rider understands.

![Brake Switch Error State / Annotated Logic]

2. When Safety Becomes the Constraint

Our early prototype followed the traditional toggle model. It worked mechanically. But during testing, a brake switch error exposed a deeper issue.  

If braking input wasn’t detected correctly, the vehicle could attempt to return to the previously set speed.

Technically rare. Experientially unacceptable.

The core intent of cruise is to reduce effort. Even the possibility of hesitation would introduce tension into daily riding. The system might have been recoverable, but the feeling of seamlessness would not be.

Due to this, the development had to be paused on all fronts. Cruise remained shelved for nearly two years, because it didn’t meet the safety clarity we expected from it.

Trust was not a layer on top of the feature. It was a core part of it.


![Wheel Speed Sensor Diagram / System Overview]

3. Hardware Upgrades

Two years later, we began shipping vehicles with wheel speed sensors to enable traction control (another feature I worked on).

Instead of relying solely on throttle and brake signals, the system could now monitor actual wheel speed in real time.

For cruise, this introduced something we previously didn’t have: redundancy at the perception level. If braking input failed, speed deviation could still be detected. If the vehicle slowed due to an external factor, cruise could exit safely.

The technical shift was subtle, but the experiential shift was not.

Earlier, cruise had to behave defensively, cancelling quickly to avoid risk. Now it could behave fluidly and adapt without abrupt interruption.

For the first time, we could rethink state transitions, engagement thresholds, and failure feedback from a rider-first lens.

Cruise returned. Not as a binary toggle, but as a system capable of continuity.


This is where design re-entered the room. Engineering unlocked redundancy, and my role was to redesign the behaviour around it.


![Annotated State Flow Diagram – Engage / Pause / Resume/ Latching and adapting]


4. Redefining Engagement

With improved sensing, the question shifted:

> How should cruise behave in unstable traffic without feeling fragile?

Traditional cruise is binary: Engaged or Disengaged.

You set a speed. It holds that speed. Any interruption cancels it.
That model assumes stability, but urban riding is anything but.
 

Instead of treating cruise as a fixed preset, we redesigned it to **latch onto rider intent**.
 
  1. If a rider accelerated beyond the engaged speed, cruise adopted the new speed seamlessly.

  2. If they slowed down and stabilised, cruise held that new speed.  

  3. If they dipped below 10 km/h, cruise transitioned into a paused state — visibly and predictably.

For example:
  • Cross 10 km/h → engage cruise with button → it latches onto 10.
  • Throttle up to 40 → cruise adopts 40.  
  • Brake to 15 → cruise holds 15. 
  • Slow below 10 → cruise pauses.

This system didn’t fight the rider. It followed them.


We formalised this into a layered state model. Internally, the system had multiple states. Externally, the rider experienced only four: 

**Active** — dynamically holding current stabilised speed  
**Paused** — temporarily suspended below threshold  
**Disengaged** — fully off
**Speed Reset** — allowing speed change, within a cruise session

The paused state prevented accidental cancellations in traffic while avoiding the surprise of automatic re-engagement.

  • Below 10 km/h, cruise paused instead of terminating.  
  • Above 10 km/h, it resumed seamlessly.  
  • At 0 km/h, it required deliberate deactivation.

If the rider came to a complete stop (0 km/h), the system required deliberate deactivation on the dashboard.

The goal wasn’t automation. It was adaptability to the user’s actions.


The 0 km/h Debate

In our early implementation, cruise disengaged completely at 0 km/h. Every stop ended the session, which felt safe and predictable.

During a leadership review, a different perspective was raised by Tarun, the CEO. Instead of ending the session at 0 km/h, should cruise automatically latch back once the rider accelerates past 10 km/h again?

We were initially skeptical. Automatic re-latching felt risky. It introduced behaviour that could easily feel jarring or unsafe if not handled carefully.

We built it into the prototype to evaluate it in motion.

In testing, the behaviour felt surprisingly natural. The rider accelerated as usual, crossed 10 km/h, and cruise resumed smoothly without abrupt torque or confusion. Instead of feeling automated, it felt like continuity.

That decision became one of the defining behaviours of Infinite Cruise. Cruise no longer behaved like a simple toggle, it started behaving like a session.


![Speed Breaker Testing Image or UI at Low Speed]

5. The 1 km/h Test

Minimum engagement speed became one of the most debated decisions. Initially, we experimented with extremely low thresholds, even 1 km/h.

During testing, I crossed a speed breaker with cruise active. As the front wheel descended and the rear followed, the system attempted to reconcile the speed difference because the motor tried to compensate for the momentary wheel-spin/drop by surging torque.

The effect was subtle but perceptible, giving me a slight whiplash.

That observation shifted the threshold conversation from theoretical safety to felt safety. Cruise needed to feel invisible.  

At very low speeds, even small corrections become exaggerated in traffic. Hence, we increased the minimum threshold.


The final range:
**10–90 km/h**
  • 10 km/h ensured predictable behaviour in dense traffic  
  • 90 km/h preserved motor and battery performance leaving a buffer to the maximum capacity (vehicle top speed: 100 km/h)


The numbers were not arbitrary. They balanced real-world riding behaviour with hardware longevity.


![Adoption Metrics / Quote Block / Usage Visualization]

6. Designing for Calm

Logic alone does not create ease. The system could be intelligent, but if the rider had to think about it, it had already failed.

Cruise needed to communicate its state instantly, even in peripheral vision, even mid-turn, even under acceleration.


We designed the interface around 4 clear moments:

  1. When Cruise is engaged
  2. When it is actively holding speed
  3. When it is temporarily suspended
  4. When it is resetting speed


Engagement 
When first engaged, there’s an auditory feedback alongside a clear visual confirmation. The Cruise pill appears with a blue glow behind it, informing the user that a Cruise session has begun. Along with this, contextual exit instructions appear if engagement was by mistake. 


Active
The Active state used persistent speed emphasis. Not flashy, but unmistakable. The Cruise pill becomes smaller, but stays perpetually.
The system communicates: cruise is holding.


Paused
The Paused state deliberately reduced emphasis without removing context. When braking or speed drops below threshold, the system transitions immediately. The pill shifts from Active to a subdued version, clearly differentiating the Cruise state. Cruise is not gone, it is waiting.


Speed Reset
When braking or a speed change occurs, the pill transitions from Active cruise to the Engagement state, displaying instructions to disengage.


Sound Design
Because the vehicle speakers were not conventional audio systems, activation and disengagement tones required careful tuning. 

The sound needed to be:
  • Audible in traffic
  • Subtle enough to avoid alarm
  • Distinct between engage and disengage




(Sound design was developed in collaboration with my manager, who had led the vehicle’s broader audio language)

We iterated on pitch, duration and loudness to ensure the feedback felt calm and never jarring, as sound on a vehicle can become a double-edged sword. 


Nothing pulsed or bothered unnecessarily. The system avoided visual or auditory drama and focused on clarity of state at speed, even in periphery.

![Adoption Metrics / Quote Block / Usage Visualization]

7. Shipped

The feature initially shipped with the 2025 450 Apex before rolling out to the primary 450X line of scooters.

Internally, it was one of the most complex Ride features we had built. Externally, it felt simple.

Common feedback from real-world users:

  • Reduced physical fatigue in traffic 
  • Less cognitive load from throttle modulation  
  • A calmer, more composed ride  

The most encouraging signal was not adoption rate. It was the absence of confusion. Not one instance of “I don’t understand this, how do I disable it?”. 

When a system disappears into the ride, you know it’s working.

The feature was launched fleet wide to the eligible vehicles (450 Apex and 450X with Wheel speed sensors) on 1st Feb, 2026. The usage data is till 18th Feb, 2026 (first 18 days post launch): 



What it Proved
Cruise control is not difficult to implement. Designing it for unpredictability, without making it intimidating, is.

For a deeper look at the engineering behind the feature, read the technical perspective written by the team I worked with:
Cruise Control, Reimagined for Scooters.

Some experiences can be explained, this one you have to ride to believe. The video below captures its essence.