13 min read

How Would You Design a Product for Users With Limited Access?

Day 1 of 1,000 Product Manager Interview Questions

PM_Day_0001_Website_1200x630.png

Imagine you're asked to redesign a navigation app for someone who doesn't have reliable internet access.

The user might lose their connection halfway through a journey, struggle to load a map, or be unable to find an alternative route.

Your first instinct might be to introduce offline functionality, reduce data consumption, or build a lighter version of the app.

But how do we know those are the right solutions?

Perhaps the user doesn't need a complete map at all. Maybe they only need directions for their daily commute. Or perhaps the real issue isn't connectivity but unfamiliarity with the interface or the cost of mobile data.

This is where the difference between designing a feature and solving an actual user problem becomes clear.

Today's interview question:

Choose a product you use every day. How would you redesign it for someone with limited access?

This is a product sense and product design question. It sounds straightforward, but a strong answer requires much more than creativity or a list of interesting features.

What Is the Interviewer Actually Evaluating?

The interviewer wants to understand whether you can turn a vague request into a specific, researchable, and solvable problem.

Several skills are being assessed simultaneously:

  • Can you clarify the user's problem and constraints before proposing solutions?
  • Can you identify and prioritize a specific user segment?
  • Can you distinguish actual user needs from your own assumptions?
  • Can you make trade-offs between serving more users and solving a narrower problem more effectively?
  • Can you propose a solution that can be tested with limited resources?
  • Do you understand what evidence might cause you to change your initial decision?

The interviewer isn't necessarily looking for the most innovative idea.

They're more interested in how you arrive at your recommendation and whether your reasoning holds up under scrutiny.

1. First, Define What Limited Access Actually Means

The phrase "limited access" doesn't tell us enough to start designing.

It could refer to someone with unreliable internet, an older smartphone, a visual or physical disability, limited familiarity with the product's language, or financial constraints.

These users don't necessarily experience the same problems, and their needs shouldn't be treated as interchangeable.

The first step is to clarify the scope of the problem.

For example, you might ask:

"Are we talking about limitations related to connectivity and devices, or physical and cognitive accessibility? And what specific task should the user be able to complete?"

If the interviewer doesn't provide further clarification, don't get stuck.

Choose a reasonable assumption and communicate it clearly.

For this example, let's assume our target users experience unreliable mobile internet connectivity, and we're trying to improve their experience with a navigation application.

This assumption defines the scope of our answer. It doesn't mean we're claiming to represent everyone with limited access.

2. Choose a Specific User Segment Instead of Designing for Everyone

Now we need to decide exactly who we're designing for.

A navigation application could serve commuters, delivery drivers, tourists, residents of areas with poor network coverage, or people who rely on public transportation.

Each group has different needs.

Hypothetical example:

Consider someone who takes the bus to work every day.

Their mobile internet is limited and unreliable. They usually follow a familiar route, but occasionally need to check their stops or review the remaining journey.

This person doesn't necessarily need every feature of a sophisticated navigation application.

Their primary need is to access a previously prepared route and its essential information when their internet connection disappears, while understanding which details can still be trusted.

Why would we prioritize this segment?

Because the problem occurs during a recurring activity, the context of use can be observed, and task success can be evaluated through a relatively focused experiment.

Of course, this choice is still a hypothesis.

We would need research to determine whether the problem is genuinely frequent and important enough to justify solving.

Selecting a specific segment doesn't mean ignoring everyone else.

It means choosing a problem we can understand deeply before deciding whether and how to expand the solution.

3. Understand Current User Behavior Before Designing Anything

One of the most common product design mistakes is jumping straight into screens and features after identifying a target audience.

But at this point, we still don't know how users currently solve their problems.

Maybe they take screenshots of directions before leaving home.

Maybe they save addresses in a messaging app, ask other people for directions, or avoid unfamiliar routes because they can't depend on connectivity.

These workarounds are valuable research signals.

I'd initially investigate three areas.

Problem severity: What happens when the connection drops? Does the user experience a minor inconvenience, or do they risk getting lost?

Problem frequency: How often does this happen, and at which stages of the journey?

