Imagine a wheelchair user booking a property advertised as having step-free access. When they arrive, they discover that the bedroom doorway is too narrow for their wheelchair. The search worked, the payment went through, and the reservation was confirmed. Yet the product failed at the point that mattered most.
This is a hypothetical scenario, but it illustrates a genuine product design challenge: finding accommodation with accessibility features is not necessarily the same as finding accommodation that meets a particular guest's needs.
The ninth question in our series of 1,000 Product Manager interview questions asks:
"Design an Airbnb booking experience for a guest with mobility needs."
This is not simply an exercise in improving a search interface or adding a few filters. The interviewer wants to understand whether you can identify a genuine user problem, prioritise different needs, propose a testable solution and establish meaningful measures of success.
The reference question is presented as a contextual Airbnb product design exercise based on unofficial interview-related material. It should not be treated as a verified question from an official Airbnb interview.
Define the problem before designing the solution
One of the easiest mistakes is to assume that everyone with mobility needs requires the same accommodation features.
Someone using a manual wheelchair may need doorways of a particular width. Someone using a walking frame might be more concerned about steps and uneven surfaces. Another traveller may be able to negotiate a few stairs but require grab rails in the bathroom.
Before discussing features, I would clarify several things:
- Which group of guests are we prioritising?
- Where do they experience the greatest difficulty between searching and arriving?
- What information is essential to their booking decision?
- What constraints exist around development time, listing data and host participation?
For this exercise, I would make one explicit assumption:
Our initial target user is a guest who uses a wheelchair, wants to travel independently, and needs to establish whether the entrance, bedroom and bathroom are suitable before committing to a booking.
That does not mean all wheelchair users have identical requirements. Wheelchair dimensions, transfer abilities and the need for assistance or equipment can vary considerably.
I would frame the product objective as follows:
Help guests discover, assess and book accommodation that meets their essential mobility requirements, without unnecessary exchanges with multiple hosts or disclosure of irrelevant personal information.
This is more useful than simply aiming to increase bookings because it incorporates the quality of the booking decision.
Understand what Airbnb already provides
A strong interview answer should demonstrate awareness of the existing product rather than presenting established functionality as an original invention.
Airbnb already offers accessibility search filters. Guests can search for properties with features such as step-free entrances, wider doorways, step-free bedroom access, bathroom grab rails and step-free showers.
Airbnb also states that it reviews accessibility features submitted by accommodation hosts, using photographs, and allows guests to contact hosts for further clarification.
Therefore, simply suggesting an accessibility filter would contribute relatively little to the current experience.
The more useful question is:
Does the existing experience give guests enough reliable information to determine whether accommodation meets their specific requirements?
Answering that requires evidence from users, an assessment of listing information and an understanding of behaviour throughout the booking journey.
We should not assume that Airbnb's current experience is failing, or that our proposed redesign would improve it, without testing those assumptions.
A structured approach to the booking experience
1. Separate essential requirements from preferences
In a conventional accommodation search, a balcony, attractive view or proximity to the city centre may be a preference.
For a wheelchair user, however, the ability to pass through the entrance doorway may be an absolute requirement.
This distinction should influence the search and matching experience.
I would divide the guest's stated needs into two groups.
Essential requirements: Features whose absence would make the accommodation unsuitable, such as step-free access to the bedroom.
Preferences: Desirable features that the guest might compromise on, such as proximity to a particular attraction.
The guest should decide which requirements are essential. The platform should not assume that using a wheelchair automatically implies an identical set of requirements for everyone.
Each feature also needs a clear information status: supported by available evidence, confirmed absent, or insufficiently documented.
Unknown information must not be presented as evidence that a property is suitable.
2. Create trustworthy matching rather than more filters
We could add increasingly detailed search filters, but increasing their number does not automatically make a booking decision easier.
My initial proposal would be an optional search journey in which guests identify their essential requirements.
The product would then present properties according to their documented compatibility with those requirements.
For each result, guests should be able to see which requirements are supported by available evidence and which still require clarification.
For example, a property might have a documented step-free entrance but no information about the bathroom doorway width.
That property should not be presented as a fully suitable match without explaining the missing information.
There is an important trade-off here.
Strict matching could substantially reduce the number of visible properties, particularly in destinations where hosts have provided little structured accessibility information.
To address this, the product could allow guests to choose whether to see properties with incomplete information, explore alternative dates or areas, and ask hosts targeted questions.
The crucial principle is that the system should never silently compromise an essential requirement merely to display more results.
3. Explain the journey through the property
The presence of an accessibility feature does not establish that an entire property is suitable.
A building may have a step-free entrance but stairs leading to the bedroom. A bathroom doorway may be wide enough while the available turning space remains unsuitable for a particular wheelchair.
The property details page therefore needs to support assessment of the guest's actual movement through the accommodation.
That might mean understanding the route from the entrance to the bedroom, from the bedroom to the bathroom, and between other essential areas.
Useful information could include doorway measurements, steps, lift availability and clear photographs of relevant routes, provided these details are available and trustworthy.
Airbnb's official photography guidance already recommends showing doorway measurements, photographing accessibility features from several angles and identifying which rooms provide particular features.
An incremental product improvement would be to make the evidence and verification status of each feature clearer.
For instance, guests could distinguish between information supported by reviewed photographs and information that remains incomplete.
Such transparency should not be confused with a universal guarantee of suitability. The guest must still be able to judge the information against their own requirements.
4. Resolve critical uncertainty before payment
One of the highest-risk moments occurs when a guest books accommodation despite unresolved questions about an essential requirement.
I would explore a lightweight pre-booking review showing the requirements the guest has selected.
Where sufficient information exists, the guest can proceed with a clearer understanding of the property.
Where important details are missing, the product should identify the uncertainty and provide a direct way to ask the host.
Instead of a generic instruction to contact the host, the platform could suggest a relevant question:
"What is the clear width of the bathroom doorway when fully open?"
A host's answer should not automatically become a definitive accessibility guarantee without appropriate supporting evidence.
Guests should also have clear access to relevant support arrangements and applicable cancellation policies.
We should not promise special refunds, accommodation guarantees or assistance that the business and its operating policies cannot actually provide.
5. Make the booking interface accessible too
So far, the focus has been on the physical characteristics of accommodation.
However, the digital booking journey must also support accessible interaction.
Guests should be able to navigate filters using a keyboard, select options, understand their states and complete payment without unnecessary barriers.
Form controls need understandable labels. Errors should be described clearly rather than communicated through colour alone.
The W3C's Web Content Accessibility Guidelines, particularly WCAG 2.2, provide an appropriate foundation for assessing these interactions.
However, digital accessibility and physical accommodation suitability are different requirements.
The booking product needs to be usable, while also giving guests trustworthy information about the property they intend to book.
Which solution should we prioritise?
An interview might produce several plausible proposals.
Option one: Add more filters and accessibility badges. This could be relatively straightforward to implement in some areas and make properties easier to discover. However, if the information is incomplete or inaccurate, it may increase perceived confidence without improving actual suitability.
Option two: Build a comprehensive personalised accessibility experience. This could support a wider range of requirements but would depend on substantial structured data, host participation, more complex interactions and ongoing maintenance.
Option three: Incrementally improve matching against documented essential requirements. Begin with a limited set of important requirements, expose information gaps and make clarification easier before booking.
I would prioritise the third option.
Not because it necessarily offers the most comprehensive experience, but because it allows us to test meaningful improvements within a manageable scope.
We can learn about data quality, guest confidence and practical constraints before investing in a much larger solution.
However, if research reveals that the main problem is a shortage of suitable accommodation rather than difficulty assessing existing properties, the priority should shift towards improving supply coverage and listing information.
That is why understanding the problem matters more than becoming attached to the initial solution.
A practical software product example
Hypothetical scenario
Imagine a booking platform similar to Airbnb.
Its product team observes that some guests who use accessibility filters repeatedly open property details but do not complete a booking.
This behaviour alone does not prove that the problem is insufficient trust.
The properties might be too expensive, unsuitable accommodation might be unavailable, or guests might simply be comparing options.
The Product Manager works with a user researcher to interview travellers and evaluate the quality of existing property information.
Suppose this research suggests that uncertainty about the route from the entrance to the bathroom is a recurring concern.
The team considers two approaches:
- Introduce a general "wheelchair-friendly" badge.
- Display separate information about access to the entrance, bedroom and bathroom, supported by photographs and clear indications of missing details.
The second approach becomes the initial recommendation because it provides information that guests can assess against their own requirements rather than relying on a broad label.
The product designer develops a prototype. Engineers assess the available data and implementation constraints. Operations and support teams investigate how hosts could supply or correct information.
The Product Manager defines the experiment and success criteria.
The team then conducts a limited test using listings with reviewed accessibility information.
If guests can make more accurate suitability judgements without significant new errors or confusion, expanding the approach becomes more defensible.
But if guests still need repeated conversations with hosts to establish basic requirements, the redesign has not adequately solved the original problem.
This is an illustrative scenario, not evidence of an actual Airbnb experiment or business result.
How should success be measured?
Booking conversion matters, but it cannot be the only success measure.
A redesign could increase bookings while also increasing the number of guests who discover, upon arrival, that accommodation does not meet their requirements.
I would therefore define three levels of measurement.
1. Primary outcome metric
The proportion of bookings where the guest's stated essential requirements are actually met on arrival.
We could investigate this through optional post-arrival feedback and recorded accessibility-related problems.
The denominator must be explicit, such as bookings in the pilot with a valid post-arrival assessment.
We would also need to acknowledge the risk of response bias: guests who provide feedback may differ from those who do not.
2. Diagnostic metrics
These could include the rate at which guests find at least one property matching their essential requirements, the time required to assess suitability, the number of unresolved essential questions before booking, and booking completion after accessibility requirements have been selected.
We should examine both individual funnel stages and the full population of eligible accessibility searches.
Otherwise, a shortage of suitable properties could be concealed by an apparently healthy conversion rate among the small number of guests who find a match.
3. Guardrail metrics
These would include cancellations and complaints caused by accessibility discrepancies, false-positive suitability matches, additional host support workload and unintended effects on other guests.
The measurement window should be established before the experiment.
Initial usability tests and data-quality assessments would be followed by a limited live pilot that also captures post-arrival outcomes.
An improvement in clicks or initial bookings would not be sufficient evidence of success.
Risks and implementation considerations
The greatest risk is creating false confidence.
A broad label such as "wheelchair-friendly" may suggest suitability even when important requirements have not been established.
The second risk is incomplete property information.
Requiring extensive structured data from every host could create a significant operational burden and delay improvements.
The third risk concerns privacy.
Guests should not have to disclose medical diagnoses or sensitive personal details to identify the accommodation features they need.
Requirements should be selected voluntarily, and the platform should avoid collecting unnecessary information.
Hosts should provide accurate information about the property rather than decide whether a particular person is capable of staying there.
Within the delivery team, the Product Manager is responsible for defining the outcome, prioritising the opportunity and assessing the result.
Researchers, designers, engineers, operations and support colleagues contribute to understanding user needs, implementing the experience and ensuring that the information can be trusted.
A natural interview answer
Illustrative candidate response:
"I'd start by clarifying what we mean by mobility needs, because someone using a wheelchair may have very different requirements from someone using a walking frame.
"For the purpose of this question, I'd focus initially on wheelchair users who need to establish whether the entrance, bedroom and bathroom are suitable before booking.
"I'd review Airbnb's existing accessibility features and look at how guests use them. I'd also speak with travellers to understand whether the main difficulty is finding suitable accommodation, understanding the information or feeling confident enough to book.
"Rather than immediately adding more filters, I'd explore separating essential requirements from preferences and showing clearly how each property matches those requirements.
"I'd test a prototype using listings with reliable accessibility information.
"My main measure of success wouldn't simply be booking conversion. I'd want to know whether guests successfully booked accommodation that actually met their essential requirements when they arrived.
"And if the evidence showed that the real constraint was insufficient suitable inventory or unreliable host information, I'd change the priority towards improving supply and data quality rather than making the interface more complicated."
Interview follow-up questions
What would you do if you had only two weeks to investigate?
This question appears in the original reference and tests whether the candidate can narrow the problem and select an efficient learning approach.
Two weeks would not be enough to build a comprehensive accessibility platform.
I would begin by selecting a specific user group and speaking with travellers about their current booking journeys.
I would observe how they search for properties and assess a sample of listings for completeness and clarity of information.
The team would then create a simple prototype showing essential requirements and matching status, followed by usability testing with relevant users.
By the end of the two weeks, we should understand which uncertainty is most consequential, whether our proposed presentation improves comprehension and what the largest implementation constraint is.
The objective would be an evidence-based decision about the next experiment, not a claim that the entire problem had been solved.
What evidence would make you reject your proposed solution?
This is the second follow-up question in the reference material.
If research showed that guests already understand the accessibility information but cannot find suitable accommodation at an acceptable price or location, improving presentation would probably not be the highest priority.
If host information proved too incomplete or unreliable, a matching system could produce misleading results.
Likewise, if usability testing revealed that guests misunderstood verification status, or post-stay evidence showed an increase in accessibility discrepancies, we would need to redesign or stop the experiment.
A Product Manager should be committed to the user outcome, not to defending their first proposed solution.
What if the redesign reduces bookings?
This is an additional suggested practice question, rather than one of the two follow-ups in the original reference.
I would first investigate why bookings had declined.
If better information helped guests avoid properties that did not meet essential requirements, lower conversion might represent a better quality decision rather than a product failure.
However, if the redesign introduced unnecessary complexity or incorrectly excluded suitable properties, we would need to correct it.
The decision should consider successful stays, guest satisfaction, support costs and longer-term business outcomes, rather than conversion in isolation.
Weak answers and common mistakes
Saying "I'd add a disability filter" is too broad. It does not specify an actual need and overlooks functionality Airbnb already provides.
Suggesting "I'd put all accessible properties at the top of search results" is equally problematic without defining accessibility. A property may suit one person while being unsuitable for another.
Proposing that artificial intelligence should determine wheelchair suitability from photographs is also difficult to defend without evidence of accuracy and careful evaluation of errors.
Automated image analysis might help identify potential features, but an unverified inference should not be treated as a definitive assurance to the guest.
Finally, evaluating success purely through booking conversion overlooks what happens when the guest arrives.
The interviewer is ultimately assessing the quality of your problem framing, prioritisation and decision-making, not the number of features you can suggest.
Conclusion
To design a better Airbnb booking experience for guests with mobility needs, I would not begin by adding more filters. I would select a clearly defined user group, understand their essential requirements and investigate where the existing booking journey leaves them without sufficient information or confidence.
My initial recommendation would be transparent matching between essential user requirements and documented property features, with clear disclosure of uncertainty and a simpler way to resolve critical questions before payment. This should be tested with relevant users and trustworthy listing information, and evaluated against real accommodation outcomes.
If evidence showed that the dominant problem was insufficient suitable inventory, unreliable host data or unnecessary complexity in our proposed experience, I would revise the approach. The aim is not merely to make booking easier. It is to help guests make informed, reliable decisions about accommodation that genuinely suits their needs.
