What Great UX Research Looks Like for B2B Products — And Why Hospitality Tech Gets It Wrong

‍

UX research for hospitality tech is the structured practice of learning what hotel operators, restaurant managers, and venue staff actually need from software, before, not after, building it.

For B2B product teams in the hospitality space, this means talking to the people who will use the system at 7am during a breakfast rush, not just the procurement director who signed the contract.

Most hospitality tech products are not failing because of bad engineering.

‍

They are failing because the product team has never properly watched a front desk manager use their system under real operating conditions. Features get built based on what founders assume operators need, what competitors already ship, and what sounds good in a sales demo. The people actually running the venues, the ones whose workflows the software is supposed to support, are consulted last, if at all.

‍

This post covers what a proper B2B UX research process looks like, why hospitality tech specifically gets it wrong, and what changes when research is done correctly. It is written for product teams and founders building software for the hospitality industry, and for operators who have wondered why the tools they are sold rarely match the realities of running a venue.

‍

The common mistake — building features instead of solving problems

‍

The default mode for most hospitality tech product teams is reactive feature development. A large client requests something specific. A competitor ships something new. A sales team reports an objection. The roadmap fills up with responses to these signals, and the team ships, fast, visible, measurable.

‍

What gets skipped is the upstream question: does any of this solve a real operational problem for the person actually using the system?

The hotel GM reviewing the software in a quarterly business review and the night auditor using it at 2am have entirely different pain points. B2B hospitality software typically gets designed for the former and used  frustratingly, by the latter.

‍

IDEO's core principle in design thinking is that human-centered design keeps people at the center of every process  and that as long as you stay focused on the people you're designing for and listen to them directly, you can arrive at solutions that meet their needs. In practice, for hospitality tech this means accepting an uncomfortable truth: the person who buys the software is rarely the person who suffers when it is poorly designed. Building for the buyer without researching the user produces tools that get sold once and abandoned quietly.

‍

The symptom is always the same: low adoption rates, workarounds that replicate the old manual process alongside the new system, and support queues full of requests that indicate the product is fighting against the natural flow of the job. These are not implementation problems. They are research problems that were never addressed before the first line of code was written.

‍

What a proper B2B UX research process looks like

‍

A proper B2B UX research process for hospitality tech has three distinct phases, and none of them happen at a trade show.

‍

Phase 1: Discovery research — before the product brief is written.

This is the most skipped phase in hospitality tech. Discovery research means spending time in the actual environment where the software will be used: behind the front desk during check-in rush, in a restaurant kitchen during service, in the back office when a manager is running end-of-day reports. The goal is not to ask users what features they want  users are not product designers, and they will tell you what they already know. The goal is to observe what is actually hard, what workarounds exist, and where the current system or process breaks down under real conditions.

‍

Nielsen Norman Group's UX research framework maps 20 distinct research methods across three dimensions — and the most valuable methods for B2B hospitality products sit firmly in the observational, contextual inquiry category: watching users perform real tasks in their real environment rather than asking them to respond to a prototype in a testing room.

‍

Phase 2: Validation research — before development begins.

Once a problem is clearly defined and a potential solution is being designed, validation research tests whether the proposed approach actually solves it. This means structured interviews with the operational users, not the buyers  reviewing early concepts or prototypes. IDEO's design thinking process frames this as "testing to learn" getting prototypes into the hands of real users as early as possible, with the explicit goal of learning what to change rather than confirming what you already believe. For hospitality tech, a low-fidelity prototype tested with five actual hotel night auditors before development begins is worth more than six months of post-launch feedback from a support queue.

‍

Phase 3: Continuous research — after launch.

Research does not stop at launch. It shifts from discovery to monitoring: tracking where users drop off, which features go unused, where support tickets cluster. The difference between a hospitality tech product that improves and one that stagnates is whether the team treats post-launch data as research input that informs the next cycle  or as metrics to report.

‍

The 3 research methods that matter most for hospitality tech

‍

Not every UX research method works equally well for B2B hospitality products. These three consistently produce the highest-quality insight for this context.

‍

1. Contextual inquiry — observing users in their actual environment.

Send a researcher to spend a half-day at the venue during real operating hours. Watch the check-in process. Watch how a manager handles a double booking, a complaint, a shift handover. Do not run a demo. Do not ask leading questions. Just observe and ask "tell me more about that" when something unexpected happens. This method surfaces the real friction points that no survey or interview will ever capture, because users adapt so completely to their workarounds that they no longer notice them.

‍

2. Jobs-to-be-done interviews with operational users.

Structured interviews focused not on what features users want but on what outcome they are trying to achieve in their job and what is currently preventing them from achieving it consistently. The right interview question for a hotel PMS team is not "what would you add to this system?" — it is "walk me through the last time this system made your job significantly harder and tell me exactly what happened." The answers reveal the actual jobs the software is being hired to do, which are almost always different from the jobs the product team assumed.

