One of the most popular mobile apps today is UBER. In a short time, this revolutionary ride sharing app has managed to disrupt and transform the taxi business in most major cities.

Thanks to the ability to be able to rate your experience, you no longer have to put up with rude and unkempt cab drivers who drive like lead-footed maniacs in dirty unsafe cars. You no longer have to settle for whatever vehicle the cab drive shows up with. Now with ride sharing apps like UBER, you can actually custom order the type of vehicle you want. 

Why I Decided to Prototype the UBER App

As a prototype engineer I was looking for a challenge I could do in my spare time. I wanted to create something that pushed the versatile web based prototyping tool to its limits. I was also looking for something interesting and exciting that I could post on to Spaces — the new interactive gallery where creators can post their prototypes for the public to experience. I wanted to go beyond just making a simple app demo and instead wanted to show people that you could create a full and robust app simulation with

So I decided to prototype the UBER app. This app pushed all of the tech buttons for me. It’s a state of the art app that has many features that show the power of what is possible using today’s smartphone technology. I felt if I could successfully simulate the UBER app it would be a great way to show people what they can achieve with and it would help to promote my mobile prototyping business.

The Art of Prototyping

Before I start it’s important to talk about the art of prototyping. Creating a prototype is not the same as creating an actual application. Mobile prototyping is all about creating illusion. It’s like a magic show where the audience only sees what you want them to see.

As a prototype engineer, my job is to simulate the look and feel of a proposed application. This proposed application comes to me from our clients often in text form, or in hand scrawled sketches or if I am lucky in full blown design documents complete with mockups of every screen.

Having a prototype is invaluable for new app startup companies and even big established companies as it allows you to validate the assumptions you are making about your proposed app without spending hundreds of thousands of dollars in development costs. Using a prototyping tool like allows you to take user feedback and make changes very quickly.

The beauty of is that they have an actual app of their own that allows you to log on and load up your prototype onto your mobile device. Once it is loaded, you don’t even need to be connected to the Internet to test your prototype.

Pro Tip

One thing I learned very quickly as a video game designer for the small handheld devices like the Nintendo GBA and Nintendo DS is that testing on your target device is crucial for evaluating the user experience. Often clients will create prototypes using the web editor and then when they actually test it on the target device they can’t read menu items because they are too small. What looks good on the web may not look good on the target device. Do yourself a favor and save yourself a lot of time and trouble: test your prototype on your target device as often as possible.

The Benefits of a Digital Prototype

For the new startup client, the difference between having a PowerPoint presentation versus an interactive working prototype is massive. It is a quantum leap for the credibility of your company to be able to show investors a simulation of your app and let them try it out for themselves. Seeing is believing and using something is even better!

Most of the prototypes that we here at ProtoNerds have developed are done with the purpose of showing a complete vertical slice of the user experience for one particular feature; this is usually the key feature and demonstrates the central proposition that the proposed app is seeking to achieve.

For example we created a prototype for a Canadian firm that allowed spectators as a sporting event the ability to order food and drink. We created a few items on the menu and allowed the user to order these items and the app calculated the total and sent the order to the concession at the stadium. The prototype was a success because it managed to simulate what the app was intended to do and most importantly it simulated the actual user experience of a spectator ordering food using an app at a sporting event.

The Journey Begins

Before you start on a journey you need to figure out where you want to go. So I decided to research my destination which of course was the UBER app. Planning to prototype the UBER app is like going to an amusement park. There is just too much to do at most amusement parks so you need to be selective and plan in advance of which attractions you will visit. UBER is the same; there are many features in the app that can be simulated but I had to decide which ones I would demonstrate and which ones to leave out.

To be able to make this determination, I needed to know everything about it, how it works, what the user experience is like.  Even though I had heard many things about it, I hadn’t actually used UBER until I decided to prototype it.

When you analyze an app from a design and prototyping perspective, you need to push, poke, prod and test everything on the screen. You need to understand what you are up against so you can plan how to proceed. Failure to do so may end up in surprises down the road when you find additional functionality in the app that you didn’t plan to recreate in the prototype.

