VEDANT SHARMA

Designer in Bengaluru, seven years in. Four of which have been at Ather Energy, designing rider-facing experiences for electric two-wheelers.

My work spans interaction design, HMI, typography, and branding, with a focus on clarity under motion, legibility at speed, and behaviours that feel invisible in real riding conditions.

I come from a background in typeface and graphic design, which informs how I approach every problem: through hierarchy, clarity, and visual decisions built to last across vehicles and product lines.

Outside of work: solo motorcycle rides, strength training, 3d printing, photo walks, books, and films.

CV

vedant@vdnt.me

Instagram

LinkedIn
INFINITE CRUISE - Cruise Control

Role
 Lead Product Designer

Scope
State model · Engagement logic · UI · Auditory feedback

Collaborators
Product · System Intelligence · HMI Engineers

Timeline
2023 - 2025



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 not really). 

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

Your throttle input is constant. Speed fluctuates. And then your braking is frequent and reactive.

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


Traditional Cruise Control Systems in four and two-wheelers

1. Designing for Instability

Conventional Cruise Control logic is binary:
  • Engage  
  • Hold speed 
  • Use +/- buttons to modulate 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 *state-based system*, one that could adapt to variability without compromising clarity.

The design question became:

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


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.



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.

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.



3. Hardware Upgrades

Two years later, we began shipping vehicles with Wheel-speed Sensors to enable traction control (a separate 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.

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.


State Flow – 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.
 

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.


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?

The team was 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.



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.


Play with sound

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 on the top 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 uses persistent emphasis. Not flashy, but unmistakable. The Cruise pill becomes smaller but stays perpetually, the system communicating: 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 the subdued version, clearly differentiating the Cruise state. Cruise is not gone, but it is waiting.



Speed Reset
When any braking or speed change occurs, the pill transitions from Active cruise to the Speed Reset 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.


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




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 the absence of confusion. Not one instance of “I don’t understand this, how do I disable it?”. 


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 (18 days post-launch): 


  • 11,400+ Riders tried Infinite Cruise

  • 813,000+ km Cruised

  • 23,100+ Hours in Infinite Cruise




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

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

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.







HOME