Ruthvik Panchakshari

Seattle, Washington

Ruthvik Panchakshari

Seattle, Washington

Ruthvik Panchakshari

Seattle, Washington

Live

Jump to final design

Tuner: Guided Diagnostics for Electric Motorcycles

Tuner: Guided Diagnostics for E-Motorcycles

I led the UX for Guided Diagnostics, a new workflow in Zero's dealer service tool that helps technicians move from symptoms to root causes with less guesswork and less reliance on customer support.

CLIENT

Zero Motorcycles Inc. | Scotts Valley, CA

27%

fewer support tickets

2,100+

support hours potentially avoided over six months

dealerships in pilot

Timeline

Jun 2025 · Present

Updated August 2026

My Role

Product Designer

Platform

Windows Desktop Application

Responsibilities

Research & Synthesis

Workflow Design

Interaction Design & Prototyping

Design System

Collaborated With

Director, Product Experience

Product Manager

Software Engineering

Customer Experience (CX)

Quality Assurance

Director, Product Experience

Product Manager

Software Engineering

Customer Experience (CX)

Quality Assurance

01 / CONTEXT

Technicians had access to diagnostic data, but still relied heavily on support.

Before Tuner, dealership technicians relied on a legacy diagnostic tool that surfaced system data but offered limited guidance on what to do next. Routine cases were frequently escalated to Zero’s Customer Experience (CX) team, leaving less capacity for the complex cases that actually required specialist support.

65%

of dealership service cases required CX escalation

300+

weekly support hours spent on routine service cases

Internal CX data · 2024–25

FROM DIAGNOSTIC DATA TO DIAGNOSTIC GUIDANCE

From accessing diagnostic information to being guided through what to do next.

The legacy experience gave technicians access to diagnostic systems and data. Tuner was an opportunity to turn that information into a guided path from check to interpretation.

LEGACY DIAGNOSTIC EXPERIENCE

TUNER · GUIDED DIAGNOSTICS

02 / DISCOVERY

I focused the research on where diagnosis stalled.

With a fast launch timeline and limited technician availability, I focused the research on moments where diagnosis stalled or confidence dropped. I conducted 8 interviews and 4 field observations, supported by targeted desk research where needed, then compared what technicians said with what actually happened in live repair workflows.

Focused Interviews

Field Observations

03 / FINDINGS

Three patterns kept showing up.

Technicians diagnose by acting, not reading

They preferred working through concrete steps and checking results over reading documentation before taking action.

EV diagnostics remove cues technicians usually trust

With fewer sensory cues such as engine noise or smell, technicians depended more heavily on digital readings — and felt less certain when those readings lacked context.

Access to information wasn’t the same as guidance

Raw values, unclear error states, and fragmented navigation made technicians spend time interpreting the tool before they could decide what to do next.

KEY INSIGHT

The tool gave technicians information.

They needed help making decisions.

That shifted my design goal from organizing diagnostic information to helping technicians know what to check, what a result meant, and what to do next.

04 / GUIDED DIAGNOSTICS

What if the tool could help technicians decide what to check, and what to do with the result?

FOR TECHNICIANS

Less guesswork.

Step-by-step decision paths help technicians understand what to check, what a result means, and what to do next.

FOR ZERO

More consistency.

A more consistent, auditable diagnostic process across dealerships.

WHERE GUIDED DIAGNOSTICS FITS

Connect Bike

Auto Health Check

Auto Gather Logs

Present Faults

Guided Diagnostics

Share Knowledge

05 / TESTING & ITERATION

EARLY DIRECTION

The first version turned the idea into a workflow.

I translated Guided Diagnostics into an early “Bike does not key on” workflow to define the information architecture, navigation, and sequence of decisions. The first version established the overall structure, but it still assumed technicians could orient themselves and interpret several test results with limited guidance.

EARLY FLOW · 01

IMAGE — ADD IN FRAMER

View larger ↗

EARLY FLOW · 02

IMAGE — ADD IN FRAMER

View larger ↗

EARLY FLOW · 03

IMAGE — ADD IN FRAMER

View larger ↗

Early Guided Diagnostics flow: Bike does not key on

USABILITY TESTING · 5 TECHNICIANS

Testing exposed where technicians still had to interpret too much.

The overall Guided Diagnostics concept held up, but the sessions exposed where the workflow needed clearer orientation, stronger interpretation, and better information hierarchy.

TESTED PROTOTYPE · POWERPACK DISCHARGE

Root-cause order didn’t match how technicians actually worked through a diagnosis.

Several checks were bundled into one long procedure, making it harder to track progress and understand the result of each step.