Every area on an app screen needs to be tapped and swiped in order to see what treasures of interactivity will be found. In UBER every icon and ever user interface element has some kind of functionality and a purpose. Even the icons in UBER footer menu where you select the various UBER cars have multiple functions.

Determining the Roadmap

I knew that I could not recreate the entire UBER app as that would take far too long, so I knew I would have to be selective about what I wanted to demonstrate. I did know that from the start that I wanted to recreate the most fundamental proposition of UBER: what it would be like for a UBER user to order a car.

I also decided that I would allow the user to order four different vehicles: UberX, Black Car, SUV and Taxi. My next decision was: how many of each vehicle should I show on the screen at once? I decided that I would have 5-4 cars of each vehicle all driving around the core of a city. Each vehicle would have to have it’s own travel route on the map.

I knew that I  would need a city for the car and figured that the iconic hub of the startup world — San Francisco — was the natural choice. Since the Google map scrolls indefinitely, I had to confine the map used in my prototype to downtown San Francisco.

One problem that came up was that as I was developing the UBER prototype, I was using the assets gleaned from screenshots from my Galaxy Note 2 Android smartphone. I assumed that the Seattle version of UBER was the same same as the San Francisco version. Not so. I found out that there were some differences: the selection of vehicle choices was different. In Seattle they have “For Hire” cars and in SF they have “Taxi” cars. Other differences were that there is a peak time feature where because of high demand fares go up.

Resolving the differences between the Seattle version of UBER with the San Francisco version ended up adding more time to the project.

Challenge #1: The Footer Menu

One of the biggest challenges for me was to recreate the functionality of the UBER footer menu. The footer area is the main user interface of the app. The car select button can be dragged to any one of 4 locations. Additional menu options are also displayed depending on which car you select. There is also a function where the button will “snap” back to the closest button resting place.

The footer can also be expanded by taping on the button. You can see both footer options in the graphic below:

UBER app footers

The footer button menu was very complicated to script which required the use of computations which used variables. Figuring out the JavaScript logic for this was quite a challenge.

Varaibles has been a very important and welcome addition to the arsental of features. However, using variables for conditional interactions is considered an advanced user feature. The team at will be introducing a more user friendly system of working with conditional variables at some point in the future as part of the roadmap. This will be a very exciting addition to as it will make the simulation of mobile video games much easier to demonstate for those with limited programming knowledge.

Inside Baseball: Footer Button Logic

I did not intend for this article to be a tutorial but I thought it would be valuable to show a brief glimpse of the inner workings of what is capable of. Here is what I needed do to make the draggable button work like it does in the actual UBER app:

Part 1: The first thing I needed to do was to make the button horizontally draggable on the x-axis. Then by using an “on drag”  interaction, I would take the current x-position value of the button and put it into a variable. With a variable we now have a way to compare it to something else. The comparison being the 4 potential resting locations of the button: uberX, Black Car, SUV and Taxi.

Here’s a crude infographic that explains the logic behind this:

Protonerds UBER infographic

Part 2: With a new variable, we then use a “on drag end” interaction to move the button to one of four possible x-axis locations.

Please see the companion video below for more actual behind the scenes footage of this project and the interface.

Challenge #2: Animating the Cars

Seeing the various vehicles in transit swarming around your location before you order your car is one of the charms of UBER. I wanted to simulate this as close as possible to give the prototype user an authentic UBER experience.

To achieve this I would need to create each of the 4 UBER vehicles and make duplicates of them for each vehicle type. Then I would need to place them on the map and give them travel routes.

Animating the cars was a painstaking chore. Every car had to have its own route which meandered through the obtusely unconventional streets of San Francisco. By the end of the process, I had started to regret using San Francisco because very few streets actually go true north, south, west or east and this created a lot of extra work getting the rotation and direction of each car just right.

One all of the vehicles were place on the map and animated properly, they would need to be filtered by turned them off and on depending on which button the user had selected.

