Commutenity: A Community of Commuters


I have a big family. Big enough for us all not to fit in a single car. And I have extended family around the town too. We love to go out to the movies together. So we all meet at home, split ourselves into the 3 available cars and decide to meet at the theatre. Coordinating all the three cars, like I’m sure you know, is pretty much a nightmare. Everyone calling each other, figuring out routes to the theatre, someone often gets stuck at a redlight and can’t pick up their phone and by the time we get in touch with them we are late for the movie. There isn’t one simple way to solve this, but I was determined to put us out of the misery of missing the first 15 minutes of the movie and my chance to pick up some popcorn before it started. That’s when I chose to design Commutenity.  

Problem Space               

The design in this report describes a platform for “Commute Communities”, i.e. a social network for people who commute. The main kind of interaction it supports is that between different cars, travelling from the same start location to the same destination. The cars between which the communication channels are created are all known to each other (not with strangers in different cars on the same route). The aim of this design is to help these multiple drivers coordinate their travel with each other during the drive.

Research work: 2 telephonic interviews and a few more online surveys

Role in Project: This was a completely individual project conceptualised and designed by me

Skiils: Telephonic interviews, online surveys, Sketch 3, low fidelity paper prototypes

As a result of the initial research on the behaviours of drivers, I interpreted that the system should:

  • Give them all the information they need while driving, without them having to look for it.

  • Present information to them in a way that is most intuitive, and easy to use while they are driving

  • Augment and capitalize on a natural channel of communication so that they do not have to learn how to use a new interface in a different way


Initial Paper Prototypes:


So to sum it up, these are the kinds of interactions I deemed possible between the driver (user) and the system:

Information received by User (System -> User communication)

  • if anyone’s car broke down/stopped

  • Notification if I deviated off the normal prescribed route eventually leading to reprogramming my path (like usual mapp apps). Also, ask first if i should send a re-route notification to other drivers in the group.

  • Notification of anyone else in front of me re-routing. The system also should ask if I want to change my path to match theirs.

  • Request for solution/change in paths due to our own car’s telemetry

    • Low gas reading: Suggest route changes that pass by a gas station by calculating how far away the gas station should be, given the gas level of the car currently. and it’s mileage. If one person accepts this route update, then notify others of the route update and the reason.

    • Verbally notify the user if he is within the speed limit for the kind of road he is on. This is also useful when driving cross-state or inter country, where speed limits and road rules might change. Another application of this is when using this system for racing vehicles in a group, to make sure that people do so without exceeding speed limits.

  • Voice notes on dropped pins on the map, by other users

  • Generic voice broadcast messages to the group.

Information sent by user (User -> System communication)

  • Voice notes dropped on map pin locations for other drivers. If one driver reaches point A on the map first, and drops a pin, for example, “There is a toll booth here, but there is no sign board. So get ready with $3!”. When the next driver is approaching this dropped pin, the systems plays back, or notifies him of the voice note left behind by the first driver.

  • Broadcast voice messages to all the other drivers in the group, that do not depend on a dropped pin. This could be any sort of generic information or communication. I like to think of it as walkie-talkie style communication taht is activated/sent only when required, and is not like being on a conference call that is permanently running and switched on.

  • Yes/No answers to accept re-routes or other suggestions that the system might offer the user. Possible questions the system can ask:

    • You have only X gallons of petrol left. Do you want to re-route to a gas station? (Answer Yes/No)

    • Sam has re-routed to a gas station. Do you want to follow him? (Answer Yes/No)

    • Nick has chosen a new route. Do you want to re-route too to follow him? (Answer Yes/No)

Final design

For this prototype, I have used Sketch3 to create storyboards/wireframes of a few scenarios. I have also chosen to model it on an iPhone (iOS) but the final product should ideally have an Android version as well.

Some things to note about the design representations below:

      All the loose text on the prototype screens, in black, floating on the map are actually audio - either system generated or spoken by the user.

      The “Yes” and “No” buttons on the screen are denoted as “Y” and “N” and while these buttons will appear on the screen, if the need arises for the user to press them, they can be controlled by a speech command of “Yes” or “No”, so as to not distract the driver when he is driving.

      Some audio messages from the system begin with a special noise, denoted by a “Ping!” in the wireframes. These are meant to alert the driver for potential route changes, updates, or important notes that he must be on the watch for. Lower priority information, that does not need his attention immediately do not begin with a ping.

