The TourRadar App: Part 1/3 - Product Discovery
Why Build an App?
When TourRadar.com went live in 2010, it’s fair to say that both Apple and Google were still figuring out exactly what users wanted from a mobile device. Apple had bundled iOS 4 in its sleek iPhone 4, and were venturing into the tablet market with the first iPad. Google was focusing purely on the Android OS, relying on HTC to distribute Android Froyo and Gingerbread on their devices. In the nine years which have followed, both platforms have matured and changed the habits of everyone who uses mobile devices.
At TourRadar, we’ve seen the effects of this first-hand: more customers are discovering, booking, and organising their tours through their mobile devices than ever before. As a result, we were faced with an important question: beyond offering a responsive website, is there any further value we can provide to our mobile users?
By starting with the customers’ needs and typical mobile app usage, we found that the value was in making those small interactions simpler and more convenient. And although the whole customer journey — from the discovery of tours, to booking, to being on a tour — could benefit from having a greater mobile focus, one area, in particular, stood out: the ‘Booking Conversation Page’ (BCP). This page handles the tour management for the customer by providing direct access to the operator, the tour details, payment information, access to tour vouchers, and more.
This was backed up by the data we had, which showed clearly that customers go to their BCP, ask a question, check a help topic, or supply some details to the operator, and then leave the site. With these customer interactions as the main focus, we decided to explore the possibility of building an app experience to make this even easier for customers.
Discovery/Ideation
Although the focus of the app was defined, we soon realised that “tour management” is a broad term. Does this refer to preparing for the tour, or whilst you are on the tour itself? Or is it only about managing your conversations with operators prior to booking?
As a UX, Engineering and Product team, we collaborated on a discovery phase where we attempted to nail down the elements of tour management needing the most attention, and from there ideate over the user journey we wanted to offer. There was no shortage of ideas! These ranged from a notification style centre app (where, upon logging in, you can see exactly which elements of the tour need your attention) to an on-tour companion, letting you manage the tour day-to-day.
We visualised and grouped our ideas on a digital board and mocked up wireframes for any ideas which we felt strongly about.
When reviewing our ideas, it became clear to us that the value of the app lay in helping customers who had just booked to prepare for their tour. In order to make the tour experience as smooth as possible, operators require passengers to provide various details and documentation, and in turn, customers often have questions about their tour: What meal options are available? How big are the tour groups? What footwear should we bring? This is an ongoing process from booking until the first day of the tour. We decided that the app experience would make these small and quick interactions more convenient and easier for customers.
Defining the App MVP
Before diving into defining an MVP, we reminded ourselves of a number of golden rules to keep us honest:
- An MVP is a mechanism firstly for learning and testing a hypothesis
- Despite being minimal, the MVP is still a product, and therefore must still be valuable, usable, and feasible to build
- Anything outside of the MVP scope is simply held back for later iterations (if they are deemed valuable enough to build)
Setting up in this way made it clear to us that we had already made a number of hypotheses that we hadn’t yet validated or tested. That the value of the app lay in these small and quick interactions was only a hypothesis. That the app would be significantly more useful than our responsive web site was another hypothesis. And lastly, and perhaps most importantly, was that customers would actually download and install the app on their mobile devices.
Rather than being overawed by the amount of uncertainty, we took our ideas and mapped them to the user journey we expected our customers to take with our app.
From this, we stress tested each piece of desired functionality against a basic question: Is this feature essential for customers to manage their tours effectively? This made it incredibly easy to arrive at a decision on nearly every idea we had, with only ‘Push Notifications’ drawing a real debate within the team. In the end, we settled upon the following MVP scope:
Although it would normally be unthinkable to exclude a sign-up form in the app, we realised it didn’t add much value for our customers at this stage, given we were targeting this to those customers who already had bookings and therefore already had accounts. However, as we discussed all the tasks required for tour preparation, it was clear that we had to offer a full suite of functionality here; we didn’t want to frustrate customers during this key stage of the user journey.
Having ideated over a number of possible solutions and settled on our MVP, we had to consider the tech approach we were going to take to build the app. We’ll detail this in the next part!
The app is now available for download on iOS and Android devices. This MVP version of the app supports only those customers who already have an account with TourRadar. As we receive feedback, the app will mature to support more and more customers.
