Search redesign where the real work wasn’t designing — it was asking “why?” until the right problem showed up leading to 14% increase in CTR
role
Lead Product Designer
remix.supply
remix.supply
team
Researchers, PMs, Developers, TPMs, and Analysts.
platform
iOS & Android App
impact
14% increase in CTR to placing trades
remix.supply
remix.supply
INTRODUCTION
The brief arrived as a shopping list
The Jira landed with three line items:
•add search suggestions,
•make filters richer with nested options,
•introduce LTR ranking.
No context. A due date. I read it twice. Then I walked over and asked the most annoying thing a designer can ask a PM, "WHY"?
"Torso-level queries (longer than 3 characters) — have the highest CTR. We want to convert more queries into torso-level ones."
— PM, in response to "why?"
That answer led to more questions. Which led to a conversation with engineering. Which revealed the actual constraint: the backend couldn't meaningfully rank ambiguous queries like "35" or "ni" in real-time. Thousands of possible assets. Milliseconds of processing time. The tech couldn't fix vague queries — so the product had to prevent them.
THE "WHY" CONVERSATION
Click to expand and read this section
PROBLEM
Users type vague queries (lacking confidence & effort) while our tech has limitations. So, UX needs to find a way to shape better queries for improved results.
HOW MIGHT WE STATEMENT
How might we help users add more context and form better queries — with minimum effort?
CONTEXT
Click to expand and read this section
WHO IS THIS USER?
Click to expand and read this section
SOLUTION
Tap, don't type.
So the solution needed to be:
• Least dependent on typing — don’t ask Ramesh to do the thing he’s least confident at
• Explicitly visible — nothing hidden, nothing ambiguous, nothing in small grey text
• Prompt-like, not specific — give him directions, not a blank field
Suggestions was the right direction. But how suggestions worked — that was still up for debate.
IMPACT
14%
increase in overall search CTR
6 —>7
Shift in customer NPS
48%
Top-3 result CTR preserved
BELOW SECTIONS PROVIDE MORE DETAILS TO THE PROCESS, DECISIONS & DESIGN
PM HAD AN OPINION
HE WAS WRONG.
The PM's instinct was horizontal chips — tidy, low-footprint, non-disruptive. But for Ramesh, horizontal scrolling is invisible. He won't swipe to find suggestions sitting off-screen. Chips that require discovery are chips that don't exist.
Two Philosophies of Search
When I looked at how other products handled suggestions, two models emerged.
Model A — Accept & show (Instagram style): User types, results appear instantly below. Suggestions are almost a shortcut to a result, not a query-building tool.
Model B — Strengthen the query (Google style): Suggestions help the user complete or refine what they’re trying to say before results appear. The query gets better first
Two data points helped me decide.
• CTR on the top 3 search results was around 48%. That’s enormous. Whatever we built, we couldn’t disrupt the results that were already working.
• Updating results at every character input was causing confusion. Users were watching the list change under their fingers mid-type and losing track of where they were.
This pointed clearly toward Model B. We needed to help Ramesh build a better query — not flood him with shifting results while he was still thinking.
SOLUTION PROCESS
Here’s what the new search journey looked like:
The suggestions appear vertically, not horizontally. They’re large, tappable, and immediately visible. No scrolling required. Ramesh sees them, recognises them, taps one — and lands exactly where he wanted to be.
The nested filters only appear once the query has enough context (4+ characters). By that point, the user has already expressed intent. Filters now have something to work with.
While we were in there
A few other things got fixed along the way — because once you’re redesigning a journey, you clean the house.
• Filter chips → tabs. Chips felt like tags. Tabs feel like navigation. For a product trying to become a financial super-app, the distinction matters — it reinforces that each filter category is a real destination, not just a label.
• Company logos added to results. Data from the homepage showed logos improved engagement. The tech had just built the capability to surface them in search. We added them. Small lift, meaningful signal for recognition.
• Design debt cleared. Category titles were inconsistent. Search transitions were janky. The “no results found” state didn’t exist. The keyboard opening and closing behaved differently across flows. None of this was glamorous. All of it mattered.
END NOTES
What I’d Tell Every Designer Who Gets a Feature Brief
Features are answers. Your job is to find the question.
When the PM said “add suggestions,” he wasn’t wrong. Suggestions was the right solution — eventually. But if I’d built what he asked for, the way he asked for it, we’d have shipped horizontal chips that Ramesh would never tap, for a problem we’d never properly defined.
The “why” conversation isn’t about being difficult. It’s about making sure the effort everyone is about to spend — engineering, design, product, QA — is pointed at something real.
A few things I took from this project:
The user’s constraint is the design brief. Once I knew Ramesh was a tap-first, type-reluctant user, every design decision had a filter. Does this require him to type more? No. Does this hide options he needs to discover? No. Is this prompt-like enough? Yes.
Data tells you what. Research tells you why. The analytics said torso queries perform better. Research told me why users weren’t typing torso queries in the first place. You need both — neither one is enough on its own.
The PM names the feature. You solve for the experience. That’s not a power struggle. It’s a division of expertise. Own your half.
The best design decision I made on this project wasn’t a UI choice.
It was asking “why” — twice.
THANK YOU FOR YOUR PATIENCE :)