One of the problems I encountered early on was that I didn’t use the “states” feature to animate the cars. I used the regular “animate item” feature. The problem was that when you switched screens sometimes the cars would fly off their course. Using the states animation feature within a container would have prevented this from happening as states are 100% persistent as all actions that you script for them are independent of the user switching screens. For example, if you animate a car to go to point A to point B within a container state, it will do so even if you leave the screen the container is on and go to another screen.

I could have used states after finding out this bug but I had already spent a considerable amount of time scripting the cars using the traditional method, so my only solution was to keep the entire app on one screen. This resulted in a very cluttered editor window which you will be able to readily see in the companion video of this project.

Challenge #3: “Your UBER Vehicle is En Route”

The second most important feature of UBER that I wanted to demonstrate is when the user orders the vehicle and what happens while you wait for it to show up at your door. It’s a magical feeling to order your car and see the animated car coming to your destination. As the car gets closer to you, the estimated time starts to tick down. You also get a chance to see what make and model your car will be along with the name and picture of your UBER driver.

Again I needed to animate a vehicle that would eventually arrive at the user’s destination, except this time I needed the vehicle to start at a fixed location on the map. In order to make it interesting for the user I compressed time by reducing a 10 minute ETA to 10 seconds.

This segment of the app is quite a long sequence of events and interactions that is really the meat and potatoes of the user experience. I wanted to make sure that I simulated all of the behaviors of the app even down to how user interface elements would move and fade out. I wanted to make sure I got it right.

My Project Stats

Here are some stats for my project :

2 screens

90 containers

308 assets

120 hours spent

 Video 1 : A Guided Tour of the UBER Prototype

Here’s an unscripted video I created that serves as a guided tour and walkthrough of the various features I scripted into the UBER prototype:


 Video 2 : A Behind the Scenes Look at the UBER Prototype

Here’s another unscripted video I created that gives the viewer a behind the scenes look at the UBER project with some insights and observations about the prototyping process:


The art of prototyping is more than just creating the actual prototype; it is also the planning that comes in advance as well as surmounting the unforeseen obstacles that show up in your path as you progress toward the destination of completion. The prototyping process is about continual testing, validation, iteration and refinement. A good prototype engineer does all of this instinctively and seamlessly.

The prototyping process is a journey of discovery. Like the metaphor of the amusement park, there is considerable planning that must be done before you visit the park in order to get the most enjoyment from your visit. When you get to the park there are unexpected surprises that come up and this reality dictates that you must change your plans. The same is true of the prototyping process as there are issues that you will discover along the way that come up that need to be addressed.

The final tally for hours spent on the project were 120. This prototype would have cost $6000 to create if commissioned by a client. This cost is typical of larger more complex prototype projects given the challenges that they represent. The philosophy of Eric Reis of The Lean Startup Method comes to mind: better to spend $6000 on a digital prototype and fail fast and pivot than to spend $200,000 on an actual app and fail slow and pivot. With each “failure” we get closer to creating the app that will succeed.

Most prototypes that I create for clients take less time to create and as a result cost less because the goal is usually to show just a vertical slice of of the user experience to demonstrate the unique proposition of the proposed app.

Behind the deceptive simplicity of a functional prototype like UBER is a lot of complex scripting. In a world where TV dramas show computer programmers pressing a few keys and producing magical results on the screen, sometimes clients who have no experience with design, programming and scripting have unrealistic expectations about the costs associated with advanced prototype development.

One of the realities of prototype development is that as the complexity of the project increases, the labor expended goes up almost exponentially. More complexity equals more assets and more interactions which all have to be managed and accounted for in the scripting process. Despite the fact that is an amazing prototyping tool that has saved startups and established companies hundreds of thousands of dollars in development costs, there are certain realities, limitations and constants that will always be inherent in the prototyping process. Anything of value takes hard work to produce and you get what you pay for.

It’s hard for me to imagine a world of mobile and tablet development without an indispensable prototyping tool like Special thanks to Alexis, Akis, Anna and the phenomenal team at for all their amazing ideas and support. Thanks to UBER for making a great app that I could turn into a prototype.