#5a – Rationale of Medium Fidelity Prototyping Approach

1. Our prototype is more vertical than horizontal. This is because chat and map are crucial in testing our prototype. Since making a dynamic chat and map are time consuming we decided to reduce horizontal features of the prototype.
2. The chat is Wizard-of-Oz’d by having a human that’s pretending to be a bot. The bot’s responses will be scripted so that we’re consistent throughout. From a technical standpoint, we’ve already created a chat and map interface. We used ZenDesk (a customer service company) and Google Maps API. We will be telling the subject that we’re using a Google voice API to parse their chat. We will then reveal that a human is the bot.
3. Functionality is more important than appearance.
4. Prototype should be used on a phone.
5. For our prototype, we are using the Google Maps API and ZenDesk.

#5b – Prototype Demonstrations

Figure 1: The prototype consists of a map screen that covers the entire interface with basic controls. The map is built using Google Maps API, allowing the map to be dragged, zoomed in/out, clicked for details, and switched to Street View. At the bottom left corner is our chat button, which was kept small to minimize it being intrusive in any way as we have found most users tend to mainly focus on the map.

Figure 2: The chat window allows the user to communicate with our bot. This screen shows the startup greeting and appearance of the chat window. The top right button shrinks the window so that the user may return to the map view at any time and continue exploring.

Figure 3: This shows an example of the conversation flow one might expect to see from the user interacting with the bot. Given what information the user requests, the chatbot will respond accordingly and make any necessary updates on the map view and direct the user’s attention to them.

Figure 4: This screen shows the updated map view according to the conversation between the chatbot and the user. The information presented here can be personalized to the user request depending on the extent of exploration.

Figure 5: A typical way to end the conversation with the bot after gathering information that is required for planning to visit a point of interest on the go. The amount of information required varies from user to user, but our bot should provide enough dynamic feedback to account for most experience levels.

2a – Next Steps

For the next step of development, we should implement the system based on the following core aspects: use of local’s travel suggestions, map integration, and offline access of information. It is also important for the information given to the user is targeted to them given their profile and preferences.

Regarding local opinion or advice from people that have extensive knowledge on a certain travel destination, it is important we have a system that includes their information and their respective ratings and reviews for locations. This information would be useful in order for users to more informed decisions from a list of recommendations presented to them. An extension of this would be to make the process dynamic rather than just a static collection of locations with their respective reviews and ratings. More specifically, a system that allows the interaction with a concierge, that would have local wisdom, through a chat interface. A user could chat with this concierge and be given relevant personalized information. In foreign countries where the tourist does not speak the local language, it would be useful to have the ability to make bookings through this concierge chat.

With regards to maps, we aim to have the basic zoomable map showing locations of interest personalized for the user. Since many users have expressed concern for distance, it would be important to allow the user to base their itinerary decisions on their current location and location of the points mapped.

For offline access, it would be ideal for relevant information to always be accessible. Tourists are often offline when travelling abroad but they should still have access to their itineraries or maps.

The interface would be intended for phones, so information must be presented minimally avoid confusion. The group planning and tour guide aspects are no longer supported since users didn’t gravitated towards them when organizing their typical trips.

2b – Task Examples

1. Jacob is reading a travel brochure closely and is gathering information to make plans for things to do in the travel destination he has reached. As part of his backpacking trip across this country, he wants to check out as many interesting spots as he can within the time he has available. As he is making his itinerary, he decides to add a stop in a very small town and isn’t too sure what to expect from it. Aside from hearing that rooms in this town are cheap, he knows little about the local attractions in the area. Jacob wishes to gather more information from locals and expert travellers to help find the best tourist attractions or must-see attractions in the town. Jacob also decides to visit the information center to ask for their opinions on popular attractions in town. To make the most of his trip, he is generally looking for places that highlight the essence of the country, and he wants advice on locations that will best suit his interests and typical travelling habits.  

Summary of changes: We decided to exclude the feature for the tour guidance by others. Also, travelling with others as a group is no longer supported either. We added support for presenting reviews or ratings by locals and expert travellers as well as recommendations by information centers, hotel concierge etc.

• Excluded: tour guidance by others; travelling as a group
• Included: others’ opinions and recommendations

2. Joseph is a college student who likes to travel to different countries during his school holidays. Given the short duration of vacation, he wants to make the most out of his trip. Therefore, he plans his activities on-the-go as soon as his trip starts. He usually does the planning in the hotel room or in the lobby area because he needs internet access in order to search for tourist activities online. He wants to save some of the relevant information on his mobile device so that he can access and use it while offline if needed. He finds several tourist activities to do and places to visit in the city and reads through the most relevant information about each of them. He then makes a shortlist of activities based on his preferences and saves the relevant information for offline use. Later when he is out for his selected activities, he uses this information to get to his destination as well as to remind himself about other important details.

Summary of changes: This task example has changed completely from the previous version since we decided to exclude the tour guide aspect as was addressed in the pre-field study version. The new version highlights the use case of information compiled from trusted sources as well as being able to have offline access to this information.

• Excluded: tour guide
• Included: information compiled from reliable sources and offline access

3. Jess, a young traveller, has just arrived in Cape Town and it is her very first time there. Since she isn’t familiar with the city, she wishes to explore the city in the most efficient way possible- making the stops to the most important tourist attractions. For this purpose, she plans to make frequent use of maps so that she can easily reach to her destinations. She first considers visiting the nearby highlights of the city. Once she decides upon where she wants to go, she marks these locations on the map and highlights the route that she needs to take. She also puts a note on the map in order to help remember important details of each attraction while she is on the go.

Summary of changes: This task example has changed completely from the previous version because our design will not support group activities and search for tour guide. In this post-field study version, we covered the use case of maps.

• Excluded: group activities and search for tour guide
• Included: maps

2c – Prioritized List of Requirements

Given our task examples and associated inquiry with potential users, the requirements for our system:

a) absolutely must include

• the ability to store travel information and have offline access to plans. When travelling to foreign countries it is not likely that a user has access to a phone data plan. For this reason, it is essential that the user has access to the information of their itinerary (whether on a map or just names of locations they need to visit)
•  personalized local information given the user’s preferences. It is important for the user to be given filtered information that fits their travel style and characteristics.

b) should include

• maps that are available offline. When in a new city, a tourist will need a map to navigate and find points of interest. Users do not always have access to phone data, so this would be an important functionality to have offline also.
• access to local advice + previous tourist information (whether static info or not). Whether asking your hotel concierge, friends, locals or even reading online local blogs, users really value the advice of people that have previously been to the places they are visiting. More specifically they value the opinions of users that are similar to them in terms of interests and travel style.

c) could include

• option to book activities through app. Because a tourist’s time in a new city is limited, booking restaurants or buying tickets before showing up to a location is often useful and makes the process more efficient. It would be useful to be able to book activities before showing up to a specific place. An automated service where the user doesn’t have to communicate directly with the local might be beneficial especially in those countries where language and communication is problem.

d) could exclude

• general, hard to process information. One of the current pain points of making an itinerary for travels is the amount of information that has to be read before finding something appealing by the user. This generic information about a city that is not relevant to a specific user should not be included in the design.

With regards to our users:

a) absolutely must include

• travellers that are visiting a place for the first time and want personalized information
• travellers that need to plan events when arrived in a new city

b) should include

• travellers that plan their trips in advance

c) could include

• tourists that are travelling in groups and plan in big numbers
• people that are not currently travelling but want to plan something in the future and want information on places that they are considering visiting

d) could exclude

• people that have extensive knowledge of the place they are travelling to (e.g., locals)

2d – Design Alternatives

Given the conclusions derived from our data analysis, there are three different design approaches we could take. These approaches are:

1. a concierge design that would allow the user to ask for any information through a chat interface and store most useful information for later use
2. a design that organizes static information about points of interest in the city by a certain category (restaurants, activities etc…)  
3. a map-centered design through which activities and points of interest could be indicated on a map

With all the listed possible design directions, the common components would be that users could always view their information offline and that all points of interest and information presented would be personalized to their user profile. More specifically, each user would have a profile that would allow the app to tailor their corresponding results and travel suggestions. Below are the three design directions mentioned, each would cover one of our previously mentioned task examples.

1 . Chat with Concierge Design

This design would allow a user to chat with an AI concierge bot that could provide answers and information to any questions a user may have pre or during travels. The left screen displays the chat, which is the medium of communication for the user with the bot. The concierge can also book restaurants and activities for the user. To produce answers to the questions asked by the user, the user’s profile would be taken into account as well as current information such as availability or crowdedness. Another feature is displayed on the right screen and is all the saved activities for past places a user has visited or future ones. For example, if a user is at home and wants information about a future trip to Milan, they can ask the bot about a museum to visit in the city and then ask the bot to save it to the app. In this case, it would appear in the “saved” tab displayed on the right along with all the information about it and any notes or pictures a user might want to add.

PROS:

• the concierge bot makes the information process dynamic and catered to what a user needs to know in that particular moment
• a user can save important information with their own personal notes to look back on an activity or use it for future reference
• the bot can also take care of all reservations which could be useful for time or if in a place where communicating with locals is difficult

CONS:

• although all the information is given and places can be reserved, a user cannot visualize it on a map.

2. Information Compiled by Category Design

With this design direction, given a user’s characteristics and profile, a list is given for the top 10 things for the respective different categories. These categories are shown in the left screen and are: restaurants, activities, must see, culture, this season only, sports, your mix, and highest rating. The “your mix” category is meant to capture the best of all categories. When clicking a specific category, a list of the top 10 things will be shown. This is demonstrated on the right screen.

PROS:

• the categories capture the main ones that a user would be interested in and the respective lists are tailored to each user
• This design is simple and informative, making the selection process for places to see easy

CONS:

• although the options are presented to a user, a user cannot book anything through this design nor add their own notes or memories to the locations. This all remains static information.
• there are no maps or directions to help the user reach the location. This design is merely focused on informing the user on the different options he/she has in a city.

3. Map-Centered Design

With this map-centered design, a user would be given the top things that, given their profile, they should do in a specific city. These activities would be plotted on the map as shown on the left screen. In the case that a user is not interested a location listed, they could delete it from the map. By clicking on any of these locations, a brief description would be given. This is shown on the right screen. On this screen, a user also has an option to add their own notes and pictures taken at the specific place.

PROS:

• The map feature is very helpful for making an itinerary and organizing activities
• The locations featured on the map are personalized from a user’s specific profile
• A user can add their own information and memories in the form of notes and photos to the specific locations  

CONS:

• A user can use this to navigate through the city but they cannot make bookings or sign up for activities through it. It remains static information.

A high-level goal of the project is to find the intricacies of booking custom tours online. The human activity is deciding on which tours to take. Locl is a service that is intended to help tourists visiting new cities in finding small customized tours or activities they could participate in.

1. Jacob is reading the contents of a travel brochure closely, and considers his plans for things to do when he arrives in town. As part of his backpacking trip across the country, he is making it his policy to check out as many interesting spots as he can within the allotted time. He has just decided to add this unscheduled stop to his trip and isn’t too sure what to expect in this sleepy-looking town. Aside from hearing that rooms are cheap he knows little about the local attractions. Jacob is hoping to gather more information from locals and perhaps see if people would be willing to guide him around. To make the most of the next few days, he is looking for short trips that highlight the popular spots. He wants to keep things flexible as well in case something unusual catches his attention while going around. Preferably, the information could be organized in one place so that he can quickly compare and decide accordingly. He is open to suggestions and is willing to explore together with new people if the situation permits. Jacob has decided to visit the information center later to start things off.
2.  Peter lives in a small town that is a very popular tourist destination and he knows the area very well, including tourist attractions, and the history or stories related to each place. He usually enjoys taking his family members, relatives and friends to these popular places and inform them of what is special about these places. Therefore, he decides that he wants to expand this activity a little further by connecting with visitors that are coming to his town. He wants to connect with them ahead of time and plan out a personalized trip according to their preferences. He wishes to do this on a single platform so that the visitors he guided can leave reviews and rate his quality of service.
3.  Jess, a student in UBC has her family of 4 visiting from abroad. She heard from a friend that people hike during the weekend and sleep in igloos overnight. Jess has never done a trip like this before. She decides to look for a tour guide. Her criteria is safety for her family and a personalized tour so they can all spend time together. She’s aware that she would need equipment but is unsure on where to find it. She’s also unsure of how to find reliable transportation to get her family to the base of the mountain. There’s probably something she’s forgetting right now but she wants reassurance that she’s prepared for every scenario.