I led the end-to-end UX design for Guided Diagnostics in Tuner, Zero's B2B service tool, from research through Phase 1 rollout, helping technicians identify and resolve issues with lesser reliance on support.
CLIENT
Zero Motorcycles Inc. | Scotts Valley, CA
Timeline
Jun 2025 · Present
Updated April 2026
My Role
Product Designer
Platform
Desktop Application
Responsibilities
Problem Framing
Research & Synthesis
Design System
Flow & Interaction Design
Team
Shreyas NS | Director Product Experience
Matthew Johnson | CX Lead
Aaron Diep | Product Manager III
Akshay Bharadhwaj | Graphic Designer II
Engineering Team
Shreyas NS
Director Product Experience
Matthew Johnson
CX Lead
Aaron Diep
Product Manager III
Akshay Bharadhwaj
Graphic Designer II
Engineering Team
why this project exists
Before Tuner, dealership technicians relied on Diag4Zero, an older diagnostic tool that created heavy dependence on Zero's CX team. Routine troubleshooting queries were repeatedly escalated instead of being resolved at the dealership, leaving Zero's CX technicians without capacity to focus on the complex cases that actually needed them.
understanding the problem
Given the fast-moving launch timeline and limited technician availability, I began with focused interviews and field observations to surface recurring patterns and the mental models technicians use when diagnosing issues, supported by desk research where needed.
What interviews revealed…
Technicians operate in an action-first mindset
They want to act through steps, not read them.
EV diagnostics remove sensory cues
Without engine noise or smell, technicians rely entirely on data readings, increasing uncertainty.
The tool felt intimidating, not supportive
Technicians felt less confident in their decisions.
Guidance most needed at moments of uncertainty
Support should accompany technicians through the unknown.
While interviews revealed how technicians think and feel about diagnostics, field observations helped surface how these challenges played out in real workflows.
What field observations revealed…
Navigation and information architecture slow down workflows
The tool surfaces data but does not support decisions
Error messages lack context and actionable clarity
Effective use depends heavily on prior expertise
A clear tension emerged: Technicians want to act with confidence, but the diagnostic tool forces them to interpret complex information before they feel ready to act.
The core mismatch..
Current tool reality
- Surfaces raw system data without interpretation
- Assumes deep technical knowledge from the user
- Requires manual interpretation of every reading
- Offers limited guidance for decision-making
Technician reality
- Prefers acting over reading through steps
- Needs confidence before taking action
- Experiences uncertainty with digital-only cues
- Needs support at moments of doubt
How might we transform diagnostic tools from data viewers into decision-support systems that help technicians confidently interpret system information and progress independently?
guided diagnostics
Guided Diagnostics could addresses both. Technicians get step-by-step decision paths that remove the guesswork from diagnosis, and Zero gets a consistent, auditable service process across every dealership.
Where Guided Diagnostics fits in the workflow
Connect Bike
Technician connects the diagnostic interface to the motorcycle
Auto Health Check
System scans all ECUs automatically
Auto Gather Logs
Fault codes and system data are surfaced
Present Faults
Identified faults shown in a prioritised list
Guided Diagnostics
design focusStructured decision paths help technicians isolate and resolve issues independently
Share Knowledge
Outcome is logged and shared across the dealership network
Guided Diagnostics is the new layer designed to sit between raw fault data and technician action, turning information into guided, confident decisions.
While working on other parts of Tuner in parallel, I was shaping the design system that the tool runs on, defining component patterns, navigation structure, and visual hierarchy to support a consistent experience across the tool.
building the foundation
With that foundation running in parallel, I began translating the diagnostic logic into early interface concepts, focusing on decision paths that would tell technicians exactly what to do next.
translating the idea into interfaces
I translated the core symptom flows into early mockups to define the information architecture and navigation. These initial designs focused on clarifying decision paths so technicians could understand what to do next.
Early snapshots for Flow: Bike does not key on (Cypher III)
Screen 1/11
Screen 2/11
Screen 3/11
testing and improving
Key insights from testing
- Technicians were dropped into root causes without context, making it hard to orient before diagnosing
- The system was leaving test value interpretation entirely to the technician
- Support materials were always visible and adding visual noise to each step
- Root causes had no numbering, making it hard to track progress through a diagnosis
What changed as a result
- Diagnostic procedures restructured into clear, sequential steps before root causes are shown
- System now interprets test values automatically, reducing cognitive load on technicians
- Supporting materials moved to optional expandable sections within each step
- Root causes are now numbered, giving technicians a clearer sense of structure and progress
Iterated Mockups for Flow: Bike does not key on (Cypher III)
Screen 1/15
Screen 2/15
Screen 3/15
not just screens
In parallel with testing, I began translating recurring patterns into reusable templates to ensure the workflow could scale beyond a single scenario.
Guided Diagnostics Template Screens
Check Screen 1
Check Screen 2
Check Screen 3
Analysis Screen
Repair Screen
Pop Up Screen
With these templates established, the workflow scaled to over 400 screens while maintaining consistency across diagnostic flows.
the shipped experience
The final system integrates structured diagnostic logic with reusable UI patterns to deliver a scalable, decision-support workflow.
Final Mockups for Flow: Bike does not key on (CIII)
early results
In pilot · 15 dealerships
Early signal
27%
fewer support calls
Measuring at full launch
Root cause accuracy
Pending
Did the guidance lead to better decisions?
Diagnostic completion time
Pending
Did independence translate to speed?
Time-to-repair
Pending
Did it result in faster fixes for customers?
what this taught me