UNBOARD
Unboard is a platform for users to find companions for spontaneous adventures.
THE PROBLEM
People need a way to find compatible companions on their travel adventures but are unable to do so because they are worried about safety and compatibility.
The idea began when I was near the Dolomites in Italy. While I wanted to hike or take on a via ferrata, I was unfamiliar with the geographical hazards like wild animals.
Thus, I thought about how I could help people in similar scenarios find trustworthy and compatible companions for their proposed adventures. By developing a means for adventure travelers to screen potential activity mates through video and audio means, I can make the adventure possible and allow participants to feel comfortable and safe.
HIGH LEVEL TIMELINE
This is a personal study.
IMPETUS
A journey near the Dolomites.
KEY GOAL
To make adventure travel possible for soloists with little knowledge of regional hazards.
MY ROLE
As this is a personal project, I gained experience in prototyping a product on my own, as well as research.
This study thought me how to prototype something completely on my own without assistance. It also allowed me to see how my choices directly affected users when it came to testing. In a group setting, I didn't get to fully understand why prototypers made the decisions they did. But here, I saw how users' feedback can lead to poor design choices if acted on literally. One example was the introduction of a flexibility feature which users asked for, where users can determine and see how flexible someone's itinerary is. But doing so led to user confusion, as I didn't step back to see the bigger implications of my design before giving users what they wanted. This has taught me how to communicate research with UI designers in my other teams.
UNDERSTANDING THE USER
Adventure travelers.
I began my research with those who loved adventure travel, but I came to discover insights from those who didn’t, so I included them in my pool as well. My goal was to understand how the ability to seek companions affected travelers in pursuing an adventure.
From the discovery interviews, users wanted adventures that were spontaneous and short (one day). Compatibility-matching mattered more than safety checks with official documents. Some activities like bungee jumping and skydiving were inappropriate with strangers, as these were excitable things that should be done with their friends. Endurance activities were more suited.
PENELOPE
'I want to river-hike the Narrows but I don't know how to deal with flash floods. If only I had someone to hike with.'
BREAKING DOWN THE PROCESS
A lean approach.
In designing a solution, I began with hand-drawn prototypes for easy revisions. Doing so made my users more candid with their feedback, as they felt free to voice minute changes given the early stage of production.
Once the overall layout of the app was established, I moved on to wireframes to test usability. What I was interested in was how users reacted to slidable and interactive elements, in order to check if my design was intuitive to use.
With that settled, the most important thing left was to test for users' comfort and trust in the process of finding a companion for an adventure. Thus, I moved on to hi-fi prototypes with simulations of realistic people. These people profiles included close-ups of their faces and descriptions of their own personalities.
THESE WERE SOME MAJOR LEARNINGS OR POINTS I WANTED TO CALL OUT
No calling
Five of seven users said talking to a stranger would build trust before a proposed trip. Nonetheless, nobody in the first round of user tests wanted to call the person they matched with. Messaging was more appropriate.
Official documents not wanted
Users did not trust or want ID/passport verification. What they wanted was a means to feel someone else's personality.
Location Tracker
Location pins can be toggled for safety. Its frequency can be adjusted, and the data will be sent to a friend.
Reputation System
Ghosting was an issue brought up in user testing. One way to curb this was to add a rating and review feature. But this would change the dynamics of the trip. Hence, a reputation system based on ghosting strikes was better.
Check-In
To count ghosting strikes, a check-in feature was needed. Initially, each member checked themselves in by dropping a location pin to the app. But this implies the location data is being used against them, and not for them. Thus, I designed a more elegant solution where the trip initiator checks all members in instead. No location data required here.
TITLE OF THE CALLOUT BLOCK
LESSONS LEARNED
I am not the user.
As this project was close to my heart, I quickly discovered I am not the user. I suspected users would be concerned about verifications, but they turned out be more interested in assessing trust themselves through video and textual means rather than allowing an ID or review do so for them. Moreover, unfamiliarity with geographical hazards wasn't the main reason why users wanted company. Rather, they wanted someone compatible to talk to during long hikes and share a memorable experience.
Also, I learnt that interviewing users outside my applicant pool can lead to interesting results. Here, I discovered users didn't do adventure travel because they had no idea where to go. This is consistent with my data from the adventurer travel pool where all users said they began such travel only after going through such an experience with a friend. This allowed me to design for this large group of people too.