Multimodal Search Accessibility Mobile

TATA Motors — Simplifying spare parts search for 52,000 mechanics

A multimodal search experience for Tata Genuine Parts that lets mechanics find the right spare part in seconds, using voice, image, or text in any of India's regional languages.

Role
Product Designer
Timeline
8 weeks · Mar–May 2021
Team
1 PD · 1 UXR · 1 UX Lead · 1 Lead Engineer
Partner Agency
YUJ Designs
TATA e-Dukaan — multimodal search interface

"Tata Genuine Parts (TGP) is the OEM parts division of Tata Motors, supplying components to over 52,000 mechanics across India who service Tata's commercial vehicle fleet. YUJ Designs was brought in to redesign the e-Dukaan search experience from the ground up."

I joined as the product designer embedded with YUJ Designs for this engagement. The existing search experience was built around a single text field that required exact part numbers or names: a fundamental mismatch with how mechanics actually work. They know parts by regional nicknames, by sight, or by the vehicle they're pulling them from. Not by catalog codes.

The business problem

A search UX failure with a measurable cost

Tata Motors observed a 12% decline in motor parts revenue. The root cause wasn't logistics or pricing. Mechanics were abandoning the platform when they couldn't find what they needed fast enough, sourcing from third-party suppliers instead. Every failed search was a lost sale and a crack in the brand's reliability story.

12%
Revenue decline in OEM motor parts, traced to search failures
52K+
Mechanics spending more time searching than repairing
22
Official languages in India, none of which the existing search supported
1
Search method: text only, for a workforce often wrist-deep in an engine
01 — The Challenge

Four ways the old design failed the people using it

The existing e-Dukaan search was built for the database, not for the mechanic. It assumed users knew exact part numbers, spoke one language, and were typing on a clean keyboard from a desk. None of those assumptions held in the field.

The old e-Dukaan search interface — before redesign
Search one-dimensional
Text-only input. No fallback for mechanics who couldn't spell a part name, didn't know its catalog term, or simply had dirty hands.
No visual hierarchy
Results arrived as an undifferentiated list with no grouping by assembly, no kit bundling, and no signal about what was previously ordered.
Not inclusive design
No accommodations for varying literacy levels, low-light garage conditions, or the physical reality of working with both hands occupied.
No multilingual support
India has 22 official languages and hundreds of regional dialects. The app recognized exactly one, and expected mechanics to use it correctly.
Problems in the old design summary
How Might We
"How might we help mechanics quickly find the right auto parts by simplifying the search interface?"
Design principles going in

The four principles that shaped every decision

Multimodal search
Text, voice, and image as equal first-class search methods, not add-ons, each suited to different real-world scenarios.
Relevant information
Results organized by assembly and kit, not just keyword match. Show what matters to the job, not what the database knows.
Inclusive design
Designed for varying literacy levels, low-light conditions, and the physical constraints of garage work. Accessibility as a baseline, not a feature.
User-friendly interface
A guided experience with smart defaults: recent searches, registered vehicles, and recently viewed parts surfaced before the mechanic types a word.
02 — Research & Process

Designing all four modes before talking to a single user

We mapped out all four search approaches on a single canvas first, then used this as a conversation starter with mechanics. Testing against something concrete let us validate assumptions quickly rather than designing in a vacuum.

All four search modes mapped on a single canvas
User interviews

Six mechanics. Three cities. Four languages.

User interviews were the only method that made sense here. We needed to understand cultural and language nuances firsthand, not through intermediaries. Multilingual sessions with the full cross-functional team: UXR, UX Lead, and Lead Engineer joined every call.

01
Six mechanics across Bangalore, Delhi, and Gujarat
Sessions held in each mechanic's preferred language to get unfiltered responses about their actual search experience. No translator, no softening.
02
I personally interviewed Jay Shah in Gujarati
Eliminating the translation layer meant we heard exactly how mechanics describe their frustrations. The engineering lead was present, so constraints reached him directly rather than through a design brief.
03
Cross-functional listening
Having UXR, UX Lead, and Lead Engineer in every session meant decisions could be made with shared context. No telephone-game distortion between research and engineering.
Mechanics know the part by sight and by sound. The catalog number is the last thing they think about.
Same part, four different names depending on which state you're in. None of them wrong.
Hands are always occupied. Typing is a last resort, not a default.
Who we designed for

Four mechanics. Four different search problems.

Subbu, auto mechanic, Bangalore
Subbu
Auto mechanic · Bangalore
"We spend too much time looking for the parts we need. If we could find parts more easily, we could finish our jobs much more quickly."
Arjun, auto mechanic, Delhi
Arjun
Auto mechanic · Delhi
"We call parts by different names, like 'patti' in South India and 'chakka' in the North. I want the search to give results in our terms."
Jay, auto mechanic, Gujarat
Jay
Auto mechanic · Gujarat
"Having support in Gujarati will make our work even easier."
Meena, auto mechanic, Gujarat
Meena
Auto mechanic · Gujarat
"As soon as we get the right parts, our work speed picks up, you know?"
What we learned

What mechanics needed that the app never gave them

01
Fast search to minimize downtime
A delayed job costs money. Every extra minute searching is a minute the vehicle isn't fixed and the mechanic isn't earning.
02
Regional terms alongside catalog names
Parts have different names in different states. "Patti" and "chakka" aren't wrong; they're just regional. The system needed to know both.
03
Native language input as a first-class option
Not a toggle buried in settings. If a mechanic thinks and speaks in Gujarati, the search should work in Gujarati without friction.
04
Search that works when hands aren't free
Typing requires clean hands. Mechanics often have neither. Voice and image input weren't nice-to-have; they were the only realistic path to accessibility.
Wireframes

From insight to interface in four screens

Each research finding mapped directly to a wireframe decision. Tactically organized information, realistic part images, and actual vehicle data so mechanics could react to something real rather than something abstract.

Wireframe screens — Search on click and Search by part number
Wireframe screens — Search by fleet number and Search by unusual name
03 — The Solution

Four ways to search. One experience.

The final design gives mechanics four search paths that adapt to their situation. Hands dirty? Voice or camera. Know the exact part? Type by name. Just want to reorder? One tap from the home screen. The search method adapts to the mechanic, not the other way around.

Search by Click

Smart defaults that eliminate the blank screen

Resolves: one-dimensional search, poor repeat-order experience

Search by Click: recent searches, registered vehicles, recently viewed parts
Recent searches surface first. The most common use case: a mechanic returning to find the same part they ordered last week. One tap, not a full search.
Registered vehicles shown on open. Mechanics service the same fleet repeatedly. Tying search to a known vehicle eliminates wrong-part errors before they happen.
Recently viewed parts with quick add-to-cart. For mechanics mid-job who need to reorder, no search required at all.
Search by Name

Suggestions that group by how mechanics think

Resolves: no visual hierarchy, fragmented search results

Search by Name: suggestions grouped by assembly and kits with last-ordered items
Results grouped by assembly and kit. A mechanic replacing brakes needs all the brake components, not an alphabetical list of parts that happen to include the word "brake."
Last-ordered items highlighted first. Repeat jobs are the majority of a mechanic's work. Getting to the right part on the second visit should be faster than the first.
Intelligent suggestions on every keystroke. The system anticipates the part before the mechanic finishes typing, reducing cognitive load in a high-pressure, time-sensitive environment.
Search by Voice

Speak the part name in any language you know it

Resolves: no multilingual support, hands-free accessibility

Search by Voice: multilingual voice input with regional dialect recognition
Supports Hindi, Gujarati, Tamil, and English. Mechanics say the part name in the language they learned it in. The system resolves it to the catalog entry without requiring transliteration.
Regional dialect recognition built in. "Patti" in Tamil Nadu and "chakka" in Delhi both resolve to the correct part, not a no-results page.
Hands-free by design. A mechanic under a truck with both hands occupied can speak a search and have results ready when they come back to the screen.
Search by Image

Photograph a worn part, get the replacement

Resolves: literacy barriers, worn parts with no visible labels

Search by Image: OCR-powered visual part identification
OCR-powered part number extraction. If the part still has a visible number or label, the camera reads it directly. No manual transcription, no typos.
Visual matching for worn or unlabeled parts. When a part is too degraded to have a readable number, image recognition identifies it by shape and context.
Accessibility for low-literacy users. A mechanic who struggles to read in any language can still find the right part. The camera removes the literacy requirement entirely.
Design system

Brand consistency without compromising usability

We used Tata's existing color system, typography, and brand identity as the foundation. The design language needed to feel like Tata: reliable, confident, built for serious work. We extended it with a cohesive icon system in line-style, 3D, and shaded variations that reinforced trust and pride in the brand at every touchpoint.

Tata brand color system
Icon system: line, 3D, and shaded variations
Typography system
After launch

e-Dukaan shipped. The numbers followed.

The redesigned e-Dukaan launched on the Google Play Store. Time to find a part dropped significantly, user satisfaction rose, and adoption spread well beyond the original 52,000 mechanic base.

e-Dukaan: 50K+ downloads, 40% reduced search time, 30% satisfaction increase
40%
Reduction in search time after the multimodal redesign shipped
30%
Increase in user satisfaction score for spare parts purchases
50K+
Downloads on Google Play Store, far beyond the original user base
4×
Search modalities available, replacing a system that only had one
Learnings

What this project changed about how I design

01
Fleet number search was wrong from the start
Our initial design organized search around fleet numbers. Mechanics don't think in fleet numbers. They think in parts, vehicle models, and the job they're trying to finish. The first prototype exposed this gap immediately.
02
Early involvement beats late validation
Having mechanics in the room, not just as research subjects at the start but as ongoing references throughout, meant we could pressure-test decisions in real time. We caught wrong assumptions in weeks, not months.
03
Cross-language collaboration needs deliberate design
Running interviews in Gujarati and Hindi alongside English changed how our team communicated. The engineering lead heard constraints directly instead of filtered through a designer's summary. That directness shortened our iteration cycles.
04
Accessibility is a product requirement, not a UX nicety
Voice and image search weren't built because they're cool features. They were the only realistic way to serve a user base with varying literacy levels working in environments where typing is impractical. Designing for the hardest constraint improved the experience for everyone.
05
Technology serves the user's mental model
OCR and multilingual voice recognition weren't chosen because they were available. They were chosen because mechanics already had a mental model: speak or show the part. The technology let us match it. Start with the behavior, then find the technology that fits.