Rapid Prototyping

In choosing to showcase rapid prototyping, I very quickly knew that I would be attempting travel. More specifically, I chose to focus on building a mobile application that would assist with travel planning. It was a subject matter that I was passionate about and I felt I understood the process well enough. My assumption at that point was that,

“Detailed travel planning was a difficult and tedious process that few looked forward to.”

Question was, did other feel the same way? Time to find out.

User research

I began by attempting to find out more about the Users. I managed to interview 5 different participants on their travel planning experiences. In doing so, I tried to craft questions that focused broadly on the following main areas:

Pain: What were the problems faced when planning for a trip?

Pleasure: What did you enjoy during the planning process?

Context: When were issues encountered — pre-trip vs in-trip?

Behaviour: How are these plans organised and accessed?

Affinity Mapping

As I collated the findings of the individual User interviews, I grouped the responses according to trends that were identified. Doing so allowed me to uncover the salient pain points that Users faced in planning for their travels. It was revealed that the majority of Users:

  1. Enjoyed the process of travel planning
  2. Planned trips to the very last detail
  3. Mostly adhered to original plans made prior to the trips with few changes
Original Findings
Affinity Mapping

However, probing further also uncovered that:

  1. All Users relied on multiple online resources (Google, Tripadvisor, Lonely Planet destination guides etc). While the research was fun due to the discovery element, organising fragmented information across multiple sources was an inconvenient task.
  2. Most Users were not able to find out about localised information for specific districts within their trip such as event listings and courtesy information (eg nearby restaurants, side attractions etc). Users agreed that such information would be useful and would allow them to explore destinations more intimately.
  3. Most Users travel with their smartphone as their primary connectivity device. Static travel plans were stored on the device. Access to further information (online research) while on the trip was limited to an average of twice a day at the hotel where wifi was available as Users typically did not wish to pay for local data plans while travelling.

It was also established that the most important factors that Users considered when selecting destinations / attractions and activities were:

  1. User Reviews
  2. Price
  3. Convenience

Problem Statement

Based on the findings above, I proceeded to define my problem statement as follows:

“To develop an application that allows Users to research travel destinations and allow them to easily create, manage and access trip bookings and itineraries.”


In order to develop the product, certain assumptions were made:

  1. The product would be supported by a resource aggregator — pulls attraction information for each destination from other popular online resources such as Google, TripAdvisor, Lonely Planet etc
  2. Information pulled would be curated and presented according to required format for mobile application — Eg: Title, Short/Long Description, Short/Long User Reviews, Star rating etc
  3. There would be a marketplace section where local tour guides/service providers could list and sell their services/activities. Data entry options would also be structured and formatted to show most important details — Eg: Title, Short/Long Description, Short/Long User Reviews, Star rating etc.
  4. Application should allow for in-app bookings of services listed and confirmations would be cached within application for offline retrieval.
  5. Database entries relating to information on a particular attraction would be linked via parent-child relationships via Tags. This would allow courtesy (eg nearby local events, dining options etc) and mapping/directional information such these these associated datasets can be retrieved when an attraction or activity is added to a Users itinerary. This datasets can then be cached for offline retrieval and browsing when Users are travelling without data connectivity.

For the purpose of the rapid prototyping exercise I have chosen to focus on the process of “Creating A Trip” and “Adding an Activity to the Itinerary”.

Mapping User Flow

Mapping User Flow


Creating a Trip should be easy
Information displayed should be relevant to Users

In designing the screen flow for specific Attraction / Activity Information, I chose to adopt a masonry view of activities allow for easy browsing of various options.

The Primary page view is simplified to only show information that is most important to Users within main container:

  1. Image
  2. Title
  3. Short description
  4. Overview of rating score
  5. Number of reviews
  6. Price

The Secondary Page view of Attractions / Activities expands to include greater detail.

  1. Image
  2. Title
  3. Long description
  4. Detailed reviews
  5. Price
  6. Links to Courtesy Information / Map with directions

It was important to provide courtesy information on Linked Pages:

  1. Map view with Directions
  2. Courtesy information — Crowdsourced information on nearby events (updated daily), nearby amenities

Meeting Expectations

The nature of the rapid prototyping exercise dictated that I was only able to focus on a very specific subset of the screen flow due to time constraints. However, I believe that it adequately reflects how the entire application system would address the problems identified via the problem statement since the application would allow User to:

  1. Easily research destinations on a single platform.
  2. Organise and manage previously fragmented datasets within a single application.
  3. Cache selected activities within the application for offline browsing when travelling without data connectivity.

As a bonus, the application also allows Users to discover HYPER-LOCALISED information tagged to each attraction and activity selected. This feature was added to increase the STICKINESS of the application service and to increase User satisfaction by intuitively going being User Expectations to increase satisfaction levels.

Also, although not displayed, the application should naturally allow Users to contribute their own reviews of experiences and allow these to be shared with other Users.

Considerations going forward

Taking the Sharing aspect further, I have realised that word of mouth recommendations from personal friends are especially relevant to Users. Therefore, I would like to create the ability for Users to easily share personal itineraries with friends since this would be extremely useful to Users planning for trips to destinations that their friends had visited previously.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.