Existing alternatives: What does the user do today, and why aren't those methods sufficient?

To answer these questions, we could interview people in our target segment, observe how they complete real journeys, and examine product analytics related to poor network conditions if such data is available.

However, analytics alone wouldn't tell the whole story.

A failed map request tells us that something didn't load. It doesn't necessarily tell us whether the user ultimately found their way.

Similarly, relying exclusively on interviews would be insufficient.

Observing people in realistic situations can reveal difficulties they might not remember or mention during an interview.

4. Compare Your Options Before Choosing a Solution

Once we've established a working understanding of the problem, several design approaches become possible.

Option 1: Build a lighter version of the product

Reduce data consumption and remove nonessential functionality.

This might improve performance on slow connections, but it may not help when connectivity disappears completely.

Option 2: Allow users to download geographic areas

Users could download maps of selected locations in advance.

This provides broader flexibility, but it can require significant storage. Users may also struggle to determine which geographic area they need to download.

Option 3: Let users save frequently used routes

Users could prepare their most important routes while connected and access essential information later without an internet connection.

For our selected user segment, I would initially prioritize the third option.

Why?

Because we're not trying to help someone navigate every possible route.

We're trying to help them complete a recurring, clearly defined task under unreliable connectivity conditions.

Instead of building a complete offline navigation system, we would focus on reliable access to a small number of important routes.

That decision has a cost.

People who frequently change destinations may receive less value from the initial version.

Recognizing and accepting this trade-off is part of making a deliberate product decision.

5. What Would the Minimum Viable Product Look Like?

We don't need a long feature list to get started.

An initial version could allow users to save a specific route while connected to the internet and retrieve its essential information later without connectivity.

For example, the experience could include:

  • Access to the saved route and important points along it.
  • Clear information about how much data needs to be downloaded.
  • A visible timestamp showing when the information was last updated.
  • Explicit warnings when real-time information, such as traffic conditions or bus arrival times, is unavailable.
  • A simple way to retrieve saved routes without searching again.

One important technical distinction matters here:

Downloading a map doesn't automatically mean every navigation feature will work offline.

Google Maps, for example, allows users to download maps for offline use. However, Google's official documentation explains that offline walking, cycling, and public transportation directions are unavailable, and real-time traffic information is not provided.

So our hypothetical product should not promise a complete, up-to-date offline navigation experience simply because some map data is stored locally.

If we cannot verify a bus route change or an updated timetable, we need to communicate that limitation clearly.

Sometimes being transparent about what a product cannot do is more valuable than introducing another attractive feature.

6. How Would We Measure Success?

Success should not be measured solely by the number of downloaded routes or how frequently users open the feature.

People might save dozens of routes but still struggle when their internet connection drops.

Our measurement approach should focus on whether the user can accomplish the intended task.

Primary success metric

The percentage of users who can successfully retrieve a previously prepared route and read its essential information under offline conditions.

We could measure this through controlled usability testing.

However, completing this task in a test would not, by itself, prove that users can successfully reach their destinations in real-world conditions.

Diagnostic metrics

These might include the time required to retrieve a route, the number of unsuccessful attempts, and how often users need assistance.

Guardrail metrics

We should also track data and storage consumption, information errors, confusion about data freshness, and situations where outdated information causes incorrect decisions.

Why are guardrail metrics important?

Because improving offline accessibility could introduce another problem: users might place too much trust in outdated directions.

In that situation, higher engagement wouldn't necessarily indicate a better product.

Before conducting the experiment, we should define what improvement would count as success, which risks are unacceptable, and which outcomes would require us to revisit the solution.

7. What If You Only Had Two Weeks?

This is one of the important follow-up questions in the original interview exercise.

A strong answer isn't to promise a fully developed offline navigation system within two weeks.

The objective should be to reduce uncertainty.

During the first few days, I would speak with users in the selected segment and investigate how they navigate under poor connectivity conditions.

We need to establish whether the problem occurs regularly, what consequences it creates, and why existing workarounds are insufficient.

Next, I would develop a prototype that simulates saving and retrieving a route.

Then I'd ask participants to complete specific tasks without internet access.

By the end of the two weeks, we should have evidence to address several questions.

