When we launched Tripnary v1.0 we went the extra mile to make sure we tracked every possible user interaction in the app so that we don’t make the mistake of building something that the users don’t want. Our advisors often asked “What part of the app is used most?” and suggested that we focus the product where users are already spending the most time. Makes sense right! Let the voice of the customer guide the roadmap.
But we resisted.
Tripnary quickly reached a million swipes, people even called us “Tinder for travel”.
This was all very encouraging, but most people were using the app to create bucket lists and few were comparing flights — what we considered the USP of the app. With Tripnary, our goal is not only to help you build your travel bucket list but make it actionable too. We are building an app that helps you decide your next destination from your bucket list based on your budget. There are many apps that let you create a rudimentary list of places you want to go (Tripadvisor, Gogobot), but from the beginning Tripnary’s objective was to help you make this a reality. Why? Because we know that leisure travelers are constrained by their budget and dates, but are flexible about where they can go.
So even though our roadmap was obvious based on user data, we always asked ourselves, if that’s the path we wanted to take.
Don’t just end up acting on symptoms when the root cause of a problem remains unaddressed…
We quickly realized that we need to be careful with early data as it can both help and hinder you. Sometimes early data can tease you with interesting metrics, but may lack any meaningful insights. The danger with obsessing over every interaction the user performs based on early metrics is that you feel the need to start pivoting your product based on this data.
We got users started with creating their bucket list. We saw users getting hooked to the Tinder-esque swipe to add places to their bucket list. Some people spent upwards of two hours (!) doing this. With Tripnary, it would have been easy to build more features around mindlessly swiping places. Creating and sharing lists of places is fun for a while, but it’s not something that hooks the user in the long term. Had we done this, we would end up prematurely acting on symptoms when the root cause of a problem remained unaddressed. So we had to look deeper.
Users engage most with the first screen they see when launching the app, and it should emphasize the core benefits for both new and regular visitors. New users will judge the book by its cover. They have a shorter attention span and want to understand what the app does quickly. Users return to the app because they like the value proposition you are selling. If you make it hard for either of them to get the core value of the app, you will win neither of them.
While we became very successful in driving engagement by teasing beautiful pictures and building an addictive interface, the core functionality of quick flight price comparison got embedded within the app with a boring interface. So even though our Tinder swipe was the most flauntable metric, we knew this is just a side-effect of the way we designed the app.
Success is dependent upon asking the right questions…
In the early stages, what’s more important is to discover inconsistencies in the data relative to your hypothesis. For example, we believed that Tripnary users would spend almost equal amounts of time on the three key screens of the app. But, we were obviously surprised after seeing the actual usage. Before focusing on new ideas, we had to first make sense of the inconsistencies.
Because people loved swiping to build their bucket list on Tripnary, it would have been easy to fall into the trap of pivoting. You will similarly get the urge to pivot or add new features based on few weeks of data. Fight it. Fight it hard. You built a product based on a problem you identified. Now it is entirely possible that the problem is not that severe, or affects a very small number of people for it to be a meaningful business, or even that your product is ahead of its time. All of these are possibilities and could quickly kill your your startup. But you can only consider these possibilities once you have questioned your current product’s viability under many scenarios. The most dangerous thing to do is to quickly pivot the core of the product based on early data. That’s the fastest way to “kill” your startup — once you have pivoted away from your original idea/problem/solution, it’s effectively dead, isn’t it?
In Tripnary’s case, we headed back to the drawing board and outlined all the things that created friction in communicating the core value of the app. Instead of asking what’s the most used part of the app, we asked why are people not performing the action we wanted/expected them to (comparing flights)? Basically, if you don’t ask the right questions, at best, you discover nothing and, at worst, you derive the wrong insights.
So in early stages of product development, your focus must only be to minimize any friction between users and your product’s intended goal, instead of getting distracted with new features, or in-depth analysis of metrics you have gathered. To be sure, I am not suggesting that you ignore the data. Far from it. It’s hip to claim you are a data-driven company. Just be cautious of using data to drive your product too early.
A design isn’t finished until somebody is using it…
So all of this is a long-winded way of saying that it’s necessary to take a hard look at your product – it’s possible that you have identified a genuine problem, you have a killer solution, but maybe the UX is lacking. Are there any gaps in the design to be plugged to drive users to your intended action or to amplify the value proposition? Focus on the design and user experience before focusing on features and pivots. With Tripnary, we unintentionally pushed the user to spend more time browsing and swiping places instead of designing a clear path to make their bucket list actionable.
So as we continue to learn and evolve Tripnary, we are taking a decidedly data-with-a-spoonful-of-salt driven approach to refine the app. Here is a sneak peek of what’s coming in the next big app update.
Even though there are still a few iterations left on the UX, you can start to see the direction we are taking.
We had to strengthen the link between bucket list creation and flight comparison. So, we boiled down a three screen workflow to two conjoined screens. Because our goal is to help users compare fares to several relevant places easily, we will be de-emphasizing browsing and recommendations a bit more in subsequent versions, in favor of something way more exciting. Now what could be more exciting than swiping left and right? Stay tuned! Spoilers are no fun 😉
Until then, check out Tripnary. Trying to decide where to go your next vacation based on your budget? We are here to help! We know the importance of user experience, so your feedback there will be especially appreciated!
Big thanks to Nick Vivion for helping make this post awesome.