End-to-end search

Context

• Platforms: iOS, Android, Web.
• Team: PM, tech lead, analyst, 3 SWEs, 3 QA.
• Timeline: December 2025 – July 2026.

The problem

When I joined the team, more than half of users weren't finding what they came for: only 40% of search sessions ended in success, and satisfaction with search sat at 2.6 out of 5. We counted a session as successful when the user clicked a result and didn't return to search within 10 seconds — meaning they found the thing instead of rephrasing the query. The core metric was falling well short of expectations, and that's what put a redesign on the table.

My task

1. Find the weak points in the search flow and identify where it could grow
2. Form hypotheses based on the findings
3. Validate the hypotheses through research
4. Build a redesign concept and get leadership sign-off
5. Carry the solution through to release

Research and market benchmarking

Together with the customer experience team, we studied the existing flow and surfaced several problems:

• No personalization: the search start screen was identical for everyone, all the time. The closest things to personalization were the "Recent searches" and "Transfers by phone" blocks. Both saw real use, but the first actually slowed people down — it just copied text back into the search bar — and the second took up a lot of screen space
• The "Financial tips" block was only useful if you had an account or a payment due, yet it claimed a large share of the search screen
• Long, conversational queries never made it through the funnel: the engine couldn't handle questions ("How do I…", "How much…") and simply returned a search error
• One non-obvious finding: phone-number transfers underperformed specifically in the web version on iOS. The native apps worked fine, but web on iPhone had no access to the address book — unlike Android, where it worked in the browser too. Users were left either digging through history to repeat an old transfer or typing the number by hand, which visibly hurt the flow's conversion

Market benchmarking showed a clear trend toward personalization: static start-screen content was giving way to screens assembled for the specific user. In parallel, the market at large and the company itself were building out their own AI — and that set the direction: banking search needed its own AI assistant, and search itself was to become the entry point for most everyday operations.

Hypotheses to test

• Removing the underperforming static blocks ("Financial tips," "Recent searches") and replacing them with personalized elements would make the start screen more relevant and speed up the target action
• Shrinking the "Transfers by phone" block would free up space for higher-priority content without losing conversion on the transfer itself
• Adding an AI assistant to search would let users resolve the complex, long-form queries that previously ended in an error, and turn search into a true entry point for banking operations
• An onboarding flow for enabling Contact Picker API (an experimental Safari feature that exposes system contacts to the browser) would lift transfer conversion on iOS web — users would no longer have to type numbers by hand or hunt for an old transfer in history

Validating the hypotheses

I tested selectively — wherever the risk of getting it wrong was higher or the solution wasn't obvious (Contact Picker API and its onboarding, for example), I ran hallway usability tests. For the lower-risk hypotheses I leaned on the research data and market practice, plus self-serve tools in Pathway: A/B tests, first-click tests, and heatmaps.

Building the concept

The research left me with a pile of drafts, which I distilled into a working concept and took to the division's vice president for sign-off. After a few iterations, the flow came out even more focused on personalization:

1The search start screen became personal

Before typing a query, every user used to see the same static suggestions. I replaced them with personalized chips — a reminder to pay off a loan, clear a balance, pick a cashback category — actions relevant to that specific customer right now. If a category holds several payments, a bottom sheet opens with the details.

I also dropped the "Financial tips" and "Recent searches" blocks, shrank "Transfers by phone," and renamed it "Recent transfers." Transfer conversion didn't move, and the screen gained a noticeable amount of room.

2iOS web users got the flow they already knew from the mobile app

Transferring money by phone number is a frequent flow, but unlike the apps, the web version had no access to the user's contacts. I designed an onboarding flow for connecting the address book through Contact Picker API, an experimental Safari feature — it opens the native iOS contact picker and drops a contact's number straight into the field.

The flow shipped recently, so there's no conversion data on it yet.

3Rolling out a full AI assistant

We moved in stages: first, Gazik, the bank's animated mascot, appeared on the search page — users needed time to get used to the character before it started answering questions.

Later the team built an ML classifier that reads intent — it knows when a plain results list is enough and when a query needs a real answer. For something like "what's my transfer limit?", where the user needs a direct answer on the spot, I designed the assistant's response with text that streams in progressively, ChatGPT-style — layered right on top of the familiar results. A disclaimer always sits next to the answer, and when the assistant isn't confident, the flow falls back to the regular results list.

4Scaling the entry point across top-level screens

As an experiment, the product owner proposed placing a search entry point on every first- and second-level screen of the web app, betting it would grow search penetration. I got the floating button's placement signed off with the owners of each screen, with the button's label adapting to the screen it sits on. Tap through to search, and Gazik suggests queries relevant to where you came from.

The result

The team shipped the changes over several releases, and the biggest shift was in the successful-session rate: it climbed 85% — from 40% to 74%. Most of that gain came from question-type queries — the ones that used to dead-end in a search error and now reach an answer. The new personalized chips also saw a 50% higher CTR than the static ones — the bet on personalization paid off. Monthly search users grew by 20%, and average satisfaction rose from 2.6 to 3.5. But the rating itself hid an unexpected finding.

40% → 74%

successful search sessions

2.6 → 3.5

search satisfaction

+50%

personalized vs static suggestion CTR

+20%

search MAU in the web app

The real insight: 9 out of 10 ratings were either a 1 or a 5

Digging into the satisfaction increase, I looked at the ratings distribution behind the average score: 46% ones, 43% fives, only ~11% in between. An average of 3.5 described a user who didn't exist: search had no "average" users, just happy ones and unhappy ones, and the star scale was hiding them behind each other. I pushed to switch to a binary like/dislike rating — it shows the real split instead of a fake middle ground.

46% 1

11% 2–4

43% 5

What this taught me

• A metric can hide a non-obvious insight: when a scale isn't behaving the way it was designed to, that's a reason to rethink how the data gets collected
• The familiar Gazik did the onboarding for us: users didn't have to get used to a new character and a new feature at the same time

Next case — Dashboard →