How Would You Improve Local Search for Someone Who Struggles with the Interface Language?

Imagine a traveller arriving in an unfamiliar city and searching for a grocery shop. The app finds several nearby places, but the traveller cannot confidently understand the interface, compare the results or work out how to reach the right one.

Technically, the search has returned results. But has the product actually succeeded?

That distinction sits at the heart of the second question in this Product Manager interview series.

What is the interviewer really asking?

The interview question is:

How would you improve the local search experience for someone who does not understand the interface language well?

This is a product sense and user experience design question. However, the interviewer is not simply looking for suggestions such as translating buttons, adding country flags or redesigning the search screen.

They want to understand whether you can:

• Separate the user's actual difficulty from an immediately obvious solution.
• Identify a specific group of users worth focusing on first.
• Consider linguistic, behavioural and technical constraints.
• Evaluate credible alternatives and acknowledge their trade-offs.
• Measure success through observable user behaviour.
• Explain what evidence would make you reconsider your recommendation.

A strong answer demonstrates that you understand the problem before deciding what to build.

Define the problem before designing the solution

Saying that someone struggles with the application's language does not tell us precisely where the experience breaks down.

A user might enter a query in their preferred language, only to receive irrelevant results. Another may find relevant places but struggle to understand their names, categories or descriptions. A third might identify the correct destination but be unable to interpret its opening hours or navigation options.

These are different problems, and they may require different solutions.

I would begin with several questions:

1. Who are the users? Tourists, migrants, multilingual residents or another group?
2. Does the difficulty occur when entering a query, interpreting results or choosing a destination?
3. Is the problem the application's language, the destination's local language or both?
4. What constitutes a successful search: obtaining results, selecting a suitable place or reaching it?
5. What constraints exist around supported languages, place-data quality, development capacity and external service costs?

If the interviewer cannot provide further details, I would make my assumptions explicit rather than pretending the missing information is known.

My starting assumption: We are designing for travellers who have limited understanding of both the application's interface language and the destination's local language, but who can search in their own language. Their primary goal is to discover a suitable local service and begin navigating towards it.

This gives us a manageable starting point. We do not need to redesign the entire product for every language and every user.

Language is only one part of the journey

Local search involves several connected decisions.

The user expresses a need, evaluates possible results, chooses a destination and takes action to reach it.

If any stage is difficult to understand, the journey may stop.

For instance, translating the phrase “grocery shop” into the local language could help the search engine recognise the query. But if the resulting list contains unfamiliar names, lengthy addresses and unclear opening information, the essential problem remains.

Equally, translating everything is not necessarily desirable. Official place and street names must remain recognisable when users navigate the physical world.

The real objective is therefore not to maximise translation, but to minimise the language knowledge required to complete the task.

That distinction should shape our design decisions.

Evaluate three credible approaches

Option 1: Translate the entire interface

We could localise the complete application, covering menus, filters, search tools and place details.

For a product serving substantial multilingual markets, this may be a valuable long-term investment. It could improve much more than the search experience.

However, comprehensive localisation creates ongoing translation, maintenance and quality assurance costs, particularly when place information comes from multiple external sources.

Translating proper names, incomplete descriptions or location-sensitive information may also introduce misleading interpretations.

Crucially, a translated interface does not automatically mean the search engine can interpret queries entered in that language.

Full localisation may belong on the longer-term roadmap, but it is not necessarily the most efficient way to test the immediate problem.

Option 2: Support multilingual search and understandable results

This approach concentrates on the core search journey.

We would aim to let users:

• Enter queries in their preferred language.
• Find places through relevant local synonyms and different written forms, where supported.
• Understand essential place categories and information in their chosen language.
• See original place names alongside translated or transliterated equivalents.
• Use complementary visual cues to understand place type, distance, opening information and possible next actions.
• Change their language preference without unnecessarily losing their search progress.

This addresses the task users are trying to complete rather than attempting to translate every part of the product.

