Your perfect travel journal


Have you ever been asked what are the best things to do in San Francisco? I constantly have friends, family and even friends of friends, visiting the city, and every single time they ask me the same question. The problem is, I don't have a good way to recollect this information and I end up having to write a long email with links and photos. When I talked to my friends, we found that this situation is an overwhelming common pattern: it's difficult to gather information about a place you visit and share it with others.



I started with the hypothesis that people who likes to travel usually struggle with the process of documenting their experiences and sharing them with the others. They use different applications and tools to do it (a notebook, facebook, instagram, foursquare, evernote, etc...), but none of this products allows them to build a complete journal of their vacations. After doing some research and market analysis I discovered that there was an opportunity to fill this gap. This is how Swarm was born. I wanted to design a product that would allow the users to collect real time information and experiences to build a journal of their trips. Find hidden gems recommended by friends or other travelers or recommend that awesome travel spot that travel guides forget to mention.



During my research I started by interviewing a small group of people about their preferences while traveling. After that I send a survey to 45 people. I gathered and formalized my findings into personas. I built these to communicate my findings easily and to determine the functional scope of the product.


I look over all the other Apps that where doing a travel journal and I discovered that there were very few on this field related to travel. I picked the main ones, Tripvi and Trip Journal, and I studied how they were designing their main interaction of creating a journal and start uploading information. To valuate them, I applied the ux score card methodology creating some heuristics.




I started sketching the first interactions focusing on how the user would create their first journal. I had the idea of designing a timeline for every trip where users could save all kind of informations. I created a first paper prototype and I tested it with some users. I discovered that the timeline was working really good. I also found out that users wanted to upload places, photos and write notes. Adding reviews, videos or links where more secondary actions that could be integrated within the main ones.

During the process I iterated with the prototype several times and I builded two more paper prototypes. Check out a paper prototype!



Because the size of the amount of content I was starting to organize, I decided to use the card sorting methodology. Card sorting helped me to design and evaluate the information architecture of the app. I did different card sorting sessions with different users, the participants organized topics into categories that made sense to them and they also helped me label these groups.They ended the exercise with similar solutions. Some of them changed the wording of some items, and others added some content. The most confusing part was between "adding a new trip", "trip view", and "list of my trips". On the following image you can see the global navigation I made as result of the card sort.


After sketching and throwing away some approaches, I moved onto making high fidelity wireframes. At this stage, I was able to get the entire flow of the app without worrying about the UI. I had to make a tremendous amount of wireframes to account for all the interactions of the app. I also inluded screens for error states and other edge case dialogs. I put toghether a hight fidelity prototype and I started to test it out with some users.


After testing the hight fidelity prototype for a while, I was a little bit frustrated because the interaction I designed was working pretty good and all the feedback was very positive. I decided to do the exercise of creating a complete different interaction; insted of having a timeline the user would have a book where they could add pages with different informations (places, photos and text).

I found out that the interaction A was more easy and useful. It was also more dynamic because it wasn't attached, as option B, to the size of the page. Even so Interaction B was very beautiful and users enjoyed having a little book about their trips. Finally, I descided to combine both interactions and integrate the book one as a premium feature of the app. I tested it again and users loved that feature. Most of them would pay for it if they can print it at the end of a trip. 





In the photo below you can see some UI elements: