Uberlytics: When is the best time to take an uber?
costs, and as we didn’t have a car that meant Uber. Los Angeles is notorious for bad traffic, and that’s not good when you’re only option for travel is Uber. We wanted to know when and where the heaviest parts of traffic, so we could plan our travels around those times. However, there was no databases or any relevant information online and so we just approximated to 10 o’clock and 8 to 9 o’clock, basically just guessing when we thought rush hours would be gone. This worked out for the most part, but we definitely cut it close. However, this problem stuck with me, and if I was going to plan spontaneous trips later, I wanted something that would reliably tell me when traffic was heavy and Uber was surging.
Fast forward to summer. I come back to California and three of my friends, who were studying computer science in Purdue University, were in search of project for the summer. And the idea of a service that predicted Uber surge prices was rekindled, and this time I had a team to do it. And so we set to work in mid July to make this a reality.
Story time.
In spring break of 2016, a few friends and I were feeling spontaneous and decided to take a trip to Los Angeles. Now, being the most brilliant thinkers on the planet, we bought the plane tickets without too much thought of where we were going to be staying, how we were going to get from place to place, and what we were going to eat. But of course we had one hour before our flight left, and a whole plane flight to plan that out.
Now being students we were all on a pretty tight budget and so we wanted to best predict how much we really were going to spend on this trip. When it comes to budgeting, there are a few things that I like to call constants, controls, and variables. For example, airfare is a constant: it was going to take x amount of money to get there, and there was nothing we could do about it. Same with our Airbnb, we knew exactly how long we were staying and how much our stay was going to cost. Controls are things that are, more or less, in my personal control. For example, food. I can base my budget on decisions of where to eat out, or when to stay in and cook from our Airbnb. This part of the budget is flexible and predictable. One thing which was a variable was travel
Initial Assumptions, Research, and Ideation
The first question we asked was how were people going to use this? Our first natural reaction was to make an app. But after researching an app methodology approach we found a few points against using an app.
The picture to the right is our team's initial ideation and brainstorming. We first clarified our "Point of View" statement as well as constructed a "How Might We?" while exploring ideas and examining our research.
1. What do people first do when they encounter a problem? They go to the internet not the app store. In terms of marketing and reachability. Having an internet service would allow us to catch the “surge pricing for x city times” google searches.
2. Apps have to be downloaded. This is a huge barrier to entry. Also our service is what I would call a “one time use” application. People would go to it when they are in need, but never need when they weren’t. It’s only useful in the moment. Having a user download an app requires a more permanent commitment to a service, something that the problem really needed.
3. Cellular Data. In our research we found many users use Uber on the go. This means that many of them are using cellular data, and not every one has unlimited. I found that many of the participants were unwilling to download an app even if they needed it solely because they had a constraint on how much they could download. If we wanted this service to be accessible to on the go, we couldn’t expect people to download an app.
Let's make a website
With these particular pain points, we looked to other platforms that achieve the same goal as an app but solved these problems. And so we decided to do a website. Websites are easy to find with a single Google search, meaning people could get to our service that fits in line with their problem solving response. Websites evidently don’t have to be downloaded which solves our one time use purpose and conserves peoples data usage. What we realized is that asking “How were people going to use this?” was a little narrow of a scope. What our research told us was to think of it as, “How do people solve problems on the go?”. This question I would use later on to pose and think about our future design problems.
Iterations and Finals
Iteration progression for website header.
Iteration progression for location search.
Location, Location, Location
So once people go to our website. How were they going to use it? To answer that we need to see how people used Uber. We found that majority of people use Uber on the go. It’s unplanned and usually unscheduled. So the most logic path was to use the users current location which is a good start. But what about the users who wanted a specific location, like what I needed in my trip to Los Angeles? So in our earlier designs we just had the user type in their whole location. However, problem with that is that people on the go don’t know their whole location. But what is easy to find out no matter where you are is the street you are on. There are conveniently signs at every intersection to tell you where you are no matter if you don’t know where you are. So in the end we still allow people to set their current location as the data point but also, if they can’t set their current location for whatever reason, or if they aren’t at the place of interest they can simply find the closest intersection and enter that in.
Entering in intersections also massively helped out the backend side. According to the Uber Rides API, surge pricing is dictated
by starting location and by area. Later, when we would start collecting data pointswe would need set locations to pull the data from to know exactly what were the “areas” that Uber had staked out. Collecting data at each and every intersection, while also keeping the users inputs being intersections massively cut the need of a complicated search engine, while also giving us the very accurate data that we needed to accurately predict and collect the Uber surge data.
Full Page Overview
Final Thoughts
In terms of design, this was the first interface I ever designed for the web. And it took a while to understand how the website should flow. I’m used to designing for mobile screens, and learning new conventions, and new proportions to work with was definitely challenging. A few things I think I could really improve would be the logo. This was also the first logo I actually tried making and I’m not that happy with it. It seems just a little too simplistic and I feel it lacks character. However, as a first attempt at a website and a logo I’m pretty pleased with the results and can’t wait for the full version to be up on the web.
Honestly, this was a challenging project for all of us. It’s always hard to work with friends, especially in the summer, but it definitely was a good experience. You can view the live website here: https://www.uberlyticsofficial.xyz. However, the developers are currently working on implementing the latest designs of the website, so the current design is an old and simplified iteration. Also we currently don’t have a web server collecting the data, so the data is just dummy data, but I’m told it does work as long as we have a server collecting data.
Credit
Team
Vincent Jiang
Matthew Farmer
Peter Farmer
Aneesh Vemptay
Project Duration
8 weeks
My Role
Project Lead
UI/UX Design
Information Architecture