Google's official Places documentation provides a useful technical reference: preferred language settings can affect how information is displayed and how some search terms are interpreted. Nevertheless, this does not guarantee equally accurate multilingual search across all languages or places.

Coverage, query matching and the quality of available place information would still need to be tested.

Option 3: Rely more heavily on icons and visual cues

Another suggestion might be to replace much of the language-dependent experience with pictures and symbols.

Visual cues can certainly help. However, icons are not universally understood, and the same symbol can convey different meanings to different people.

They also cannot reliably communicate every important detail about a destination.

I would therefore use visual cues alongside understandable labels and essential information, rather than treating them as a complete replacement for language.

My initial recommendation is Option 2, supported by carefully selected elements of Option 3.

It offers a more focused opportunity to test whether we can improve task completion without committing immediately to full-product localisation.

That choice would change if research showed that users struggle throughout the entire interface rather than primarily within search.

What evidence would support this decision?

Before building anything substantial, I would investigate how people currently work around the language barrier.

Perhaps they translate their queries using another application and copy them back into the search field. They might ask another person for help, or identify shops through photographs and visible landmarks.

These workarounds reveal opportunities to reduce friction.

I would combine a small number of contextual interviews and usability observations with relevant product analytics. Participants could be asked to find an open grocery shop nearby, without help.

The research would examine:

• Whether users receive relevant results.
• Whether they can distinguish between similar options.
• Where they abandon the journey.
• Whether they rely on an external translation tool.
• Whether translated information ever leads to an incorrect decision.

I would not rely solely on search volume or click-through rate.

An increase in search activity could mean that users are repeatedly trying to correct unsuccessful searches. More searches do not necessarily indicate a better experience.

A hypothetical software-product scenario

Consider a hypothetical local discovery application whose content is predominantly in German.

Some Persian-speaking visitors to Vienna use the app to find nearby grocery shops.

In this hypothetical scenario, preliminary observations suggest that certain users enter Persian search terms, receive unsatisfactory results and switch to an external translation tool.

The product team has three proposals: localise the entire application, improve Persian-language search for selected categories, or build a largely visual discovery experience.

As Product Manager, I would recommend testing Persian-language query support and understandable results for one category, such as grocery shops.

The product designer would investigate which details users need to make a confident choice. Engineers would assess whether Persian queries can be reliably matched against the available place data, including constraints imposed by the search provider. Customer support could contribute common examples of unsuccessful searches and confusing results.

An initial version might provide:

• Persian-language queries matched to appropriate local place categories.
• Original place names accompanied by understandable category descriptions.
• Clear opening hours, distance information and navigation actions.
• An accessible language preference with an easy way to revert to the original display.
• Appropriate warnings where translations or place information may be unreliable.

We would not replace official street names with translations alone. The traveller may need to recognise the original name on a physical sign or when asking somebody for directions.

Nor would we infer a person's language proficiency solely from their nationality or current location. Users should retain control over their preferred language, with an opportunity to correct any preference derived from their device settings.

How would we measure success?

We should agree on both desired improvements and unacceptable consequences before running the experiment.

The primary outcome is a behavioural proxy, not proof that the user actually reached the destination.

To validate it, we would also use task-based research to assess whether participants selected the correct place and completed the task independently.

The metric's denominator needs to be explicit: all eligible search sessions within the experiment, not merely sessions in which the new feature was used.

We would compare results against an established baseline, examine performance by language and user segment, and agree on an observation window and decision criteria beforehand.

If users make choices more quickly but select incorrect destinations more frequently, the change cannot reasonably be considered successful.

What if you only had two weeks?

This is one of the two follow-up questions included in the source material.

With only two weeks available, attempting comprehensive multilingual localisation would be difficult to justify.

I would approach the time constraint as follows.

First few days: Define the target segment, select the main task and identify the most likely point of failure. Review existing evidence and observe a small number of users completing the task.

Middle of the period: Develop a limited prototype of multilingual query matching and understandable results. Start with controlled categories and existing technical capabilities wherever possible.

