The results appear, but the place names are in the local language. You struggle to understand the descriptions, and you're not even sure whether the place you've selected actually provides what you need.
Technically, the search engine has done its job. It returned several results.
But has the user actually accomplished their goal?
This is exactly the problem we're exploring in the second product management interview question:
"How would you improve the local search experience for someone who doesn't understand the interface language well?"
This question falls under Product Sense & Design. It evaluates our ability to identify the underlying problem, choose a target user segment, prioritize solutions, and design an experiment with measurable outcomes.
Is the Interface Language Really the Problem?
Our first instinct might be to introduce a language switcher or automatic translation.
That's not necessarily a bad idea. But we still don't know what the actual problem is.
Perhaps the user doesn't know how to express their search query in the local language. Maybe they can search in their native language, but the system returns irrelevant results. Perhaps the results are correct, but the user cannot understand their descriptions.
It's also possible that the user finds the right place but cannot match its translated name to the sign outside the actual building.
These are four different problems, and they won't necessarily be solved by the same feature.
Before proposing a solution, we need to clarify three things:
- Who is the user, and under what circumstances are they searching?
- At which exact step are they unable to proceed?
- How will we know that we've solved their problem?
One important distinction is that the user's search language, the application's interface language, and the language spoken at the destination may all be different.
If we ignore this distinction, we're probably oversimplifying the problem.
Who Are We Designing For?
There are several potential user groups in this scenario.
A tourist visiting another country for a few days, a recent immigrant, an international student, or even someone who has lived in a country for years but still struggles with the local language.
Each group has different needs.
A tourist might primarily search for restaurants, transportation, and attractions. A recent immigrant may have more frequent needs related to healthcare, banking, and government services.
In an interview, we don't need to design a solution for everyone simultaneously.
I would initially focus on travelers with limited knowledge of the local language who need to find essential services nearby.
Why this group?
Because in some situations, choosing the wrong location can result in significant wasted time or practical consequences. We can also define specific tasks to test whether our proposed solution works.
However, this is an initial hypothesis, not a conclusion supported by research.
If the evidence shows that immigrants experience this problem more frequently or severely, we should reconsider our priorities.
First, Identify Where Users Get Stuck
Let's assume we're improving the search experience in a mapping application.
Instead of immediately designing new features, we should examine the user's journey:
Start searching → Enter a query → View results → Evaluate options → Select a location → Reach the destination
Each stage raises a different question.
Can the user enter the intended query? Does the system return relevant results? Are the titles and descriptions understandable? Can the user identify the correct option? Does the selected location actually meet their needs?
To answer these questions, we need two types of evidence.
Behavioral data can help us identify searches that return no results, repeated query modifications, quick returns from place-detail pages, and abandonment at different stages.
Alongside this data, we should interview target users and conduct usability tests to understand why these behaviors occur.
For example, if someone searches for the same thing three times in different languages, we shouldn't immediately conclude that the search engine is performing poorly.
The correct result might have been available from the beginning, but the user may have been unable to recognize it.
Behavioral data tells us where to investigate. Observation and user interviews help us understand the possible reasons.
What Solutions Could We Consider?
Once we understand the problem, several potential approaches become available.
Option 1: Translate the User Interface
We could display menus, categories, messages, and translatable information in the user's preferred language.
This could make the interface easier to understand, but it wouldn't necessarily solve the problem of matching search queries to local place names.
Option 2: Introduce Multilingual Search
We could allow users to describe their needs in their native language while the system retrieves relevant places, regardless of language differences.
For example, searching for the Persian word for "pharmacy" could return places categorized as pharmacies in Germany without requiring the user to know the German equivalent.
This could be implemented using category mappings, multilingual synonyms, and existing search engine capabilities.
Option 3: Make Search Results Easier to Understand
Alongside the original place name, we could display understandable information such as service type, location, distance, and opening hours.
Under this approach, we wouldn't necessarily translate every local place name.
In fact, preserving the original name is important because users may need to recognize it on a physical sign, ticket, or address.
Option 4: Let Users Search by Need Rather Than by Word
For frequently requested services, we could introduce simpler discovery paths.
For example, users could select a recognizable service category without knowing its name in the local language.
However, adding a few icons doesn't automatically solve every language-related usability problem.
Which Solution Should We Choose?
If I had to make a decision for an initial release, I wouldn't develop all these capabilities at once.
My recommendation would be to combine two limited improvements:
First, allow users to find essential service categories using queries in their own language. Second, present key information about each result in a way that helps users match it to the real-world location.
The main advantage is that we're targeting two meaningful points in the user journey without redesigning the entire product.
However, there are costs and risks.
Multilingual search may return irrelevant results. Automatic translation may misrepresent a place name or service category. Opening hours may also be incomplete or outdated.
For these reasons, I would preserve official place names, distinguish verified information from uncertain details, and allow users to view the original information when necessary.
Furthermore, if the data shows that users primarily struggle to understand results rather than retrieve them, I would prioritize result presentation over multilingual search.
Priorities should come from evidence, not from how technically impressive a feature sounds.
A Realistic Product Design Example
Let's consider a hypothetical scenario.
A Persian-speaking traveler in Berlin needs to find a pharmacy that's open when they plan to visit.
In the existing experience, their Persian query may return poor results, or the application may display German names and descriptions they cannot understand.
In the proposed experience, the user enters the equivalent of "open pharmacy near me" in Persian.
The system identifies the required service category and geographic context. It then displays relevant results with their original German names, understandable categories, distances, and available opening-hours information.
If the system cannot reliably determine whether a pharmacy is open, it shouldn't confidently claim that it is.
Before leaving, the user can review the location details. When they arrive, they can match the original place name to the physical sign.
This is a hypothetical design scenario, not a claim that a particular application has implemented these exact features.
The value of this design isn't the number of features it introduces. It's how effectively it reduces the gap between what users need and what they can successfully accomplish.
How Would We Measure Success?
One common mistake in product design interviews is proposing a solution without explaining how its success will be evaluated.
For this problem, simply increasing the number of searches would not be a meaningful success metric.
In fact, more searches could indicate that users are repeatedly trying and failing.
I would define three categories of metrics.
Outcome metric: The percentage of users who can independently identify the correct location for a predefined task.
Diagnostic metrics: Time required to find the correct result, number of query reformulations, and frequency of irrelevant-result selections.
Guardrail metrics: Incorrect-location selection rate, location-information errors, and cases where inaccurate translations or categories mislead users.
In a controlled usability test, we can compare user selections against a predefined correct answer.
However, in the live product, clicking the directions button or opening a place-detail page doesn't necessarily prove that the user reached the right destination.
We need to distinguish measurable behavior from actual task success.
Before running the experiment, we should document the baseline and decision criteria. This prevents us from selectively highlighting whichever metrics happen to improve afterward.
What If the Interviewer Gives You Only Two Weeks?
With a two-week deadline, I wouldn't attempt to build a complete multilingual translation and search system.
During the first few days, I would review existing data and test a handful of common tasks with target users.
Next, I would choose one major obstacle and build a limited prototype.
For example, we might introduce multilingual search for a small set of essential service categories in one city.
We would then compare task performance between the existing experience and the prototype.
If users can identify the correct locations more easily without increasing important error rates, we can plan a limited rollout and further real-world experimentation.
The goal of those two weeks isn't to deliver every feature.
It's to gather enough evidence to make a better product decision.
What Evidence Would Make Us Abandon Our Proposed Solution?
This is one of the most important follow-up questions in the interview.
If users still cannot identify the right result, multilingual search alone hasn't solved the problem.
If the main issue turns out to be inaccurate or missing place information, improving translation should no longer be our top priority.
If users can already accomplish their goals through existing visual categories, developing a more complex feature might not justify the investment.
And if incorrect search results become more common, we may need to modify or stop the experiment even if search completion time improves.
A product manager shouldn't simply look for evidence that confirms their original idea.
They should establish, from the beginning, what evidence would justify changing their decision.
How Should We Answer This in an Interview?
If I were answering this question naturally in a product management interview, I would say:
"Before proposing a solution, I'd want to understand whether users struggle to enter search queries, understand the results, or identify the correct real-world location.
For the initial scope, I'd focus on travelers who don't know the local language well and need to find essential services.
I'd analyze existing search behavior and observe a few target users to identify where the biggest difficulties occur.
If the main problem is finding and understanding relevant results, I'd initially test limited multilingual search alongside clearer result information, while preserving the original place names.
I'd measure success through correct-location selection, task completion time, and error rates.
If the results aren't positive or significant errors increase, I'd reconsider the solution."
Instead of listing features, this answer demonstrates a structured decision-making process.
What Makes an Interview Answer Weak?
Saying, "I'd make the whole application multilingual," without identifying where users struggle is not a complete answer.
Similarly, saying, "I'd use AI to translate everything," is more of a technical suggestion than a product decision unless we address accuracy, costs, local naming conventions, and potential errors.
An answer such as "I'd improve the experience for all users" also lacks meaningful prioritization.
The interviewer wants to understand whether we can make a defensible choice among competing problems and possible solutions.
Conclusion
To improve local search for users unfamiliar with the interface language, we first need to identify where the actual problem occurs: entering queries, retrieving results, understanding information, or selecting the correct location. We should then choose a limited, testable solution for a clearly defined user segment.
In this scenario, my recommended starting point would be multilingual search for essential services combined with understandable result information alongside original place names. I would choose this approach because it directly supports task completion and can be tested without redesigning the entire product.
However, this recommendation isn't absolute. If research shows that the main obstacle lies elsewhere, our priorities should change.
A strong product management interview answer isn't the one that proposes the most features. It's the one that clearly explains which problem we're solving, for whom, why we've chosen a particular approach, and what evidence would make us change our minds.
References
- Google Places Autocomplete Documentation — Language preferences, alternative names, and location restrictions:
https://developers.google.com/maps/documentation/places/web-service/place-autocomplete
- W3C — Writing for Web Accessibility:
https://www.w3.org/WAI/tips/writing/
- WCAG 2.2 — Understanding Language of Parts:
https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html
