Published on | Prototyping: From UX to Front End — Medium Francesco Fiore

Hey, I am Francesco Fiore here, the founder of Blink, you may have read my previous article about how I became obsessed with undiscovered experiences, and I decided to commit to help people finding memorable moments in the places they live or visit.

In this article, I am going to take you through the journey from the product idea, to the first prototypes, how we shipped the iOS beta then reached 15k users over it, to the launch on Product Hunt.

I am going to share my perspective as designer and developer of the project about:

the problem we are solving in short
the assumptions I made about product and tests for each step
the tools I used for prototyping
the tools I used to measure my tests
things that went wrong, errors and successes on the path

In the end, I will share some tips that may help you with your journey from a new idea to the market.

Please note that as part of my method I actively tried to apply the Lean Development Methodology. If you do not know what it is or you just heard about it, I would recommend reading The Lean Startup.

It is time to begin.

The right focus on the problem we’re solving

At first, I set the focus on the problem and customer needs:
Our traveling time is limited, and we want to use it to the best of our chances.

The uses cases we keep in consideration are:

free time trip (half/one day, weekend)
vacation journey (more days to some weeks)

The more the time is limited, the more we worry about missing something, especially if we know we will hit the destination once in our life.

The customer experience of a typical traveler is vast and complex: it includes inspiration, planning, reservations and bookings, transportation, visiting. We are taking care of a specific part of it: we call it the inspiration and exploration.

There were our assumptions on how people are already dealing with the problem:

search and read articles on different blogs and sources (time-consuming, dispersive, uncertain quality)
buy traditional written guides ( boring, outdated, expensive)
ask for advice online and in place (dubious quality, time-consuming)

Field research and how we got strategic insights before building

With field research, we started collecting feedbacks about the problem and how people, outside of our team, face it

How we did it:

Talk to friends and parents
Talk to people during public activities in natural conversations
More structured interviews offline and online

After the first rounds of these quick and easy interviews, we started to realize different types of personas that were responding to our question with some different “skill level” and passion for the problem itself.

We got a bounce of exciting insights:

Passionate travelers 😎 do the job very naturally, and they do it for them and others
A good majority of people skip the process entirely for laziness and just get what it comes 😴
All the people can recognize the difference when they travel with the right information 😍
Food experiences are more important than what we thought 🍔
Traveling is very important and fulfilling for many people 💕
Our assumptions for the existing way of solving the problem were confirmed: web surfing, articles, guides 👍
The pains behind the current solution confirmed: time-wasting and in some case annoying
We found that some people found the research and planning process is so tricky that they hardly can accomplish it 😤

This initial research and analysis could sound a little boring, but it is very important and represents a base of know-how where you can start to build on top.

Based on that I realized that the challenge of creating a successful product was made up of two main parts:

– Create an innovative model to research and organize information
– Design game-changing experience to access the content

We needed to create a product that helps users solve the core of the problem:

gather the best inspiration for what to see / to do once there
be comfortable during the visit with the necessary info ( prices, locations)
understand the local culture, food for example, and find the best spot to try it

To make a remarkable difference compared to the actual process we needed:

to help the user solve the task much quicker
the user should get more than what he was looking for
the experience should be mostly visual
It should be immersive to your destination

Intriguing and challenging stuff eh?

Breaking the world into pieces and creating one system to rule them all

Designing our content model was such an exciting challenge, in this article I will not bother you by going into details, but I will give you an idea of the approach I used.

I started to put every aspect of the context on paper: we had monuments (like Coliseum), attractions of a different sort (places, natural spot), things to do (museums, exhibitions), typical food and cultural trasures, commercial activites like restaurants.

whiteboard madness

I tried to consider and watch the context from different angles to match the intrinsic characteristics of places with the user needs.

A recap of personas, use cases and entities, half in italian sorry

I was looking for the perfect recipe to create order and simplicity of information while preserving the variety of experience and diversity.

I made some iterations and improved the model until, by testing, it satisfied our goals.

We defined our first content entities such as Spots, themed collections of spots, and Guides. We identified that an editorial approach with in-field collaborations was the best solution to start-up the project with the required quality.

Okay! Only once I had a precise idea about the content to organize and display inside the app, I jumped into design and prototyping.

The Prototyping machine 🚂

The first context in the app I had to design was the discovery experience. I had to choose the best format to help the user get through all our content.

First things I did was built something very basic and test it with my colleagues and friends with the focus on content.

I built an Invision interactive prototype in just a few hours using Sketch 💎 as a design tool.

Assumptions and goals behind my first tests:

Test nearby where I live to make it easy ( not a touristic area but still relevant )
Proceed lean, be quick and learn in short iterative cycles

Quick digression over the UI Concept

I was comparing the classic stream concept vs. the tinder-like experience since from the start.

I have found that the normal feed (like facebook or instagram) concept is perfect when you need to give importance to the order of the content, as usually new content goes on top and user can easily understand the chronology. In our case, there is not chronological order, instead I wanted to put emphasis on the discovery feeling , so I chose the tinder-like UI.

These are some of the first mock-ups of the home section.

different mockups, made with Sketch

First round of test and feedbacks

I got some helpful insights about the information that I chose to display, the visual impact.