‍

3. Usability testing on real tasks.

Once a feature exists, give operational users a realistic task to complete without assistance and watch what happens. Do not explain the interface. Do not help when they get stuck. The points where they hesitate, misclick, or give up are the exact issues that will generate support tickets and reduce adoption at scale. Five participants in a usability test will surface more than 80% of critical usability problems  a finding from Nielsen Norman Group's research on testing sample sizes that has held up for decades across industries.

‍

How research changes what you build — and what you cut

‍

The clearest output of proper UX research is not a feature list. It is a cut list. When you actually understand what operational users need to do their jobs, a significant proportion of the roadmap that seemed important turns out to be irrelevant to them, or actively adds friction to workflows that should be fast and automatic.

‍

We have seen hospitality tech teams discover through contextual inquiry that a core feature — one that had been on the roadmap for two years and was frequently mentioned in sales calls — was never used by operational staff because the screen that contained it required three taps to reach during a time when users had one hand occupied and 30 seconds available. The feature itself was not wrong. Its placement in the interface was. Research found this in a two-hour session. The sales process had been obscuring it for two years.

‍

Research also changes the way product value is communicated. When you understand that a hotel operations manager cares about reducing handover errors between shifts, not about "streamlined workflows," the product language changes entirely  and so does the website, the sales deck, and the onboarding sequence. UX research and marketing strategy are not separate disciplines at this level. They are the same inquiry, conducted at different stages.

‍

A brief note on why we added this to our service offering

‍

Mad Magnet started as a digital marketing and web development studio for hospitality and tech brands. We added UX research to our work for a specific reason: we kept encountering hospitality tech clients whose marketing and website problems were actually product problems. The value proposition was unclear because the product team had not validated which outcomes operators actually cared about. The conversion rate was low because the website was describing features that operators did not recognise as solutions to problems they had. Fixing the website without addressing the underlying research gap would have produced slightly better-looking symptoms of the same root problem.

‍

The research methods that work for hospitality tech products are the same ones that inform effective positioning, effective content, and effective digital marketing  as we cover in our broader digital marketing guide for hospitality brands. If you are building a hospitality tech product and the market is not responding the way you expected, the answer is usually not a rebrand or a new ad campaign. It is six structured conversations with the operators who would use your product, conducted by someone who knows what to listen for.

‍

If that is where you are, our services page covers what we offer across research, brand, digital, and growth  and how they connect for teams at different stages. Or book a 20-minute call and we can tell you quickly whether research is the right starting point for your situation.

‍

Frequently asked questions

‍

What is UX research for B2B hospitality tech products?

‍UX research for B2B hospitality tech is the structured practice of understanding how hotel operators, restaurant managers, and venue staff actually use, or struggle to use, software in real operating conditions. It involves observing users in their work environment, conducting jobs-to-be-done interviews with operational staff rather than buyers, and testing prototypes before development to validate that proposed features solve real problems. The goal is to prevent building software that gets sold but not used.

Why do hospitality tech products have low adoption rates?

‍Low adoption in hospitality tech almost always traces back to a research gap: the product was designed based on what founders, sales teams, or buyers assumed operators needed, rather than what the operational users  front desk staff, restaurant floor teams, night auditors  actually need to do their jobs. Features that look good in a demo rarely match the reality of a fast-moving service environment. The result is a product that gets implemented and then worked around.

What is the difference between B2B and B2C UX research for hospitality?

‍B2C hospitality UX research focuses on the guest experience, booking flows, app usability, pre-arrival communication. B2B hospitality UX research focuses on the operational user  the staff member using the software to manage inventory, process check-ins, handle reservations, or run reports. B2B research is more complex because the buyer and the user are different people, the usage context is high-pressure and time-constrained, and the cost of poor usability is measured in operational errors and staff frustration rather than abandoned shopping carts.

How many user interviews does a hospitality tech product team need to do?

‍For discovery research  understanding the problem space before building  five to eight in-depth contextual interviews with operational users will surface the majority of significant insights. For usability testing of a specific feature or interface, Nielsen Norman Group's research consistently shows that five participants expose more than 80% of critical usability problems. More interviews produce diminishing returns beyond these numbers unless the user population is genuinely heterogeneous across job types or property categories.

What is design thinking and how does it apply to hospitality tech product development?

‍Design thinking is a human-centered problem-solving process that prioritizes understanding user needs before generating solutions. IDEO's framework organizes it around empathize, define, ideate, prototype, and test  an iterative cycle that keeps user needs at the center of every decision. For hospitality tech, applying design thinking means spending time in the operating environment before writing a product brief, testing prototypes with real operational staff before development begins, and treating post-launch feedback as the start of the next research cycle rather than the end of the project.

‍

‍