AI-Guided Diagnostic for Vehicle Service
Turning a rigid troubleshooting flow into a smarter diagnostic conversation
Role: UX Researcher / Product Design Consultant
Company: BRP
Domain: Vehicle service, dealership tools, electrical diagnostics, AI-assisted troubleshooting
Users: Certified BRP dealership technicians
Methods: Moderated user testing, task-based research, think-aloud protocol, prototype iteration, qualitative analysis, stakeholder recommendations
Keywords: AI-assisted service tools, guided diagnostics, user research, dealership technician workflow, electrical troubleshooting, conversational UX, LLM interface, human-in-the-loop, BUDS ecosystem
Overview
Electrical issues are one of the most common reasons customers bring BRP vehicles to dealerships.
Internal data showed that 52% of dealer visits were related to electrical-system problems, and 78% of those issues were concentrated around recurring failing components, including the battery, magneto, stator, and related systems.
BRP Engineering had mapped a troubleshooting flow to help technicians identify likely causes faster. My role was to test how that flow translated into a usable interface, identify where technicians struggled, and recommend a better design direction.
The key lesson was simple:
The right AI experience was not more automation. It was a more natural diagnostic conversation that respected technician expertise.
1. Situation
Electrical diagnostics are frequent, complex, and time-sensitive
BRP dealership technicians work in a practical service environment. They need to diagnose vehicles quickly, follow the right procedures, and access vehicle-specific information such as wiring diagrams, graphics, and documentation.
The opportunity was to create a new diagnostic side application within the BUDS ecosystem to guide technicians through electrical troubleshooting.
BUDS was already part of the service ecosystem, but it was a slow and sometimes glitchy Windows application. I suggested that the new guided diagnostic experience could work better as a lightweight web app: easier to access, easier to iterate, and better suited to a focused troubleshooting task.
The product challenge
Engineering had created a structured troubleshooting flow. The logic was sound: based on vehicle symptoms, the tool would guide the technician through tests in a specific order and help identify the likely failing component.
The design challenge was different:
Could technicians actually use this guided flow in the way the system expected?
To succeed, the experience needed to:
- identify the correct vehicle
- capture all relevant symptoms
- guide the technician through tests in the right order
- provide vehicle-specific instructions and diagrams
- support both experienced and less tech-savvy technicians
- feel faster and more useful than manual troubleshooting
The risk was that a technically correct diagnostic flow could still fail if the interaction model did not match how technicians work.
2. Actions
I ran a fast research sprint with real service users
The research was organized as a fast-paced, guerrilla-style sprint:
- 1 week of preparation
- 3 rounds of prototype testing over 3 weeks
- 3–4 participants per phase
- 30-minute remote moderated sessions
- task-based testing with think-aloud observation
- qualitative post-task questions
Participants included BRP engineers, subject-matter experts, and internal and external service technicians.
We intentionally included a range of technician profiles: younger, tech-native users and experienced veterans who were less comfortable with new software.
The task scenario was practical:
A Spyder vehicle has electrical symptoms. Use the tool to identify the likely failing component.
The goal was not to measure satisfaction with a survey. The goal was to watch where technicians hesitated, misunderstood the flow, or tried to work around the interface.
Prototype direction 1: guided flow with vehicle selector and symptoms
The first tested direction included:
- vehicle selection
- symptom selection
- a reset button
- sequential diagnostic instructions
- test steps based on selected symptoms
Technicians could select symptoms, then launch the guided troubleshooting flow.
The core issue appeared quickly.
Users often selected one symptom, then moved forward as soon as the interface displayed the next step. The tool expected them to add all symptoms that applied before continuing, but the next-step UI pulled their attention forward.
The “+” button for adding symptoms was technically available, but users were eager to start the diagnostic.
The behaviour was clear:
Technicians were not trying to carefully complete a form.
They were trying to get to the fix.
This created a serious product risk. If users failed to select all symptoms, the diagnostic flow could start from incomplete information and guide them down the wrong path.
User Testing Prototype #1
Prototype direction 2: a more restrictive stepper
To reduce errors, the next prototype made the flow more restrictive.
The design added:
- a stepper
- confirmation after each major step
- a more controlled sequence
- clearer required actions before proceeding
This improved task completion. Users were more likely to select the required information before moving forward.
But the research exposed a new problem.
The flow became too slow.
Younger, tech-native technicians in particular complained about the number of clicks, the repeated confirmations, and the feeling of being blocked. Experienced users also wanted faster ways to select known information.
Some of the feedback was direct:
“Just give me a dropdown.”
“I don’t want to answer five screens before starting.”
The restrictive flow solved the system’s need for complete input, but it weakened the technician’s sense of speed and control.
That was the core tension:
The system needed structure.
Technicians needed freedom.
User Testing Prototype #2
I reframed the experience as a diagnostic conversation
After testing the guided and restrictive flows, I proposed a different direction: an LLM-style diagnostic assistant.
Instead of forcing technicians through a rigid sequence, the tool could behave more like a smart service conversation.
The interaction model was simple:
- Start by selecting the vehicle, or reusing the last selected vehicle.
- Ask the technician to describe or select all observed symptoms.
- Confirm: “Are these all the symptoms you noticed?”
- Guide the technician through the appropriate tests.
- Use vehicle-specific diagrams and documentation when needed.
- Adapt the conversation as new information emerges.
This approach kept the diagnostic logic, but changed how the technician experienced it.
The system still needed complete context. But instead of blocking the user with rigid steps, it could ask clarifying questions, confirm assumptions, and guide the user more naturally.
The experience became less like filling out a form and more like working with a smart assistant.
User Testing Prototype #3
Prototype direction 3: LLM-style guided diagnostic
I built the conversational prototype from scratch.
The design used an LLM-like interface to make the experience feel more flexible, adaptive, and intelligent.
The flow included:
- vehicle selection or reuse of the last vehicle
- symptom gathering through conversational prompts
- explicit confirmation that all symptoms had been captured
- guided test instructions
- contextual responses based on technician input
- a more organic progression through the diagnostic flow
The goal was not to make the AI feel magical. The goal was to make the workflow feel more natural.
Technicians still needed to follow the right test procedure, but the system could interact with them in a way that felt closer to how they diagnose problems: by gathering clues, confirming context, and narrowing the possibilities.
What we learned from the conversational test
Technicians reacted much more positively to the LLM-style experience.
They were more open to adding symptoms when they forgot some, because the assistant asked for confirmation in a way that felt natural rather than punitive.
Users described the flow as smarter and more organic.
One technician said:
“This feels smarter.”
Another surfaced an important shop-floor use case:
“I’d use voice because my hands are dirty.”
That comment was important. It revealed that the diagnostic experience was not only a screen design problem. It was a service-environment problem.
Technicians may be standing near a vehicle, handling tools, looking at components, or working with dirty hands. A conversational interface could eventually support voice interaction and reduce dependency on a keyboard, mouse, or laptop within reach.
3. Results
Research reduced product risk
The research helped BRP avoid overcommitting to a rigid guided workflow.
Each prototype answered a different question:
- Could technicians follow a guided diagnostic flow?
- Would they provide complete symptom information?
- Would a restrictive stepper reduce errors?
- Would technicians accept the friction?
- Could a conversational assistant preserve structure without slowing them down?
The final insight was not that technicians needed less guidance.
They needed guidance that respected their expertise.
The conversational direction balanced two competing needs:
The system needed complete diagnostic context.
Technicians needed speed, flexibility, and control.
The direction moved toward MVP planning
My contract ended before I could observe the long-term implementation impact. But according to my manager, after the research the team synced with the AI team and development team to review requirements and begin planning an MVP in the following sprint.
The AI team was already exploring a model that could retrieve vehicle-specific graphics and wiring diagrams from BRP documentation.
That made the conversational diagnostic direction more credible. It connected the user experience with real AI capability:
- retrieve the right vehicle-specific documentation
- surface relevant wiring diagrams
- guide technicians through the proper tests
- ask clarifying questions when symptom input is incomplete
- support a more adaptive troubleshooting flow
What changed
The research helped shift the design direction from:
“How do we force users through the correct troubleshooting steps?”
to:
“How do we guide technicians through the right diagnostic reasoning without slowing them down?”
That shift mattered.
The product opportunity was not just a step-by-step wizard. It was an AI-assisted diagnostic companion for dealership technicians.
What this project proves
This project shows my ability to use research to shape product direction before a team commits to the wrong interaction model.
The engineering logic was valuable. The diagnostic flow made sense. But the early prototypes showed that the user experience needed to account for real technician behaviour: speed, expertise, incomplete symptom recall, dirty hands, vehicle-specific context, and frustration with unnecessary steps.
My contribution was to turn those observations into a clearer product direction.
The right solution was not simply more control or more automation.
It was:
a more natural diagnostic conversation that respected technician expertise while still helping the system collect the information it needed.
Relevant strengths
User research for complex workflows
Testing a technical diagnostic flow with engineers, SMEs, and dealership technicians under realistic task conditions.
AI-assisted product design
Exploring how an LLM-style interface could support troubleshooting, symptom gathering, documentation retrieval, and guided decision-making.
Service-tool UX
Designing for users working in real shop environments, not ideal office conditions.
Human-in-the-loop design
Balancing system guidance with technician judgment, confirmation, correction, and control.
Risk reduction
Using fast prototype testing to identify usability risks before MVP development.
Strategic design recommendation
Reframing the product from a rigid wizard into a more flexible AI-guided diagnostic assistant.
Lafortune Design 