However, showing just 3–4 contents was not enough. I was getting too much feedback about the graphics and not about the utility. I felt like the test was not relevant. I quickly realized that I needed a functional prototype to test the solution within a realistic context.

🚅 Moving quickly to a functional prototyping approach 🚅

I was excited to start building functional, so I made some consideration for the development stack I wanted to use.

I chose to try first with a web-based prototype for my development experience on it and it’s speed.

I did try Parse.com framework, by Facebook, in the past so I decided to give a try the new open source version of it: Parse Server running on Node.js.

It is a great development framework! I jumped into building the database and a simple CMS to make the content creation possible.

Our CMS for creating a Spot, includes reverse geocoding, google places match, task management and bounce of cool things we made to move fast

With this kind of framework your life is easier and you can just focus on what you need to do and less on how to do it.

For example, you can just type:

var spot = new Spot()
spot.set(‘name’,’The Roman Forum’);
spot.set(‘address’,’Some address, Rome’);
spot.save()

You have saved a new object into the database, quick and straightforward!

Once I got some data, I built the prototype to visualize all the content and add some interactions by using express.js, pug, jquery UI.

Our 2nd round of tests and feedbacks

The prototype with real content was way better, people focused on content, and they started to see the utility and discover new things they wanted to do.

The tinder-like UI built as the web app prototype wasn’t smooth. Drag and drop gestures were not fluid at all on Android browsers.

I could have used a more simple UI like a regular feed just to test the reactions on content, and I could have improved the User Experience later.

The most important thing I realized was the limit of testing on users not hot on the problem.

To improve our learning, I realized that we had to focus on a context where people are naturally facing the problem we are solving.

The way up to a beta on the real market.

We defined Rome as our testing field, a beautiful city, and one of the world leading touristic destination with million tourists every year.

To launch the beta to Rome, we had to:

– Build our first MVP ( Minimum Viable Product )
– Create the contents
– Find a smart way to get users

Your MVP you build it!

I decided to build the MVP personally.
I did not know anything about Swift or iOS development environment. I took some courses on TreeHouse, and I went straight to building it.

Honestly, I had previous experiences on personal projects where I did not have autonomy over the product, and I felt so wrong with it. I did not want anyone to limit my speed and iteration process. Too often developers get lost in building the core experience and then you do not have time or energies to focus on onboarding experience or first usage flows.

I built it from day 0 with the following technical characteristics:

– offline cache for images ( they download the first time than they’re saved)
– redundant data model using MongoDB objects to cut loadings ( 75% less loadings )
– internationalization setup ( multi-language )
– guest experience ( no user required, much more fluid first usage)

After I killed the initial iOS barrier, I started to love Swift and even if I only had web programming skills I was so happy to write every line of code to build my product.

Measuring performance

I used Mixpanel from day zero to carefully measure the usability, and product usage. I defined some key metrics like:

How many times a card is swiped
How many times a card is opened
Session length
Map usage

The most important feature of Mixpanel for me is People profiles with specific usage.
I keep watching every user flow for at least two months.

We created the contents for Rome, it was fun, especially gathering feedbacks from locals and friends and iterating over time.

Finally our Beta was real 😎

With my colleague Francesco Prandi, who joined the project as a marketer, we started to build Instagram communities to create a touchpoint with our potential users.

We ran some tests with paid ads ( less than 200$ / month ) on Facebook and Instagram which were the best way to acquire users on target.

We started to have great reviews and user feedback from the first day.
We focused on improving the onboarding before adding new features.

Product —Growth focus balance

After the first months of learning and prototyping, we started to split our focus from product to acquisition.

We built a simple website to start to get SEO positioning and to have strategic bridge before the mobile experience.

In four months of beta, thanks to our social strategy + ads combined with SEO and ASO kicking off, we able to acquire more than 14k of users on the website and more than 5K active users in the iOS app.

More than 160.000 cards swiped, and we had 5/5 ( ~4.8 ) stars on more than 250 reviews during the beta.

Swipe swipe swipe babe

During the last two weeks we are doubling new users per days after we launched the Android Beta 🤖.

We prototyped itineraries with Framer js and launched them in the iOS version after validating the user interactions. ( The framer prototype )

We had the chance to test one of our business model ideas with Premium Itineraries in Rome with an acceptable conversion rate.
The day we sold the first one was such amazing!

Here is some takeaway from this incredible journey:

– Focus on the problem first
– Test in a relevant context as soon as you can
– Focus on users that feel the problem the most
– Find the best way to be efficient in validating the value you create
– Find teammates that help you move the needle

This was a year of hard work, and our journey is just getting started. The last week we have been a popular upcoming product on Product Hunt, and we are launching this week!

Support our launch — Today we’re LIVE on Product Hunt 🚀

Share your feedbacks 👉 here and get access to an exclusive coupon for your next travels.

Me, my body hairs 🐻, and the app

I’m happy to share more detail with you about the design process, the prototyping, the development if you like send me questions to francesco@blinkapp.it and I’ll try to share more about our journey.

How to build a travel app from a sketch to 15k beta users was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to build a travel app from a sketch to 15k beta users

Cool stuff, every week

More Articles