Final days: Test the prototype with representative users, assess task completion and errors, and decide whether to proceed, revise the approach or stop.

This is an illustrative delivery plan rather than a commitment that could be guaranteed without knowing the team or its infrastructure.

The purpose of the two weeks would not be to establish large-scale commercial success. It would be to reduce the most important uncertainty with credible early evidence.

What evidence would make you reject your solution?

This is the second follow-up question from the original source, and it tests an important part of product judgement.

A Product Manager should be able to defend a choice without becoming attached to it.

I would reconsider the proposal if testing revealed that users still received irrelevant results, translations increased confusion or the main obstacle was unrelated to language.

For example, users might understand the results perfectly well but discover that opening hours are outdated or locations are incorrectly recorded.

In that situation, introducing more languages would not solve the underlying problem. Improving place-data quality should take priority.

Equally, if users experience language barriers throughout the application, a search-only improvement may be insufficient. Broader localisation would become more justifiable.

A sound product decision should specify the conditions under which it needs to change.

What is the Product Manager's responsibility?

The Product Manager helps determine which problem deserves attention, which users to prioritise, which outcome matters and whether the proposed investment is worthwhile.

The work is inherently collaborative.

Product designers investigate behaviour and usability. Engineers assess technical feasibility, search quality and the implementation approach. If a Project Manager is involved, they may coordinate delivery against agreed schedules, resources and dependencies.

Within Scrum, the Product Owner is accountable for maximising product value and effective Product Backlog management, as described in the Scrum Guide.

Organisational responsibilities vary and may overlap, but deciding whether a solution creates value is not the same as simply delivering a feature on schedule.

A natural interview answer

A candidate could give a response along these lines:

“Before suggesting changes, I'd want to understand where users are actually struggling. Is it entering the query, interpreting search results or choosing the right destination?

“If we assume we're focusing on travellers who don't understand the app's language or the local language particularly well, I'd start with one common task, such as finding a nearby grocery shop.

“I'd look at how people currently work around the problem, then compare full localisation with improving the core search journey. My initial preference would probably be the second option: let people search in their own language, make the essential results understandable and preserve original place names.

“I'd test a small version and see whether people can choose suitable places more quickly and accurately. I'd also monitor translation errors and incorrect destination choices, because reducing effort at the expense of accuracy wouldn't be a good result.

“If the evidence showed that the real issue was poor place data, or that language difficulties affected the entire product, I'd revise the approach. For me, success means helping people complete their task, not simply increasing the number of supported languages.”

This answer covers the problem, assumptions, choice, measurement and conditions for reconsideration without descending into an unstructured feature list.

Common mistakes and weak interview answers

“I'd translate the app into every language.”

This overlooks segmentation, costs, priorities and the connection between translation and actual search success.

“I'd replace the text with icons.”

Visual cues can help, but they cannot convey all essential information without ambiguity.

“If people search more often, we've succeeded.”

Search volume measures activity, not necessarily success. Repeated searches might indicate that users cannot find what they need.

“I'm certain this solution will work.”

Without testing or evidence, that degree of confidence is unjustified. A stronger answer explains what remains unknown and how those uncertainties will be resolved.

Conclusion

Improving local search for users unfamiliar with the interface language does not necessarily require translating the entire product.

The starting point should be identifying where the user's journey breaks down, selecting a specific group and designing around an observable task.

My initial recommendation is a focused multilingual search experience that offers understandable results, preserves original place names and uses visual cues where they genuinely help. It should be tested on a limited scale before wider investment.

If evidence reveals a different underlying obstacle or unacceptable new errors, the recommendation should change.

Good Product Management removes the obstacles between users and their goals. It does not simply add more features.

Sources

1. Google Maps Platform – Text Search (New)
2. Google Maps Platform – Place Autocomplete (New)
3. W3C WAI – Understanding Labels or Instructions
4. W3C WAI – Understanding Language of Page
5. The Scrum Guide