Root-cause order didn’t fully match technicians’ troubleshooting sequence

Multiple checks still lived inside one continuous procedure

TESTED PROTOTYPE · BMU MALFUNCTION

Primary actions and supporting information competed for attention on the same screen.

The tool showed the result, but still asked technicians to decide what it meant.

One screen had to handle observations, system actions, and support

Technicians still interpreted deterministic results themselves

06 / SCALING

I turned recurring diagnostic steps into a reusable state model.

Across flows, the same moments kept recurring: collect evidence, interpret results, repair, and verify. I turned those moments into four reusable states so new diagnostic flows could scale without becoming one-off screens.

Testing showed that different diagnostic flows were asking the same screen to do too much — collect evidence, surface support, trigger actions, and interpret results. As more flows were added, I needed a model for how the diagnosis itself should behave, not another one-off screen.

I mapped the recurring moments in a diagnosis into four reusable states, each with a clearer responsibility.

REUSABLE DIAGNOSTIC LOGIC

CHECK

ANALYSIS

REPAIR

VERIFY

Check and Analysis can repeat, with Analysis returning to Check when more evidence is needed before moving into repair and verification.

FROM STATES TO REUSABLE TEMPLATES

Each recurring state became a reusable screen structure that could be adapted across different diagnostic flows.

CHECK TEMPLATE 01

IMAGE — ADD IN FRAMER

View larger ↗

CHECK TEMPLATE 02

IMAGE — ADD IN FRAMER

View larger ↗

CHECK TEMPLATE 03

IMAGE — ADD IN FRAMER

View larger ↗

ANALYSIS TEMPLATE

IMAGE — ADD IN FRAMER

View larger ↗

REPAIR TEMPLATE

IMAGE — ADD IN FRAMER

View larger ↗

POP-UP / SUPPORTING PATTERN

IMAGE — ADD IN FRAMER

View larger ↗

SCALE

A reusable model supporting 500+ screens

The shared workflow model gave the team a repeatable structure for designing more than 500 Guided Diagnostics screens without treating every new flow as a one-off.

DESIGN FOUNDATION

Building the system alongside the product.

While Guided Diagnostics was growing, I helped organize and expand Tuner’s existing visual assets into a more reusable system of foundations, components, and interaction patterns. This gave design and engineering a shared structure for building new screens without recreating the interface each time.

Explore the Tuner Design System ↗

FOUNDATIONS

IMAGE — ADD IN FRAMER

View larger ↗

COMPONENTS

IMAGE — ADD IN FRAMER

View larger ↗

PATTERNS

IMAGE — ADD IN FRAMER

View larger ↗

07 / FINAL EXPERIENCE

The state model turned diagnosis into a sequence of focused moments.

The final experience breaks diagnosis into four focused moments: checking the bike, interpreting the result, carrying out the repair, and verifying that the issue is resolved.

CHECK → ANALYSIS

The technician provides the evidence. Tuner interprets what it means.

For deterministic checks, the technician enters or confirms the result, then Tuner evaluates it in a separate Analysis state instead of asking the technician to make the same judgment.

A MULTI-STEP ROOT CAUSE

Longer procedures became a series of focused checks.

For multi-step diagnoses, each action became its own Check state before the workflow moved into Analysis.

Verification reuses the same Check pattern, letting technicians confirm the repair without having to learn a new interaction.

08 / IMPACT

Now in pilot across 30 dealerships.

Preparing to scale to more than 250 dealerships worldwide.

27%

fewer support tickets

An early pilot signal from support-ticket volume. Broader product outcomes will continue to be measured as deployment expands.

MEASURED

27%

fewer support tickets

MODELED

2,100+

support hours potentially avoided over six months

≈$140K

estimated support cost avoided over six months

WHAT WE’RE STILL MEASURING

Root-cause accuracy

Did the guidance lead to better decisions?

Diagnostic completion time

Did greater independence translate to speed?

Time-to-repair

Did the workflow ultimately help technicians resolve issues faster?

WHAT WE’RE STILL MEASURING

Root-cause accuracy

Did the guidance lead to better decisions?

Diagnostic completion time

Did greater independence translate to speed?

Time-to-repair

Did the workflow ultimately help technicians resolve issues faster?

TAKEAWAY

Good decision-support design isn’t about giving people more information. It’s about knowing when the system should interpret, when it should guide, and when it should get out of the way.

UP NEXT

Tuner Design System

Building a reusable system of foundations, tokens, components, and patterns for Tuner.

View case study ↗

Context

Discovery

Findings

Guided Diagnostics

Testing & iteration

Scaling

Final experience

Impact