TUNER: Guided Diagnostics for E-Motorcycles
Client: Zero Motorcycles Inc. | Scotts Valley, CA
About
My Role
Product Designer
Platform
Desktop Application
Responsibilities
Problem Framing | Research & Synthesis | Design System | Flow & Interaction Design
Timeline
June 2025 - Present
Team
Shreyas NS (Director, Product Experience)
Matthew Johnson (CX Lead)
Aaron Diep (Product Manager III)
Akshay Bharadhwaj (Graphic Designer II)
Engineering Team
The Context
why this project exists
The current diagnostic tool, Diag4Zero, led to a systemic dependence on external support, with repetitive service queries frequently routed to Customer Experience(CX) teams, dealership workflows often requiring intervention to progress, and technicians remaining limited in their ability to use the tool independently.
Understanding The Problem
and reframing it
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
O
Technicians operate in an action-first mindset
They don’t want to read steps. They want to act through steps.
O
EV diagnostics remove sensory cues
Technicians rely on digital interpretation, increasing cognitive load and uncertainty.
O
The tool is perceived as intimidating rather than supportive
Technicians felt less confident in their decisions.
O
Technicians want guidance that accompanies them through uncertainty
Support is most needed at moments of uncertainty.
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
O
Navigation and information architecture slow down workflows
O
The tool surfaces data but does not support decisions
O
Error messages lack context and actionable clarity
O
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
Assumes technical knowledge
Requires manual interpretation
Offers limited guidance for decisions
Technician Reality
Prefer acting over reading
Rely on confidence before taking action
Experience uncertainty with digital-only cues
Need support during moments of doubt
What Technicians Are Really Trying To Achieve
What they want:
What they fear:
What they possibly need:
Reframing The Problem.
How might we transform diagnostic tools from data viewers into decision-support systems that help technicians confidently interpret system information and progress independently?
For Tuner to truly support technicians, diagnostics needed to evolve from tools into a guided workflow for interpretation, decision-making, and action:
The Key Idea
Guided Diagnostics
The business wanted more consistency.
Technicians wanted less guesswork.
Before exploring solution directions, I strengthened the tool’s design foundation to support scalable diagnostic workflows…
From Assets To A System
Tuner started with basic visual assets, and I had already begun structuring them into a design system and expanding reusable components to support more complex workflows across the tool.
With the design foundation in place, I began exploring how guided diagnostics could translate into a clear, step-by-step interface.
Early Design Directions
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 (CIII)
Screen 1/11
Screen 2/11
Screen 3/11
Iterations and Refinement
Compared to early exploration screens, this iteration focused on strengthening decision support and reducing cognitive load:
• Diagnostic procedures were restructured into clear, sequential steps
• Decision points were explicitly separated from action steps
• Progress tracking made workflow state visible to technicians
• Supporting materials integrated directly within each step
Iterated Mockups for Flow: Bike does not key on (CIII)
Screen 1/15
Screen 2/15
Screen 3/15
Iterations and Refinement
To validate the workflow, I ran a lightweight usability test with two technicians to refine its logic and structure.
Key Insights:
• Clear entry point needed before root causes
• The system should interpret test values automatically
• Support materials should be optional and expandable
• Numbered root causes reduce guesswork
Designing for Scale
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.
Diagnostic Workflow Framework
Diagnostic Workflow 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.
Final Designs
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)
Root Cause 1 Check
Root Cause 1 Analysis
Root Cause 2 Check 1
Root Cause 2 Check 2
Root Cause 2 Check 3
Root Cause 2 Analysis
Where This Landed
In Pilot
The guided diagnostic feature is currently being piloted across three dealerships in California.
What We're Measuring
• Diagnostic completion time
• Step abandonment rate
• Error reduction in root cause selection
• Escalation to senior technicians
• Technician confidence
• Time-to-repair validation
Due to pilot-stage data restrictions, detailed results cannot be shared publicly.
Takeaway
Good tools don’t replace human judgment — they make it easier to use.
Designing for autonomy in complex systems means helping people feel safe making one decision at a time.