00 · Context
What is SPEC Borescope?
An AI-based web application by General Electric used for Remote Visual Inspection of Gas Power Turbines. It compares, tracks, and records the health status of a turbine fleet by analysing defect images across inspections — spanning up to 35 years of data. Desktop-only. Inspections run 3–4 times per year.
Who
Field Inspection Engineers, SPEC Engineers, Managers — each using the same tool for different ends.
What
Compare defect images across inspection years. Annotate, measure, group, and report on turbine health.
Why
To monitor turbine fleet health, catch defect growth early, and reduce the manual burden on domain experts.
Where
Desktop web app. Used in the field and in the office. Borescope equipment feeds images directly.
When
Reports generated at any point in time. Formal inspection cycles run three times a year.
How
Compares defect images from past and present inspections. AI detects defects; engineers validate and annotate.
Ecosystem — how data flows
01 · Problem Space
20+ insights. Three problems worth solving.
Secondary research across GE internal documentation, domain knowledge transfer sessions, and prior inspection data surfaced 20+ system insights. After a priority matrix session with the team, two modules were selected: Measuring Defects and Compare Historical.
Friction 01
AI makes mistakes — and users know it
AI can auto-detect defects, but its accuracy is not trusted. Engineers overwrite AI annotations constantly. Trust is the core design problem.
Friction 02
Selecting the right base image is manual and error-prone
Users must manually sort and select the BASE IMAGE from 20+ images per inspection. High mental load. High scope for human error. No system guidance.
Friction 03
Comparing defects across years is a repetitive cognitive task
AI cannot auto-tag defects with reference to previous states. Engineers repeat this task for every defect — time-consuming, high cognitive load, easy to lose track.
Other key insights from secondary research
Inspections run 3–4 times per year. Same defect areas are revisited every cycle.
14 major defect types (Spallation, Oxidation, Crack, TBC…). Defects must be compared like-for-like: Crack vs Crack, not Crack vs Oxidation.
Borescope images go back 8 years. Resolution varies — images must be scaled to the base image for accurate comparison.
One defect is compared at a time to avoid confusion. Users pick defects one by one and complete up to 10 reports per defect.
Domain expertise is required. Engineers need deep knowledge of turbine anatomy — sections include HGP bucket, combustion, compressor, bearing stage.
Images can be captured from multiple perspectives. Matching the same physical location across inspections is non-trivial.
02 · Field Research
Two sites. Two kinds of pain.
Two field visits were conducted to understand Turbine inspections and SPEC Borescope use cases in their real operating context — not in a meeting room.
Visit 01
CGPL Mundra
Coastal Gujarat Power Limited · Kutch district, Gujarat
On-site at an active power plant. Observed how field inspection engineers operate in a high-noise, high-pressure environment — far from the designed desktop experience.
Visit 02
JF Welch Technology Centre
Gas Turbine Maintenance Lab · Bengaluru
Lab environment. Observed how SPEC Engineers interact with inspection data and reports in a controlled setting — closer to the core tool workflow.
User interviews
Santosh Jha
Desk Maintenance Engineer · CGPL Mundra
6 years experience · Meeting in person · Tech expert · Detail oriented · Dedicated
Key findings
- —AI makes a lot of mistakes — confidence in AI results is low and fragile.
- —Image selection from 20+ images to find the same defect is consistently frustrating.
- —Selecting and adding defects by checking base image back and forth is slow and error-prone.
- —Defect type confusion — Crack vs Crack, Spallation vs Spallation — breaks flow.
- —Adding defects one by one is time-consuming and very difficult to track across images.
Aniket Sahu
Maintenance Manager · General Electric
12 years experience · Online calls · Values time · Always in a hurry · To the point
Key findings
- —Usage frequency varies (twice a month to quarterly) — hard to remember report generation steps.
- —Sometimes instant reports are needed before shutdown or routine maintenance — no fast path exists.
- —It usually takes 3–4 attempts to generate the required report.
- —SPEC Borescope screens are hard to remember between sessions.
- —Intermediate reports stored in different repositories — hard to find when needed.
03 · Personas
Two users. One tool. Different needs.
Primary User
Abhishek Sinha · SPEC Engineer
33 years · “Annotate, measure and compare defects, then generate a report.”
Pain points
- —Base image selection from pool of 20+ images
- —Selecting inspection images with the same defect
- —Adding a defect is an additional manual task
- —Mapping and tagging each image by location
- —Remembering what has been tagged in which image
Goal
Inspect, validate and compare all identified defects against their current state, then generate a report.
Needs
Summary of defects and their growth over time.
Devices
Desktop · Dual monitors
Screen time
10 hrs / day · Tech-savvy · Dedicated
Secondary User
Niharika Grover · Asset Manager
35 years · “Get the consolidated report. See the full picture of fleet health.”
Pain points
- —Time and effort investment in generating reports
- —Trust issues with AI analytics and human error
Goal
Get the consolidated report and centralised overview of all inspections.
Devices
Laptop · Desktop · Projector
04 · User Journey
Four stages. One thread of trust.
Inspection by year
Compare products against their previous state by selecting images from different inspections.
Opportunity
Auto-select and tag multiple defects with retrospective data. System status visibility.
Measure Defects
See how the particular defect or group of defects has changed over time.
Opportunity
Easy zoom, commenting system, avoiding radio button confusion.
Compare Measurements
User-specific, customisable summary of defects over time with scale.
Opportunity
Clear information hierarchy. Reduction in scope of human error.
Generate Report
Create a customisable summary report in an easy-to-share format. Archive for future reference.
Opportunity
Easy-to-download report with customised view. One click.
Lean UX Canvas · Key decisions
Business problem
Improve the experience of image and defect tagging on SPEC Borescope — improve information hierarchy, add system status visibility, reduce user mental load.
Core hypothesis
AI is not going to be able to auto-tag images — it is not trained based on the physical location of defects. The solution must empower the user, not replace them.
Target outcomes
- ↗Decrease task completion time
- ↗Fewer clicks per workflow
- ↗Clear information / visual hierarchy
- ↗Reduction in scope of human error
User outcomes
- ↗Annotate and stage selection with minimum effort
- ↗Unambiguous, clear status of selected images
- ↗Improved visual hierarchy throughout
05 · Ideation
Three concepts. One direction.
Multiple discussions, brainstorming and feedback sessions with the development team produced three distinct design concepts — each addressing a different layer of the problem.
Concept 01
Bucketing System
Group similar defects to compare them together
Users can group defects of the same type (images from different inspection years) into a “bucket” — reducing the mental load of remembering what to compare against what. Users can now add and compare multiple defects simultaneously. Cracks compared with Cracks. Oxidation with Oxidation.
Concept 02
Summary Chart
Per-image defect status visible on hover
A summary chart appears on hovering over an image. It informs the user what defects have been selected in that particular base image and their respective groupings — giving a clear picture of system status without navigating away.
Concept 03
Dual Image Layout
Base image and inspection image side by side
Both the base image and the current inspection image are shown simultaneously — eliminating the back-and-forth between images during annotation. Screen wireframes were ideated based on visual hierarchy and eye movement to keep the comparison natural.
06 · Design
From wireframe to working prototype
The three concepts were translated into screen designs and a clickable Figma prototype — tested with sales reps across the two field visit sites.
Screen 01 · Measure Defects + Bucketing
Defect annotation view with the Bucketing system. All Defects panel on the right with colour-coded defect types and image thumbnails. Bucketing reduces the selection mental load from 20+ images to grouped clusters.
Screen 02 · Compare All Measurements
Compare All Measurements view. Defect images from 2021 and 2012 side by side. Crack length by year bar chart below. Defect tabs (A_CRACK, B_CRACK, C_CRACK) allow switching between grouped defects without losing context.
Interactive prototype
Interactive Prototype
Prototype coming soon.
The Figma prototype will be embedded here. In the meantime, reach out to see it live.
07 · Reflection
What I learned from my first real product
Lesson 01
Align with engineers and PMs before going deep into design
Ideas get constrained by dev and engineering, not users. I learned this the hard way — proposed concepts were marginalised by technical constraints after significant design investment. Early alignment changes what you invest in.
Lesson 02
Field research needs a business thread to survive stakeholder meetings
Maintaining and documenting field research insights in a way that connects to business outcomes is as critical as the research itself. Without that thread, insights get overridden by opinions in the room.
Lesson 03
Real products don't follow a clean UX process — and that's correct
Multiple iterations, skipped steps, revisiting earlier phases mid-stream. This project evolved my understanding of what a design process actually is versus what it looks like in a textbook. Adaptability is the real skill.
Lesson 04
Documentation is a design skill
Tracing a decision from field insight to research finding to design choice to stakeholder sign-off is harder than the design itself. The story has to hold at every stage — not just at the presentation.