Company
Hapybara
Role
Lead Product Designer
Timeline
Winter 2021 - Spring 2022
Contribution
UX / UI [0 to 1, End to End]
Hapybara is a start-up founded by 2 young entrepreneurs from Chicago Booth business school and their friends. As avid solo-travelers, they have seen remarkable trends of solo-traveling after the world’s gradual recovery from covid, and opportunities of tapping into this very niche market.
The team was applying for Polsky Center BUILD Accelerator to get fundraising, and was looking to launch a concierge MVP in Chicago by end of 2022.
To understand solo-travelers better, we interviewed 16 solo-travelers, who shared with us their past travel stories, along with how they think their travel experience could be improved.
In a subsequent product workshop, we summarized all the insights we’ve collected and re-categorized them in an afinity map. We have discovered that solo travelers tend to look for travel partners via online forums & platforms, despite rampant frauds & inefficiencies which accompany these platforms. Consequently, lots of concerns focus on safty and social aspects.
Earlier secondary research show that most solo-travelers are in the 25 to 34 year age group. And from our user interview, people who raised concerns on safty and social issues are primarily young females. We believed this is the pain points that our product needs to focus on. As a result, the persona reflects all the typical characters from our early studies.
In the ideation phase, in order to build strong team alignment, we conducted a design workshop in which every team member got fully engaged and brainstormed together. The brief agenda of the workshop is shown as follows:
222.jpg)
The mural board document of the design workshop
At the end of the workshop, we identified 3 design areas/strategies for MVP, which we believed could potentially lead to a better alternatives for finding travel partners, with improved security and compatibility.
Taking the team consensus as guidance, I started by sketching the diagram of information architecture, to see how the system could actually works.
Basic Info and ID verification is asked during onboarding process
Contents are recommended based on info collected from onboarding process
Groups that are exclusive to certain communities can be created
Data collected from review is used to improve group matching function overtime
In order to get actual users’ initial feedback, I developed a low-fi prototype for user testing. At this stage, I paid more attention to the function of the app than the pleasantness of the screens.
The user testing for the wireframe prototype was very successful and shed light on a lot of problems that we hadn’t realized. We recognized its value is far beyond our estimation, so we altered our plan to allow for multiple rounds of user testing.
I would be developing the prototype for one user flow at a time, so that the finished part could be used for testing as I continued working on the rest.
This altered plan has worked extremely well for us. Being able to incorporate multiple rounds of user feedback into the prototype has resulted in a great deal of improvement of the work.
In order to keep track of the users’ perception change between iterations, I set up a testing metrics to quatify the severity of any revealed problem.
The “heat map” below has revealed very interesting pattern. Clearly for the first two design area, it was mostly usability issue, but for the post-trip review portion, users were questioning its usefulness. This indicates necessity to re-evaluate the feature from the product level.
The insights from the participants show that major design problems could be summarized into 3 aspects as follow:
Onboarding / ID Verification: Not friendly, discouraging.
“I feel like I am filling out a form. ”
Compatibility Matching: Too complicated to learn, too many friction
“There are just too many steps before I can finally post groups. ”
Post-Trip Review: Not sure how it’s helpful
“The trip is over and I am unlike to go to the same place again, so why do I need to do the review? ”
Users’ negative perception on matching feature marries with my concern that the current app structure might be too cumbersome as an MVP. After discussion, we decided to trim off the community feature and replace with an extra “Interest Preference” setting.
The refined information architecture is much more simple than what we had and therefore more realistic to build and would hopefully have less cognitive load for users.
Basic Info, interest preference and ID verification is asked during onboarding process
Groups are recommended based on interest preference from onboarding process
Groups that are exclusive to people with certain identities can be created
Data collected from review is used to improve group matching function overtime
As part of the effort, I developed a complete design system for the prototype.
Show only high level buckets first, more details show up depending on the buckets users choose
I informed users all the benefits from filling out the information, and have them learn the core value of hapybara as working on the series of tasks. To further reduce friction, I always keep “skip” option for not-mandatory tasks
When a user post a group, similar ex. groups will show up before user get to the actual post screen.
When a user search existing groups and decide to post one instead, he/she will be directly taken to a screen where the destination and time range has been filled out based on the search content.
Users have the option to only share the group to people with certain identity that they share. The identities users filled out when signing up will become show in here as options.
Based on the feedback we got from user testings and the volumn of MVP, I decided to cancel the “Share” tab and add “Group Notification” feature on the Overview screen.
To respond to users’ comments and improve the correlation between post-trip review and compatibility matching, I decided to have users review people instead of trips. Therefore the reviews could be used as additional factors to improve the accuracy of compatibility matching overtime.
It was very rewarding to see that the testing result for the last round was very positive. Despite some concerns were still remained on the usefulness of post-trip review, the metrics clearly indicate that the prototype has been greatly improved.
Comparison Metrics between Round 1 Testing and Round 4 Testing
Revisit persona
Persona is a useful tool to establish a strong team alignment on product direction.
Always ask the question of “Will the persona be happy about this?” when making design adjustment.
Test early and frequently
User testing is extremely helpful and should be engaged as early as possible.
It’s good to incorporate multiple rounds of testings into design iterations.
Get developer’s insight early
It’s helpful to conduct design workshop with the developer who would later implement the feature.
Define the scope of MVP in the early stage and consider developer’s opinions regarding feasibility.
