Once we decided we want to focus on millennials, my team and I started the design process by conducting semi-structured interviews to find out how the user group plans their travels today and what their pain points are. The whole team was involved in finding and defining a product vision and every one of us was conducting interviews. My team was working remotely which was a novel situation for me and as the only researcher/designer, I was responsible that our interviews would lead to useful insights. This is why I designed and described a whole process with the goal to get from conducting the interviews to prioritizing what our product would do. This process can be summarized in the following steps:

1. Turn the interview in a set of small, descriptive statements of a user's behaviour
2. Create an insight statement for each descriptive statement, aka our own interpretation of why this is happening
3. Cluster similar insights
4. Define an overall theme for each insight cluster

We collected 92 insights from our interviews which we boiled down to roughly 20 clusters. This was still too much for a minimum viable product and in addition, some of the statements were contradictive. We decided that the easiest solution to this would be if we voted on the pain points we regarded as the ones that "hurt" our users the most. The following insights got the most votes:

1. People would like to have an authentic experience of the city and local customs
2. Finding new and undiscovered places on travels is really important
3. What people are really looking for is information that is directly linked to their interests and activities
4. People find the information currently available too much and overwhelming

We started the product development process by sketching initial ideas and building several paper prototypes. For example, we defined the main screens we would need and used post-its to add all the functions we deemed as necessary. In the early stages, we were iterating a lot, based on feedback from our mentors and individuals from our user group. Below, you can see one of the early stage flow diagrams I created to get a better overview of the service and its individual functions. Creating such a flow diagram helped me not only to build the later prototype but also to communicate product details to my group members and other stakeholders. It also takes less time to change than a paper prototype or wireframes.

In addition to the user experience, I developed a visual identity for TravelPal, since we wanted to pitch an appealing-looking product and not "just" wireframes. Research furthermore shows that aesthetic designs are preferred over designs that are less beautiful, but more user-friendly. Given the limited timeframe, I therefore decided to invest some time in the UI instead of perfecting the user experience.

Below you see the design guide I created for TravelPal as a template for fonts, buttons and the chat interactions. As you can see, I chose grey as a base colour with yellow and mint as highlights, to give the app a fresh look and feel, appropriate for the user group.

The logo for TravelPal is shown above. It is a combination of a speech bubble, a location pin and a map. Together they create a visual representation of the travel service TravelPal.

The final interactive prototype I built in proto.io, you can see a video of it on the right. In the chatbot, the user enters trip details and preferences, before the app automatically creates a trip itinerary of things to do. The user can modify the itinerary, learn more about the individual items or book attractions and reserve tables for restaurants right in the app. If I were to build this prototype again, I would use less duplicate content and blind text, because this could be irritating in a user test.

To understand our users, we followed a highly methodical research process that resembled thematic analysis, an analysis form in scientific qualitative research, which I learned about one year after the project during my Master's degree. For a project like this, a "leaner" approach might have been more appropriate. For me as an individual researcher however, I learned a lot about communicating research methods and results back to team members that are not designers and taking responsibilities for research outcomes.

It was very interesting and challenging to prototype a chatbot in a standard prototyping tool. Since many interactions are necessary, prototyping these was very work intensive. Furthermore, I could not really prototype the "intelligent" and "personalized" aspect of the prototype, which makes it hard to really test the hypothesis that users prefer personalized information and are willing to give up their data for it. I think this is always a risk when prototyping highly complex applications. I recently stumbled across a tweet that sums this problem up: