This was a proof-of-concept exploration prepared for TVS Motor, not a shipped product. No usage metrics exist for it — the value of this case study is in the design process: how the existing app was diagnosed, and how that diagnosis became a new structure.
01The brief
TVS Connect is the companion app for TVS's connected motorcycles and scooters — it pairs with the bike to show real-time vehicle data, service reminders, navigation, and a rider community. The existing app had all of these pieces, but they didn't feel like one product. The brief was to propose a clearer structure for TVS Connect: audit what existed, look at what competitors were doing, and recommend a direction.
02Design audit
Before proposing anything new, I audited the live TVS Connect app screen by screen — Dashboard, Vehicle Overview, Navigation, and Community — scoring what worked and what didn't against basic usability fundamentals.
- No clear flow for understanding the information on screen
- Low-visibility CTA on the homepage banner
- Poor discoverability of functions — risk of drop-out
- Separate subsections for clearer categorisation
- Give the primary CTA visual prominence
- Contextual CTAs tied to what the rider is actually doing
- Inconsistent UI elements; arbitrary placement creates confusion
- Poor grouping of information, no clear information architecture
- Oversized cards waste screen space; no type hierarchy
- Standardise ride-overview layout across all bike models
- A real design system for consistent components
- Personalise content to improve discoverability
- Inconsistent button sizing and hierarchy on map cards
- No contextual functions — feels generic, not bike-specific
- Poor visibility of system status while navigating
- Consistency over decoration in map UI
- Surface nearby fuel stops and service centres contextually
- Clear feedback for every action the rider takes
- Low trust and legibility — the community feels empty
- No visual hierarchy, so nothing invites engagement
- No direct search for events, rides, or people
- Show rider profiles and photos upfront to build trust
- Replace the buried drop-down with visible entry points
- Add search and trending filters to surface activity
The problems weren't really four separate screen issues — they were one structural issue. The home screen's information architecture had grown unconventionally, with inconsistent type, card sizes, and button styles creating a cluttered hierarchy. Fixing screens individually would have papered over a problem that needed a new structure underneath.
03Competitive scan
To benchmark where TVS Connect stood, I reviewed four connected-vehicle apps — Harley Davidson, Hero Connect, Ather, and Yamaha's Y-Connect — against the same two questions: what's working, and what's missing.
04Personas
Riders use a connected-vehicle app for very different reasons depending on who they are and how they ride. I defined three archetypes from rider interviews to stress-test the new structure against, instead of designing for one assumed "average" user.
05The Four C's
Every pain point from the audit and the personas sorted into one of four jobs the app needed to do. Rather than another flat list of features, I proposed reorganising all of TVS Connect around four pillars — a structure simple enough to become the app's actual navigation, not just a slide in a deck.
Collapsing the app's sprawling feature list into four named pillars meant every future screen had an obvious home. It also gave the rest of the pitch a shared vocabulary — "that's a Care problem" or "that belongs in Commute" — instead of relitigating where a feature should live.
06Concept screens
With the structure agreed, I designed onboarding screens that introduce each pillar on first open, and concept screens for two of the four — Connect and Care — to show how the new IA would actually look and behave on a real screen, not just in a diagram.
07Outcome
As a proof-of-concept, this work doesn't have shipped-product metrics to report — there's no download count or drop-off rate to point to. What it delivered was a clear, defensible direction: a structural diagnosis of the existing app, evidence from four competitors and three rider archetypes, and a four-pillar model specific enough to brief a build team against.
The clearest lesson from this one wasn't visual — it was that a messy app is rarely four messy screens. It's usually one missing structure wearing four different masks. Naming that structure was worth more to the pitch than any single polished mockup.