Based on the topic of travel, define a problem that could be solved with a mobile app simply and effectively.
View my final deck here.
For this project, I chose to identify my problem statement through user interviews with random individuals with the criteria being he/she must have travelled at least once in the past year. I decided that it was imperative that I take a step back to look at Travel as a whole, then identifying a pain point from there. View my user interview notes here.
The process that I took was as follows:
- Theres nothing wrong with having a broader topic as a starting point— I spent a long time worrying about what questions I was going to ask; should they be focused on a random part of travel? I later realised that perhaps having been assigned a broader topic would give me more freedom in crafting my questions. Also, my partner’s pain point might not necessarily resonate with the other four respondents that I would later speak to.
During this stage of the process, I was stuck with a lot of post-its and many trains of thoughts running concurrently through my mind — should it be about travel experiences? Could it be about the dissemination of photos at the end of every trip? Affinity mapping allowed me to streamline my thoughts and reorder them, removing the dead ends or irrelevant information at that time.
Affinity mapping & synthesising my research
- Only pulling out essential quotes helped me minimise the fluff that I would have scribbled on my post its. That said, I was sure to keep their quotes in their original form — word for word. This allowed me to identify what was missing from my original interviews, and acted as a way for me to keep thinking about why they used certain words in their responses, then leading me to form an insight (see image above for my affinity mapping process)
2. From post its to mind maps. I found that while affinity mapping with post its allowed me to group my findings by observations, it wasn’t the best platform for forming relevant, effective insights (see image above for the mind maps I created to guide my thinking). As such, I preferred to use my observations I drew from affinity mapping as a starting point that would later lead me to form insights that I could explore.
Forming a problem statement
Once I had my main insight, I found myself thinking long and hard — what was it that I was trying to solve? I knew that my users had an issue with group travel. Yet, travelling in groups was common practice for them because they see meaning in travelling with the people they care about. So what is the real issue?
- Shifting from WHATs to WHYs — this simple act of changing my mindset helped me tremendously. By doing so, I stopped myself from thinking of the idea for my app before having an effective problem statement.
My thought process after much deliberation was as below:
People do not like travelling solo,
But people find that travelling in groups can result in a negative travel experience because members often have different activities in mind, or have different travel goals
As such, their biggest fear of travelling is not group travel but the possible conflicts that may come with due to this misalignment in goals and expectations
The final problem statement:
How might we help people who travel in pairs or more have an enjoyable trip despite their different travel habits and personalities?
By creating an application that can help groups of people establish clear boundaries and expectations ahead of their trip, we can create a positive experience for travellers and their companions.
Creating my user flow
I only created my user flow after sketching out my prototype, as I felt that I completing the user flow first would only restrict me in creativity. While unconventional, I felt that this really sped things along for me. Still, there were many points that I was lacking in.
- While more efficient, sketching out my frames before creating the user flow resulted in me overlooking certain features that were not within my initial prototype — which was streamlined due to the project timeline being <5 days. For example, it took me two check-throughs to realise that my user flow was missing a crucial aspect; 1) what would happen if someone accepts a trip from another? Thankfully, it wasn’t too late, and I was able to reflect this in my final flow (see zoomed in version below)
My final prototype
Before embarking on this stage, I thought “easy peasy!”. Boy was I wrong — sketching out the various frames of my application turned out to be one of the longest parts of the process. While challenging, the process was a great learning experience for me, someone without a background in design.
- Usability over design. Focusing on the prototype’s usability over its design helped me prioritise the features that were most important to prove in my 5 min presentation. Still, I placed a bit of emphasis on the colours used in my prototype. Moving forward, I will learn to focus less on creating a high fidelity design, since the final designs should be the ones with the most work.
With that, I’d like to present Travellry
View my low-fidelity prototype here
How it works: With this application, you and your friends will be able to give their input on some of the most common pain points people experience when travelling as a group. Key features are: Dates, budget, type of trip, level of flexibility (how flexible are you about separating from your friends at any point of the trip for individual activities), and personal way of resolving conflict (this would be an open ended answer. E.g: I’d prefer for my friends to raise their concerns over Whatsapp than in person)
When it can be used: Apart from using it ahead of a trip, this application could also be used to find out if the group of friends you had in mind would be interested in a trip you had in mind. This application also minimises the back-and-forth syndrome people experience during the planning phase.
What I would do differently if I were to continue on with this project:
- Including a DM option: a colleague pointed out that there wasn’t a chat function in my prototype, a feature that would be essential in ensuring that everyone was on track
- I would also spend more time with my users — this could even go up to 60 minutes per interview if they are willing. I found that although I got the responses I needed to define my problem, spending more time with them would give them the opportunity to elaborate on their pain points, which I could then weave into my apps features
- Present my idea better: I spent a lot of time on my research and prototype, leaving me little time to work on my presentation deck. For someone who was trained in communications, I was sorely disappointed in the way I presented my information. Essentially, a good design will not fly without a strong narrative
- Usability testing: though I wished I’d done it, the 4-day timeline allowed me no time to consult my users and let them test the prototype. Usability testing is something I’d definitely include in the next round of prototyping
This project brought a plethora of emotions —excitement> confusion>realisation>happiness>fear>relief.
I might even say that I enjoyed the process even more than the end product, as it showed me that I had the potential to identify real insights with a simple user interview (I went gaga at the thought of mixing this with quantitative research and contextual inquiries). To sum it up, completing this project was a proud milestone for me as it killed off my doubts as to whether UX design was something that I really wanted to do, or could do.
Till next week! Tdodeloo~