Aaveg's Fun Fact
Loading…
Back to projects
Comparison Page UXComparison Page UX
COMPARISON UX · DECISION ARCHITECTURE · MOBILE

Comparison Page UX

Rebuilding CarWale's side-by-side car comparison flow to handle the messy reality of how buyers actually compare cars, with cross-brand, cross-segment, and cross-fuel-type combinations that the old design quietly assumed away.

Role
Sr. Product Designer
Company
CarTrade Tech
Timeline
Oct 2023 - Apr 2025
Focus
Comparison UX, Decision Support, Mobile UX
01 · Context

The old comparison page assumed a tidy buyer

CarWale had a comparison feature that worked beautifully when buyers compared two variants of the same model. The columns aligned, the spec rows aligned, the verdict-style summary at the top made sense. It was a clean piece of design for the canonical comparison use case.

It started breaking down the moment buyers tried what they actually wanted to do. Compare a hatchback against an SUV. Compare a petrol variant against an electric. Compare three cars across three brands. The columns would either truncate uncomfortably, surface differences that were irrelevant to the actual buyer's question, or produce a verdict that was meaningless because the comparison was apples-to-oranges in ways the design did not acknowledge.

Session recordings made the failure mode visible. Users would set up a cross-segment comparison, scroll halfway, and abandon. Some would retreat to setting up multiple browser tabs with single-model pages and comparing manually. A few power users had built their own comparison rituals using note-taking apps because the site's comparison was unusable for their case. Real comparison behaviour was messy and our design was tidy. We had built a product for the comparison we wished people did, not the one they actually do.

02 · Research

Watching messy comparisons get attempted and abandoned

I ran a research pass that deliberately focused on the non-canonical comparison cases the old design did not handle well. I sampled session recordings for users who had set up cross-segment or cross-fuel comparisons, watched them try to use the page, and noted where they got stuck.

The patterns were consistent. Users in cross-segment comparisons did not actually care about most of the spec differences that the page surfaced, because those differences are obvious by category (an SUV is taller than a hatchback, a petrol car has different running costs than an electric one). They cared about a small set of decision-relevant dimensions that varied by individual buyer. One user comparing an SUV and a hatchback cared specifically about cargo volume and parking footprint. Another cared about fuel efficiency under their specific commute pattern. The dimensions that mattered were specific to the buyer, not to the comparison.

This observation became the design thesis: the buyer, not the system, should decide which dimensions matter for their comparison. The default set of dimensions should be a reasonable starting point, and the user should be able to add, remove, and reorder dimensions to match what they actually care about. The system should be a tool the buyer wields, not a verdict the buyer receives.

Comparison archetypes, mobile patterns, dimension preferences

04 · Approach

Let the buyer drive what is compared

The redesigned page is organised around the principle that the buyer decides which dimensions matter for their comparison. The default view is a curated set of universally-relevant dimensions, then a clearly visible affordance lets the buyer add, remove, and reorder dimensions to match their priorities.

Cross-segment comparisons stopped being a degraded experience and became a first-class one. An SUV-versus-hatchback comparison defaults to a set of dimensions that makes sense for that comparison, not the spec dump that made sense for variant-versus-variant. The page understands what kind of comparison is being attempted and adjusts its default content accordingly.

On mobile, the trickiest constraint was the small viewport. Side-by-side columns at any spec density become unreadable on a narrow screen. I prototyped four layouts before landing on a column-swap pattern that keeps focus on one car at a time while preserving the comparison context. The user swipes between cars within a fixed dimension framework. This is harder to design than parallel columns, but it produces a mobile experience that respects the screen rather than fighting it.

The design language stayed consistent across mobile and desktop. The column-swap pattern works on desktop too, where it sits alongside the parallel-column layout as an alternative view. Many desktop users preferred it for cross-segment comparisons, where parallel columns produce visual noise. The pattern earned its way into desktop on the back of being designed for mobile first.

Behaviour studies, prototyping, mobile constraint exploration

06 · Key decisions

Mobile drives design, buyer drives dimensions

Mobile drives the design. Most CarWale traffic is mobile. The old desktop-first design was being painfully translated to mobile and losing fidelity along the way. I committed the team to designing the mobile experience first and treating desktop as the wider format of the same idea. This was unpopular at first because the team was used to working on the bigger canvas. After a few rounds of mobile prototypes, the discipline of designing for the small screen actually clarified the desktop layout.

Buyer-controlled dimensions, not system-imposed. The standard pattern in comparison UX is for the system to decide which dimensions to show and in what order. The buyer's job is to interpret the verdict. We inverted this: the buyer decides which dimensions matter, the system provides a sensible default, and the verdict is the buyer's to draw. This shifted the page from being a comparison verdict-generator into being a comparison toolset.

Default dimension sets by comparison type. Cross-segment comparisons default to different dimensions than same-segment comparisons. Cross-fuel comparisons default to different dimensions than within-fuel comparisons. The system tries to be intelligent about defaults without taking control away from the buyer. This required a taxonomy of comparison types that the content team maintained alongside the system.

The dimension customisation pattern travels. The buyer-controlled dimension customisation became a reusable pattern adopted by adjacent pages on the site, particularly the variant differentiation page where it shared design DNA. Designing for messy comparison behaviour produced a system that travels beyond the original page, which is the kind of compounding return that justifies the upfront design investment.

Column-swap pattern in production

Column-swap pattern in production

Hatchback vs SUV, petrol vs EV, three-way comparisons

09 · Outcomes

Cross-segment comparisons became viable

The most visible outcome was qualitative: cross-segment and cross-brand comparisons stopped being a degraded path. Buyers who previously gave up on the page when they hit the old constraints now completed comparisons that span unusual combinations. The completion rate on cross-segment comparisons rose noticeably in post-launch measurement, although the absolute number of cross-segment comparisons was always smaller than canonical same-segment ones.

The dimension customisation pattern also got adopted by adjacent pages on the site. The variant differentiation page used the same pattern. The model overview page used a simplified version of it. Designing for the messy reality of comparison behaviour produced a system that travels beyond the original page, which is the kind of compounding return that justifies the upfront design investment in any system-level work.

10 · Reflection

Stop sanitising user behaviour in research

The old design was the product of clean user research that had unconsciously sanitised messy comparison behaviour into tidy patterns. That is a research failure as much as a design failure. The researchers had asked users what they wanted, the users had answered in tidy hypothetical terms, and the design had been built for the tidy answers rather than for the actual messy behaviour the session recordings would have revealed.

I would push the team next time to over-index on the weird and edge-case behaviours that show up in session recordings, because those edges are often where the real product opportunity hides. Pretty research is a known failure mode and one I want to be more wary of in future work.

Comparison UXDecision ArchitectureCross-segmentMobile-firstInformation Density