Stellaroute

Background
Growing up overseas, travel was always a large part of my life. As an adult, I continued to travel and witnessed how the digital transformation affected the travel industry. Very quickly, technology solutions disrupted the utility and logistical-based travel industries including airfare and hotel bookings. These booking engines like Expedia and Kayak were making travel agents obsolete, but one aspect of the travel planning experience that had not been digitized was research and planning. Guidebooks still ruled the day and if you found yourself in a hostel dorm room anytime before the iPhone 5, you’d still see groups of backpackers flipping through Lonely Planets and Rough Guides planning their next moves.

To demonstrate how strong this industry seemed, the BBC bought an initial 75% stake in Lonely Planet in 2007 and continued to see profits through 2011 when they acquired the remaining 25% for a combined amount of £130 million. In 2013, just two years later, the BBC divested itself of all holdings for £50 million for a whopping loss of £80 million ($125 million).

Unlike ride sharing cutting into taxis or Airbnb cutting into hotels, there was no single company or solution that usurped the former market leader. Instead, in the decline of guidebooks, travelers have turned to creating patchwork solutions, relying on the likes of TripAdvisor, recommendations, and local blogs to plan their trips. We thought we could create a solution for the new generation of traveler.

Problem
We had a grasp of the general problem. There wasn’t a single platform or product where a curious traveler could go to plan their trip. The user had to compile information from numerous sources and, as a result, their level of confidence when finally booking was relatively low. However, we didn’t know where to begin crafting a solution.

We quickly discovered that one of the reasons a solution hadn’t successfully entered the market was that millennials were wary of paying the $25-$35 price tag a guidebook normally went for. Yet, despite their unwillingness to pay the modern traveler wants better, personalized information for cheaper. We wanted to find a way to provide the market with that solution. We couldn’t simply put guidebooks online, we needed something a modern traveler could truly engage with. We needed this product to be:

• Easy for the user to find personalized information

• Easy for content creators to add new content

• Scalable and repeatable for different type of destinations around the world (cities, national parks, countries, etc.)

User Interviews and an Initial Concept
Before spending time and money creating the application, we needed to make sure that there was actually a market for what we were building. I initially held a number of 60-minute, qualitative interviews to try and identify pain points in the market and really focus in on a potential solution. I confirmed that people were, indeed, frustrated. Guidebooks absolutely didn’t meet the user’s need anymore. Being the information age, a modern traveler’s expectation is to have detailed information, personalized to their travel style (foodie, adventurer, intellectual, etc.). People didn’t need a guidebook to tell them to go to the Eiffel Tower, what they want(ed) to know is what arrondissement in Paris is best for boutique shopping, or which market in Bangkok is going to have the best street food. And modern solutions, like TripAdvisor, still didn’t provide that.

These interviews confirmed some assumptions, shattered others, and really pointed us towards a specific direction. Our concept for a solution became the “Spotify for travel.” Spotify addressed a problem that people had been solving offline for decades. Once cassettes and CDs hit the market, people had been creating playlists for their crushes, road trip, workouts, and more; except they were doing in manually. Spotify allowed users to create digital playlists in minutes and send it out into the world. We wanted to do the same thing, except instead of music we wanted to use that concept for travel itineraries.

Wireframing & Testing
The goal was to create a software that would allow us to seed the platform with reusable, crowd-source data elements that would quickly provide value for early adopters while also allowing us the room to scale.

We needed two features, a data creation flow and an itinerary building engine. We focused on proving the usefulness of the itinerary builder and created some simple wireframes reflecting our research. I wireframed a low-fidelity “create-your-own” guide on Moqups to test with our target audience and uploaded it to InVision to create a clickable prototype.

We then did dozens of guerrilla tests. We went to college campuses and coffee shops to ask students and young professionals (our target market) if they would be willing to do 5-minutes of user testing. We found some immediate friction points in our design, but had otherwise proven that the concept had a potential market. We iterated constantly, sometimes in the student centers and coffee shops before in between tests.

One reason you’re seeing colorful low-fidelity wireframes is that, while color tends to be a distraction, in this case the lack of color was throwing off our users. Inevitably the first piece of feedback we heard was, “why isn’t there color?” We added some color and immediately the user started focusing on the test rather than the aesthetics.

The Information Architecture Challenge
We needed to create a framework to allow these content creators to create different types of custom guides while keeping a consistent user experience across guide types. We needed an information architecture that would allow us to create guides across neighborhoods, cities, regions, and even countries. Adding another layer of complexity, we wanted to have both Chronological and List guides (an hour-by-hour guide to a city vs a “best of” list of restaurants or vintage stores).

In the end, we built an information architecture hierarchy that I am incredibly proud of. It ended up fitting every variable we accounted for. We identified nine-levels of guides that would build on each other and allow for flexible usage and ended up creating both chronological and list guides on the platform. However, it was overly complicated, unintuitive, and never proved to be particularly useful to the users at an early stage.

Marketing & A/B Testing
Once we had a working beta product, we needed to market it to get early adopters. This proved to be an entirely different design challenge, as I had to build splash pages for Facebook and Instagram that would attract different types of travelers. We designed different ads and signup forms for travelers falling into a number of different categories including foodies, adventure travelers, backpackers, beach bums, etc. We ended up attracting enough users to seed numerous destinations.

Failures
I’m very proud of what we built together. We successfully created a responsive web app that worked well on both desktop and mobile, allowing users to take these guides with them as they traveled. In the end, however, we failed. And there were some massive lessons learned.

• We tested our wireframes too much, and didn’t test our production until it was too late. We got enough data points during the user interviews and user testing to argue that every possible feature was critical for our MVP. As a result, we overbuilt our MVP and by the time we had enough data to focus in on a single feature, our runway had disappeared.

• We thought we were our own users. We didn’t realize that this was a huge trap for passion projects, but as much as we told ourselves that we were focusing on our user, we ended up building a tool for ourselves. Unfortunately, we were power users. Like most products, power users use 90% of the functionality, but make up 10% of the users. We needed the 90% of users who would use 10% of the features.

• As a result of both of the above, we overbuilt too soon.

While we did gain some traction, we weren’t able to get the volume of free or paid users to justify continuing with the project.