This first storyboard gallery tells us about how the application looks when opened, how a team is created from a team leaders point of view, and how a journey is created and started. When creating a journey, various parameters can be assed as inputted by the users and appropriate route suggestions are made. It also gives us a basic look of the UI in the non-drive mode as well as it's transition to the 'drive mode' whet he journey is started. This is apparent when we lose the title bar and see an expanded map cover the entire page. 

We also have two small buttons on the bottom left and right corners: These options are available on voice command as well, if the driver says “Mute” or “Repeat”.

a)    Mute: This is to mute the audio of the system, if required immediately.

b)    Repeat: This is to ask the system to repeat its last audio, if you want to hear it again.







This second storyboard gallery takes us on a case based scenario where the last route update offered by Sam was NOT accepted by the first person user, by him choosing the NO option offered on the last wireframe slide on the previous gallery.

'No' could have been chosen either by a verbal command, or if not registered, by touching the appropriate button. On rethinking this design, A next iteration would also have some sort of "undo action" option that can act as error recovery when a wrong Yes/No option was registered by the system.






Contrary to the previous gallery, this third storyboard gallery takes us on a case based scenario where the last route update offered by Sam was accepted by the first person user, by him choosing the YES option offered on the last wireframe slide on the previous gallery.

Again, 'YES' could have been chosen either by a verbal command, or if not registered, by touching the appropriate button. 


Finally, one the user reaches his destination, the most natural impulse for him would be to check which of his team mates have also reached, or which of them are still on their way. Once he finds this out, he might want to either:

  • place a phone call to a team mate who has already reached
  • broadcast a message to someone still travelling. This is important because, for a team mate who is driving, we don't want to place a phone call to them. Rather, we would like them to continue using the mode of interaction the app provides in it's raw state.

We saw these options present themselves in two scenarios in the previous storyboards. Following those, we have this screen that takes us out of the drive mode and resumes regular mobile device interaction.








more support for the design

Here are some additional reasons for decisions that were taking while designing the interface as seen in the examples above:

  • While we have audio mode communication to allow the driver to concentrate on the road, we also have audio feedback for his actions, once his Yes/No reply is recorded, for the same reason
  • By Fitts’ law, we want to minimize the error caused by the user when selecting between the only 2 push button options he has. So like in the diagrams above, the “Drop Pin” option and the “Broadcast” option are on opposite ends of the screen. We must remember that we want to minimize the effort of the user, in being accurate while selecting an option, while he is driving, so that his attention is not diverted.
  • For the same reason as above, minimalistic words are used in the display, so that most of it can be gauged at a glance. The main page of the app in drive mode, is simply a map, with the user’s car highlighted in a different color as compared to the others.
  • The system takes initiative in collecting and presenting data to the driver and in providing available suggestions on how to act on them, but the choice and decision making power, is still with the user. The user still feels in control and not led by the system entirely. This is an example of allowing the system to decide who does what better, and splits the work accordingly (Man-Computer Symbiosis). 
  • Safe exit: This is based on the design principle for recoverability and robustness. Each stage of the process has an exit sign on the top right corner that should help you exit the app gracefully. This is especially useful when in ‘Drive mode’ when you want to stop and exit out. 

  • Minimize recall: Most of the interface is speech and audio based, so if the user had to initiate all commands, he would need to actually remember appropriate voice commands to relay to the system. For this reason, most of the interaction is initiated where possible by the system, and the only commands the user needs to remember are yes and no for the most part.

  • The design adopts a uniform color scheme that is friendly to people who have red/green colorblindness. It also maintains headings over sub-headings, such as “Create Trip” over the three tasks below it (“Invite Friends, “What is most important to you?”, etc.

Future directions and evaluations

  • More work needs to be done to expand on the pre-drive mode, route selecting options, especially, about how to handle pending requests for team mates before the journey is started.
  • We could probably provide Avatars to each of the icon representations denoting different drivers, so allow some level of personalization. However, i is important to still be able to maintain a visible distinction between the user's car with other team mates' cars, possibly with color.
  • Evaluations would need to be carried out using a proper map API, possibly with Android where audio feedback and speech recognition can be employed. This is particularly important for on the site testing. A detailed evaluation plan for this design can be found here: Evaluation Report PDF