Wanderu Group Trip Feature
General Assembly Group Project
Timeline: 3 Weeks
Team: 3 UX Designers
Role: Researcher, UX/UI Designer
Team: 3 UX Designers
Role: Researcher, UX/UI Designer
Through the General Assembly UX Design Immersive program we worked closely with Wanderu to find a user-centered problem and create a solution. Through a lot of user research we discovered one.
Problem:
Coordinating a group trip is never easy.
Solution:
Create a group trip feature where users can plan and book their travel in one place.
We tested and refined our feature at multiple stages before presenting to Wanderu twice. One of those times we presented to a Co-Founder of Wanderu, and a team of developers.
Design Process
Backstory
When we first met with our contact from Wanderu we had one basic directive: find a problem. It was suggested that we go to travel hubs to find users, something which turned out hilarious. But first we had to figure out what we were doing.
Researching - First Steps
With free reign on the direction of the project starting was easily one of the hardest parts. We knew we needed to interview people. Our first task was figuring out the best way to find and talk to as many representative users as we could. Luckily the building we were in was across the street from Boston’s South Station. Plenty of representative users there.
This was where we failed.
We failed in thinking out what sort of data we’d be able to gather.
This was our initial plan:
• Go to South Station as a group of 3
• Have clipboards with Wanderu’s logo on the back
• Approach as a group with a bucket of candy as incentive to talk to us
We thought it sounded like a great plan.
We were wrong.
The first few people we approached quickly said they weren’t interested. It turns out that when three strangers approach you with a bucket of lollipops it can be be creepy.
Who’d have thunk it?
Not to be discouraged, we regrouped and rethought our plan. We decided to give guerrilla interviews, or “please talk to me” interviews, one more proper try. We ditched the lollipops and split up between: South Station, a food truck court, and a busy coffee shop. I was at the coffee shop. The other two designers managed to talk to a couple of people, but I had no such luck.
We needed data. So, it was time to rethink our approach.
Research - Focusing In
We needed longer, more formal interviews with users. I lead the charge in finding and conducting those. While I was doing that the other designers kept trying to get more people on the street. It was from these more traditional interviews that we gathered our most useful data.
In total we conducted 20 interviews (long form + guerilla). We also sent out a survey to multiple subreddits and received 18 responses.
Here’s a visual breakdown of how survey respondents travel:
The analysis mostly focused on the interview, but we also used the survey responses.
Analysis & Feedback
It was time to look at all the information we had gathered.
It was time to find some problems that we could try and solve.
We took all the insights and quotes we had and placed them onto sticky notes.
We had a lot of insights.
This is what our raw data looked like before we grouped it all. It was both gorgeous and daunting. A giant wall of color for us to organize. The three of us took a few hours to group all them into similar groups. We then grouped them under “I statements”.
The “I statements” helped us start to strongly emphasize with our users. But, we saw a ton of overlap in potential solutions.
We weren’t exactly sure what features would help solve the problems. It was easy to see a feature for each individual problem, but we needed something more succinct. So we decided to warp a feature prioritization matrix to help us.
Using the I statements we placed them on an axis to group them in sections of frequency they were stated. We also kept in mind how big the frustrations were in each of the I statements.
Using the diagram we were able to pull out 4 potential problems that we could design solutions for.
The four features & their problems:
• Bearings: Users struggle to figure out where they are and what they can do
• Connectivity: Users find group trips difficult to organize
• Price Alert: Users want to save money, and don't know when to buy
• Live Updates: Users hate unexpected delays
We then took these problems to our contact at Wanderu. We sat down and explained our steps so far and how we discovered the problems that we did. After discussing the 4 features our contact chose “Connectivity”.
Through Wanderu’s own research similar problems were discovered. Wanderu wanted to see what we could do with the issue.
After this we regrouped and discussed our next steps. We realized we needed something.
We needed a refined survey question, based around our chosen problem.
Research Part 2 - Single Question Survey
We reached out to users and sent them an anonymous survey asking one question:
What’s the most difficult part of planning a group trip?
The answers helped us figure out a lot more about our users and the specifics of this discovered problem.
Through the survey we also found a problem statement in the form of a quote from a user:
Coordinating a trip with multiple people is never easy.
Personas
Using our research we created 3 personas to do a few things:
• First, we wanted to keep our actual users in mind during the rest of our process. To be sure that we were designing for them and solving their issues.
• Second, we wanted to be able to show the design using their story and journey.
We created three personas with general traits that our users showed:
• Michael: A natural leader, stays organized
• Lauren: Headstrong, likes to do her own thing
• Justin: Goes with the flow, doesn’t care about planning
To make sure we had a specific person in mind, we also fleshed out the “main” planner persona, Michael.
With our users in mind it was time to start solving the problem.
Ideation & Creation
At first we thought a design studio would work best. But after doing a few rounds of it we realized that none of our solutions were what we felt worked. We decided to change things up and instead design the feature together on the whiteboard.
The first step was figuring out the basic flow that users would take.
With this flow in mind we went about creating the details of the interface. After a long discussion we decided to focus on a group that traveled together to and from the same locations. We thought about adding a feature for someone starting from another location, but our timeline was short. We had to focus.
We were constantly erasing and adding to our whiteboard for quite a while. The goal was to create a solid version 1 that we could translate to paper and begin testing.
Note: The names on the board were the initial names of our personas that were later changed. (We used our own for fun to keep us engaged during the long process)
We decided to add in lite versions of the features that would solve some of the other issues we found. These features took place at the end of the flow, and were there to show how our feature could be expanded. (To see that, check out the prototype video at the end!)
After creating the whiteboard version we were ready to get it on paper and start testing.
We considered creating a pre-group chat for users to discuss when and where they were going before hand. But, our research showed that that decision is made when they decide to travel in a group.
Here are a few screens from the paper version:
With those created, and test scenarios set, it was time to move onto testing.
Testing & Takeaways - Part 1
We brought our paper prototype to many users and ended up receiving some consistent feedback. Overall the flow made sense and so did the feature, but there were still plenty of fixes to look into.
The biggest takeaways from the paper-prototype testing:
• “WandergroUp” looks like “wander grow up” and it’s confusing
• Preferences looked like they were for the whole group (Our goal was to have the system aggregate the filters and give best options)
• Some buttons were not labeled and unclear
• People were unsure if they were booking for themselves or everyone
Digital Version 1
It was time to translate our feature into a digital version. To do this we used Sketch. We tried to incorporate some of the feedback from the paper-prototype tests. But, the time crunch had us forget a couple things which I’ll get to later.
I then put the screens into inVision and created a clickable prototype of our Version 1.
Testing & Takeaways - Part 2
With the inVision file we were able to test even more representative users who had not been apart of the process so far. It was important to not keep reusing the same users as they would start to know how to interact with the app, or compare it to older versions.
The biggest takeaways from the digital-prototype testing:
• Buttons still unclear
• Departure / Return trips are not clear which is which
• Credit card upfront made everyone uncomfortable
• Still not clear who users are paying for
• Wanted to see overview before booking as Justin
• Preferences look like they are for the whole group still
Digital Version 2
The main fixes in the digital-prototype version 2:
• Make the buttons clear
• Departure / Return trips become obvious
• No more credit card upfront
• Begin a split payment feature
• Put itinerary upfront in new sign-up flow
• Make it crystal clear who the preferences are for
In the current version we also built out the “Explore” & “Chat” functions a bit. We saw that our users found it hard to force others to book, so we came up with a solution. In the chat Chiku (Wanderu’s monkey) will pop up and give useful information to the group automatically.
Presenting to Wanderu at Wanderu
After presenting to Wanderu at General Assembly we were invited to present to a larger part of the staff.
A few weeks later we had an incredible opportunity to present to a Co-Founder of Wanderu a large chunk of the developers.
It was fantastic to get a room full of outside perspectives. There were a lot of good points raised, and questions asked by the team at Wanderu.
My favorite question:
Why do you think no other travel app offers this?
Why do you think no other travel app offers this?
That wasn’t a question we ever found ourselves asking. It caught me off guard when I realized that. We had looked around to see if anyone was doing this feature (they weren’t) but never stopped to ask why not.
I think it comes down to a few reasons:
• There’s a lot of back-end work that would need to be done for little monetary payoff
• The sale has already happened, so the company might not immediately profit
It was great to be able to show the Wanderu team what we had created, and talk to them about it. But, the project never truly ends in my mind.
Reflecting
Looking back I’m proud of the feature that we designed. It is a feature that solves a real world problem in a simple way.
There are a few things I wish we could tackle moving forward:
• Figure out different locations in the booking
• Test the feature with larger groups of travelers
• Build out the bearings, chat, split payment, and itinerary functions
• Keep testing the feature to improve it
