Our Project: Commuter Crony is an inexpensive way to help daily commuters drive safer by educating, motivating, and helping users to not speed. Our app provides real-time driving notifications that alert users when they are driving too fast and also gives post-driving feedback by providing users with a driving score that incorporates not only the average driving speed in relation to flow of traffic, but also the frequency of sharp turns, sudden stops, and sudden accelerations.
Brainstorming: Throwing out ideas, choosing one idea, zooming in on the issue.
In the very beginning processes of our brainstorm, we threw out tons and tons of different ideas for apps. We wrote and drew our different ideas on sticky notes, putting them up on a wall.
Afterwards, we grouped all our similar ideas into categories and chose the top three ideas we had to flush out a little more in-depth, thinking about the specific target user group, the problem at hand, and ways in which we could potentially solve the issue. Finally, from these three ideas, we chose to build the app “Commuter Crony” and began looking at our competitors and also running contextual inquiries for our app.
Competitive Analysis: There are some apps out in the market space right now, but they’re not sufficient enough to put a dent in the problem.
The following is a screenshot of the iSpeedCam app.
The iSpeedCam is a mobile app that looks pretty cool at a glance. However, it lacks complete road data and thus requires the user to input their own speed limits for roads, which is not only inconvenient, but also pretty unfeasible. In addition, for this app the user to get notifications that require user input, which is extremely dangerous while driving.
Another app is PebbSpeed, which is shown below.
This app has functionality for the user to set a single max speed limit. The app then notifies the user when they drive faster than that particular speed. However, it’s pretty unrealistic, because on any given commute, a user will drive through roads of all different kinds of speed limits.
Finally, a third competitor is SpeedForWear.
This wearable app is able to show you your speed and your max speed. However, its too simple – it’s basically a speedometer and doesn’t give you any information about what the current speed limit is. Furthermore, it doesn’t make any sense for a driver to look at their watch to see the current speed when they can simply look at the speedometer on their car.
User Studies, Details, and Findings: From our very first contextual inquiry, to the last user prototype, we received and incorporated a lot of feedback from people we interviewed, as well as from our peers and instructors.
Through research, user studies, and feedback, here are a few of our findings:
1.) Speeding is a huge problem in America
We did some research on the issue of speeding, and to summarize, we found that speeding is the number one cause of death on the roads and that speeding is a very prevalent problem. A summary of stats that we found are that:
- 112,000 people in America receive speeding tickets/day
- $152 avg cost of a speeding ticket
- 41 million speeding tickets/year
- $6,232,000,000 revenue from speeding tickets/year
In short, speeding is a dangerous and costly issue for many people that can be avoided.
2.) People don't think that speeding is a big deal.
Originally, our target user group was for drivers who have to take long commutes often but want to drive to work safely. Through more discussion and researching information online, we saw that the biggest two problems for commuters were speeding and drowsy driving. Although we wanted to address both issues, we decided to zoom in and focus on one of them for the app. From our contextual inquiry, we found out that most people don’t even view speeding as that big of a problem. One person we interviewed said, “I often go faster than the speed limit on my way to work”. Another said in passing that “driving 15 mph above the speed limit isn’t that big of a deal”. This wasn’t consistent with the statistics that we had researched (which said that speeding was a big deal), which was why we decided to focus on the problem of speeding.
We had also researched statistics that said that "90% of drivers think that they're better-than-average drivers". Clearly, 90% of people cannot be better than average, which means many people are deluded about the quality of their driving. It was a challenge thinking of how we could help people (who for the most part don't think they need any help) improve their driving.
3.) People want an app that is easy to use, not distracting, and would provide accurate feedback.
From our contextual inquiry, we found that users would want the app to be easy to use (very intuitive and doesn't require any training) and also a minimal level of distraction (unintrusive). One person we interviewed even mentioned how she would even get annoyed at Google Maps talking to her sometimes because it was telling her where to go even though she already knew the way. Another person also mentioned the dangers of being distracted from the road while driving because of the watch.
Another person said that they know so many really bad drivers who think that they're good at driving and that it would be "pretty cool to get objective personalized data for how people actually drive". We thus really wanted to incorporate into our app some way in which a driving score could be generated that would accurately reflect the driving quality of a user.
4.) People didn't think that our app would be able to do much to prevent speeding.
Initially, we decided that the way that we would approach our app and solve our problem would be to educate users through some kind of "facts and tips" about the dangers of speeding, sustain their motivation to not speed through gamification of the app with clear steps that they can take to improve their driving score, and also to help the users to not speed through real-time notifications when they actually are speeding.
After our initial presentation, one of our peers gave us feedback saying, "I'm not sure if this is a problem that is solvable. I don’t know if people that like to speed would ever download an app like this." This concern made sense, and we thought of potential things we would be able to do to further incentivize users to not speed and also to download our app in the first place.
One idea was to partner with insurance companies so that our app users would be able to get certain discounts on car insurance if they are able to have a certain level of driving quality. With this in mind, we wanted our app to have a single driving score that would incorporates not only the average driving speed in relation to flow of traffic, but also the frequency of sharp turns, sudden stops, and sudden accelerations.
Another idea that would cause users to use our app is if we partnered with the government so that when a driver gets a speeding ticket, instead of going to driving school (which is long, tedious, and often an ineffective way to prevent speeding again) the driver would have the option to use our app instead and maintain a particular driving quality for a certain period of time.
Wireframes: We started off one of our first wireframes with a simple sketch of the different pages we wanted our app to have and through many iterations expanded it for a complete interaction flow that included the wear and background services
This is one of the early sketches of our app that we did together on large post-its. We first drew out all the different pages we wanted and determined the interaction flow between the pages.
Later in the process, we also added a more comprehensive wireframe that included Wear interactions and also background services that would run in the background.
Intermediate/Final Design Sketches, Variations, and Ideas + Final Design
Changes to the "Facts and Tips" Section
One of our first prototypes for the Wearable "Facts and Tips" section was the following:
We then digitalized it. The idea was to click the "Did You Know" section on the watch and then “I don’t anyone will ever use the ‘facts and tips’ or the ‘analysis’.
However, we ended up completely taking out he "Facts and Tips" section from the wear completely because people said it would be inconvenient and too hard to read on such a small screen.
We took out the "Facts and Tips" section from the menu and instead placed it instead on the loading screen when you first enter the app because people said that they were unlikely to specifically go to the "Facts and Tips" section to read tips unless they were really, really bored.
This is what hi-fi prototype of what our "Facts and Tips" section originally looked like (you would access it from the menu bar on the side).
Here is what our "Facts and Tips" feature now looks like. It is no longer a section, but rather simply part of the loading screen when the app is first opened.
Changes to Make the Watch Design More Visually Appealing
One feedback we received was to our notifications on the wear was "probably reconsider the color choice. The watch app color theme is not so aesthetically pleasing”. Thus, we changed the watch color and design to make it look more visually appealing. Also, to make the watch more cohesive with our UI, we made the notification a simple notification card and "Slow down!" in big words.
Here are some early prototypes:
Another feedback we received was that having different notifications for driving past the flow of traffic and one for speeding was a little confusing, so another design choice we made was to merge these two "different" notifications into one notification that said "Slow down". However, the
This is our final design for a notification:
Changes to the Data Visualization
This was an early prototype that we had for our driving data:
Here's a more hi-fi prototype that we had.
However, because people said they wanted more interaction with the app, we made it so that users can change what kind of data is shown on the graph. Also, the the different "Driving Quality" values (ie Sharp Turn, Sudden Stop, etc.) are clickable and can also be reset.
Technical Challenges: We encountered many technical challenges throughout the development of our app, including making a dynamic graph, API calls, and also figuring out what the different sensor values meant in real life.
1.) First of all, making the graph dynamic was very time consuming. Once we got the graph set up, it was pretty straightforward to add different values and change the layout. However, setting up the graph in order to make it dynamic was difficult because we were unfamiliar with the mechanics behind it. In addition, if we wanted the graph to show more than just the day the infraction occurred (like instead showing the time of day, or week, etc), it required a lot more tweaking to not only display but give the user the chance to pick what they want to see.
2.) It was also difficult to make the API calls in the background. It required a lot of reading and re-reading API documents and tutorials over and over. Many of the services we looked into provided a variety of services and it took awhile to narrow down exactly what we needed to get and how we would get it. This was also difficult to test - we could only make the phone "travel" so much and so fast when testing on an actual device. We could not exactly test speeding because that would mean we would have to break the law, not to mention having this kind of distraction while driving is not a smart idea. We ended up getting around this by finding a "mock location" feature of android and then using that to fake locations and then testing the speed limit breaking saying the speed limit was always 5mph (so going normal speed would mean we "broke" the speed limit).
3.) Finally, there was a lot of trial and error trying to figure out what types of type of sensors (ie accelerometer and location) would accurately reflect attributes of driving such as sudden stops, sharp turns, or sudden accelerations. There are a lot of different factors that go into each of these and the fact that they do have a lot of overlap did not help. Also because we were pulling information from many different sources (accelerometer on watch, location on phone, etc), being able to compile them all in a single spot was another unforeseen difficulty. In addition, figuring out how all of these would come into play to reflect a single accurate driving quality score was also quite hard and seemingly subjective at times.
Personas and Scenarios: These are 2 example personas and scenarios of users who would potentially use our app.
1.) This is Amy. She just graduated is nervous about starting her new job, which she has to drive about 30 minutes every day to get to. It's her first time being completely independent and supporting herself financially, and she wants to take advantage of any opportunity to save money on living expenses, including car insurance.
Amy heard from her friend that if she downloads CommuterCronny and maintains a score of 80 or above she can get a discount on car insurance. She tries out the app for the first time. She sees the Commuter Cronny loading screen with a random fact on the top. Driving to work one day, she goes slightly faster than the speed limit, and her watch gives her a notification about it. Knowing that she has to keep her score low in order to get a discount on car insurance, she immediately slows down even though she was thinking about cutting off the car next to her.
2.) This is Bob. He is a father of 2 and thinks that his driving is quite superb.
One day he was playing around with his new wearable moto 360 and stumbles upon the CommuterCronny app. He didn't really want to use the speeding part of the app because he thought that receiving notifications would be annoying, but he was curious about the analytics for the app. He drove to work and after he finished driving, he looked at his phone, seeing that he had made one sharp turn and one sudden stop and because of it his driving score had gone down a little bit. Impressed that the app actually caught the data because he remembered exactly where the sharp turn and sudden stop was, he slipped his phone back into his pocket as he badged into his building at work. Later in the day, he would show his wife the objective score of 95 of to prove to her what a good driving he was.
Summary of Project
Our app, CommuterCrony, is a step towards making our roads safer. It's a simple and inexpensive way for users to receive real time warnings for when they are driving dangerously and also to view analytics of their driving. CommuterCrony is committed to educate, motivate, and help people avoid speeding and become better drivers overall.
Presentation Slides
Final Video Link
Code Repository
http://www.bitbucket.org/qwertyrit/incognito_group25
Comments