This project placed third at the Ontario Engineering Competition for the Innovative Design category.
How might we create a platform that encourages fair and collaborative planning for groups of travellers?
I was the UX designer and main front-end developer for the project. This project was my capstone project (along with 3 teammates), and was done over the course of 8 months. We determined a problem statement, ideated, iterated, and prototyped our solution at the end. I worked on delivering:
The travel industry is incredibly lucrative, valued at over 7.6 trillion USD globally in 2016. Tourism boosts the economy for many poor counties, resulting in a higher quality of living and overall wealth. From a personal level, leisure travel is usually a privilege and it is important to make the most out of the budget and planning process.
How do people travel?
We received over 50 responses on surveys and in-person interviews. 91% of people travelled in groups (i.e. friends, family). 88% of people left planning to a more dominant figure when travelling in groups. But despite that, 48% of all participants felt that the company and coordination of preferences can heavily affect the enjoyability of the trip.
Sometimes, life just gets in the way
When asked, respondents cited that they often left planning to someone else because of factors such as lack of time, distance and schedule matters, and simply to avoid group politics. Contributing to the planning process not only meant having to scrape though multiple resources, but also having to negotiate and provide ideas which could be shot down by others.
Since this was a capstone project, it required us to conduct some academic research. While my teammates focused on more technical research, I read up on behavioural concepts such as fairness and group decision-making psychology. Some points gathered included:
We created multiple personas, but here are two of them: a young family planning for a reunion with old friends, as well as a consultant looking to explore her surroundings on a work trip.
As per our research, we decided on a two-stage solution to maximize decision-making impact and efficiency.
This is for stage 2, when all chosen activities are gathered into a total pool and each user is allowed to give their opinions on what everyone has selected.
We developed and analyzed over 6 information-gathering models and concepts. However, only 3 made the cut for further consideration.
In order to determine which model to take, we created a decision matrix based 4 on dimensions: (1) Efficiency, (2) intuitiveness, (3) fairness, and (4) ease of implementation. Using this as our point for evaluation, the preference buckets won by a large margin, and was the model we decided to go with.
A question that was continuously asked during our development process was whether or not we had sufficiently validated our problem statement and resulting solution. Our solution was supposed to not only be intuitive from a UI/UX standpoint, but also to provide a good solution based on our mathematical model. We structured a comparative usability test where we observed users planning a trip to London using both a simulation of Pistachio and a direct competitor. We then interviewed the participants and asked them to fill out an exit survey.
When comparing Pistachio to its direct competitor:
There was also a large time discrepancy. Planning with Pistachio took between 2-4 minutes, while it took roughly 7 minutes to plan with the competitor.
We received a lot of great feedback for features to consider such as:
Focusing on the visual appeal of Pistachio was something the team took relatively seriously. We wanted to have a cohesive “brand” because we felt that even though the backend solution was working, we would not have users without pleasing visuals.
I drew the pistachio nut and a custom geometric sans-serif font for the project logo.
The overall look and features of Pistachio were determined as a team effort. The four of us spent a day at the library hashing out important features and discussing potential ways of implementation. We had a mini sprint and sketch session, where we each contributed and spliced concepts to determine a general skeleton of the project.
Unfortunately, due to technical limitations, we were unable to implement the preference bucket feature in time. Instead of dragging attractions to buckets, users could specify their preferences directly per each attraction.
This is an educational video with more technical details, which we submitted as part of our final course deliverables.