Red Route 1: Create A Trip and Itinerary

User Flow for Red Route 1

The “Find places to go” process is embedded in the “Add a trip and itinerary” route, and I wanted to keep them separate. I found in my user interviews that often, users would browse for places they might want to visit and then search in that area, rather than knowing from the beginning where they wanted to visit. Hence, I felt they were two independent entities with no certainty which would come first. I wanted to give users this flexibility and freedom. 

In “Find places to go”, I wanted to give users of differing travel experience to be able to easily search for places. This led me to decide to allow the ability to search from the landing page, the map, and also from the itinerary- using a variety of input data types.

 Red Route 2: Find Places To Go

User Flow for Red Route 2

During user interviews, 3 of 5 interviewees mentioned they had specific tastes so they would take different types of recommendations from different people depending on what types of activities they were. Hence, I decided the search filters are a critical factor in users adopting the recommendation feature. I also researched different travel and restaurant discovery sites to see what filters they enabled for their customers. I would have added more filters but for the MVP, I felt this was enough. 

I came to understand while talking to users that during their searches, they would often use Google maps to ‘favorite’ a place for later even if they were not committed to going there on a trip. With this in mind, I wanted to let users ‘favorite’ places that they could keep a list of, in case they wanted to add it to their itinerary later. 

 Red Route 3: Collaborate With People On The Trip

User Flow for Red Route 3

For the last red route “Collaborate with people on the trip” I followed procedures on commonly used group messaging apps. The most common app amongst interviewees by far was Whatsapp. I imagined the user flow to create and start a chat conversation to be similar, with added variables being related trip and dates. 

Progress Bar.

Most tasks did not require too many screens but with “Adding a trip”, because it required 5 screens/steps to finish the task, I added a progress bar at the top to keep users informed of their progression.

Back Navigation.

Even with the Android ‘back’ button being a hardware feature of the phones, I decided to add an additional ‘back’ button for complete user control and freedom.

CTA Buttons.

I wanted to give users easy access to what I assumed would be commonly pressed buttons, so in addition to them being available via the primary navigation buttons, I put them as big CTA buttons on the landing page of the app.

Tooltips.

I added tooltip modals to give users a sense of what actions to take, and what would be possible even with the limited functionality of sketched screens.

Test Findings.

1. A common user assumption I discovered was that when it came to adding accommodation or flights to the trip details, the users wanted to be able to search for accommodation and flights to book it as well. 

2. To start planning a trip with known details, most of the participants went straight to DISCOVER to begin their itinerary rather than ADD A TRIP or TRIPS. This was despite both options being clear CTA buttons on the landing page and users being told exactly where they are going.

3. Everyone was comfortable with having the map as the discovery part of finding places. They expressed relief in seeing the filters and sorts in searches that they considered important.

• I didn’t expect people to want to book flights and accommodation directly from the app but it made sense as people want one interface to help them achieve all their goals. Perhaps my description to the users of the app’s functionality should have been clearer- that it is not a booking system.

• I was able to make revision notes about navigational issues from the way the participants interacted and moved (or wanted to move) through the app. Users’ logical process flows were evident when they didn’t see the screen they expected- but it usually wasn’t consistent nor highly problematic.

• Once the participants understood the purpose of the app- that it was more for discovery and organizing than booking accommodation and flights, they became more confident and relaxed. 

• The collaborative and organizational aspects particularly made users believe in the value of the app. Users found the app to be helpful and they valued the recommendations and filter/sort options greatly. They also loved the ability to communicate with friends on the app and have everything organized in one place.

Recommendations.

• I would make some minor improvements to the navigational processes which are not part of the MVP. In particular, when one mini task is completed, where users are directed to upon pressing “BACK” or “SAVE”. These would be based on what they had expected to see upon clicking certain buttons. Some users expected to go back to search results, or back to their itinerary.

• I would look into how complex it might be to allow booking accommodation and transport directly from the app for the later versions of the app, also not part of the MVP.

• I would create suggested itineraries that are already made that people can personalize for themselves, based on the recommendations from their contacts and reviews online.

• Based on the order of buttons users clicked and screens they expected to see, I decided to make changes to the options available to users to follow their natural processes. Allowing users to go to DISCOVER first, find things they like, then favorite things and add to the itinerary.

• I decided to add times and categories for transport details, because the users seemed confused what and how they would enter details.

• I decided to add a summary page upon entering the trip details in ADD A TRIP and allow users to COMMIT and SYNC with their contacts and calendars. This is to let users see the result of the steps they had undertaken thus far. Because there were 5 steps of users entering details, it would serve as a helpful reminder to users what they had entered before committing and creating a trip from the entries.

• Another change I implemented was to simplify the hourly itinerary blocks to a simpler view but allow for granularity when needed. One user mentioned that the hourly blocks were too overwhelming. I researched some mobile calendar apps and decided it may be better to only show what was scheduled, without it being equally segmented into hourly daily slots.

• I decided to add the collaborate/chat function from the trip management page. This is after seeing a few users try to go to the MANAGE TRIPS page to perform task 3, which was to collaborate and communicate with people on the trip.

• I also decided to add the option to invite contacts to the app from the chat, based on user comments.

Wireframes.

Incorporating interaction design principles, I turned my initial design sketches into digital artifacts using Sketch. Taking note of insights and observations made during the previous guerilla user testing, I made sure to integrate my learnings with the principles into these mockups. 

By creating a low fidelity digital version of the app, I was able to identify critical design decisions that I would need to make. It was important to be able to do this while having the flexibility of not having a labor intensive design yet.

• Consistency, standards, heuristics: to prevent user error and make an application easy to learn. e.g. by using similar elements to achieve similar tasks, and having similar functions and behaviors throughout. I used the same ‘add’, ‘favorite’ and ‘share’ icons throughout the app to let users familiarize themselves with actionable items. I also tried to follow layouts of popular apps like Google calendar and Google maps.

• Visual hierarchy and emphasis: by arrangement of elements in a way that implies importance. Because this would influence the order in which the user perceives what they see. Order was created by visual contrast between objects in a field of perception. Visual contrast was achieved by size, proximity, color, opacity, and actual tonal contrast between elements. e.g. 40% opacity dark grey layers behind module pop ups, use of different levels of boldness and sizes in fonts, colors and sizes of buttons.

• Recognition rather than recall: by showing users things they can recognize to improve usability over needing to recall items from scratch. e.g. I used common standard icons, and where there were no standards, I tried to make them as intuitive as possible, with labeling.

The interaction design principles focus on the interactions users have with the product and how to make those interactions as streamlined as possible. My goal was to create an effective interaction design so users can understand what the product is used for and how to use it just by looking at it. 

• Discoverability: so users can find what they need and are clear about what actions it performs, e.g. I labeled any non standard / non universal icons, used universally worded labels on buttons, and same colors for related items.

• Signifiers: to indicate an available interaction, e.g. I used tool tips to signify how to use certain parts of the app.

• Feedback: to show information about the impact of an action and ensure visibility of the system’s status, e.g. confirmation modules were used to show successful edits, adds, saves, etc.

• Conceptual and mental models: to match images in a user’s mind about their expectation of a certain interaction and how something works in the real world. I wanted to make the interface easy to understand and use so it was intuitive. I changed the flow of the screens to match the sequences of what users tend to do in their travel planning.