Do users genuinely need this functionality? Can they use it without guidance? Is the available information sufficient for their decisions? Does uncertainty about outdated information create unacceptable risks?

If the results are promising, we can decide whether to invest in building the functionality.

If they aren't, we should adjust the hypothesis before spending more resources.

8. What Evidence Would Make You Reject Your Proposed Solution?

A product manager shouldn't become so attached to an initial idea that contradictory evidence gets ignored.

Suppose research shows that users rarely struggle with familiar routes.

Instead, their biggest difficulty occurs when plans change unexpectedly and they need real-time alternative directions.

In that case, saving frequently used routes might not address the most important problem.

Alternatively, we might discover that users already have access to offline route information but struggle to interpret it.

Or perhaps similar functionality already exists in the product, but people cannot find it.

Under those circumstances, improving the discoverability of an existing feature could be more valuable than developing something new.

Another reason to reconsider the solution would be evidence that route information changes too frequently for offline copies to remain trustworthy.

The important point is to define what could invalidate our original hypothesis.

Being willing to revise a decision doesn't demonstrate indecisiveness.

It demonstrates that the decision is grounded in evidence rather than personal attachment to an idea.

9. How Would I Answer This in a Real Interview?

If I were answering this question in an interview, I would say something along these lines:

"First, I'd clarify what limited access means because connectivity issues, physical accessibility, and financial constraints create different product problems.

For this example, I'll assume the user has unreliable internet access, and I'll choose a navigation application as the product.

I'd initially focus on people who regularly travel along familiar routes.

Before proposing anything, I'd investigate where connectivity problems interrupt their journey and how they currently work around those interruptions.

Then I'd compare several approaches, including a lighter application, downloadable maps, and saved frequently used routes.

My initial recommendation would be to let users save essential routes.

Given our assumptions, this seems like a focused problem we could test without immediately building a complete offline navigation system.

I'd measure whether users can successfully retrieve the information they need without internet access, rather than simply counting how often they use the feature.

I'd also monitor data consumption, errors, and the risk of users relying on outdated information.

If research showed that the underlying problem was different from our assumptions, I'd change the proposed solution.

I'd rather discover that our hypothesis is wrong early than build the wrong product extremely well."

This answer is neither excessively vague nor unnecessarily technical.

More importantly, it includes a clear decision and explains the reasoning behind it.

10. What Makes an Interview Answer Weak?

"I'd build a simpler version for everyone."

Simpler doesn't automatically mean more accessible.

Without understanding the specific limitation and the user's primary task, we might remove functionality that people actually need.

"I'd make every feature available offline."

This ignores development costs, technical complexity, storage requirements, and the challenge of keeping information current.

"I'd use AI to make the experience smarter."

Until we've defined the underlying problem, introducing another technology doesn't explain how the user's experience would improve.

"We'd know it worked if users were satisfied."

Satisfaction matters, but we also need to understand what users successfully accomplished and whether the product introduced unintended negative consequences.

"I'd design for every type of limited access from the beginning."

Inclusive design is important, but it doesn't mean assuming that everyone has identical needs.

We can start by understanding one specific limitation deeply and then explore how the resulting solution might benefit a wider group.

This also aligns with an important principle in Microsoft's Inclusive Design approach: solve for one, extend to many.

Conclusion

Designing a product for users with limited access should begin with understanding the limitation, the target user, and the task that has become difficult to complete.

Only then should we investigate existing behavior, compare possible solutions, and select the smallest meaningful intervention we can test.

In our navigation example, we initially chose saved essential routes because we assumed unreliable connectivity and recurring journeys were the central problem. That decision provides a focused and relatively inexpensive opportunity to learn. It doesn't mean the same solution would be appropriate for every user.

If research revealed that users primarily needed real-time route changes, or that stored information could not remain sufficiently reliable, we would need to reconsider the recommendation.

What separates a strong product management candidate from an average one isn't the number of ideas they generate. It's their ability to define the problem, make deliberate trade-offs, explain the reasoning behind a decision, and identify the evidence that would justify changing it.

References

Moein Ghezelbash Technical product management and digital platforms
More writing Browse all articles