Connectivity by Design

Recently I was riding a shuttle bus at the airport along with five other people. The moment the bus pulled away from the curb, all five people had their cell phones out and were “connected” to somewhere else altogether. I observe this behavior a lot; perhaps you have as well. In my opinion, it is actually a very disconnected way to live – arguably anti-social and often useless. Granted, I am just as guilty as the next guy for checking my phone when I probably shouldn’t, but it got me thinking – could connectivity on Freightliner and Western Start trucks result in similar behavior – distracting people from what’s truly important to them? If so, then I will have failed.

My job is to develop our vehicle connectivity products within Detroit Connect, the product that turns our highly acclaimed commercial vehicles into connected technical wonders. Through connectivity, our customers can perform less monitoring, less data gathering, less analysis, and more informed decision making. That is in essence one of our mantras: We will deliver an exceptional user experience for both the drivers and the fleet managers.

There is one problem however. Connectivity also provides real-time access to more and more data every day. This begins to feed the monster of more and more monitoring which could very well put us behind with managers having to constantly monitor their fleet.

So, how do we avoid this? I think there are a couple of potential solutions.

First off, through connectivity we need to avoid simple reporting of facts and figures to customers regarding every vehicle. Certainly there is a need to be able to drill down to an individual truck and that will always be supported. However, on a daily basis our customers only need to manage the exceptions. For example, fuel economy reporting is available each and every tenth of a mile, but perhaps the customer only cares about the vehicle’s actual performance compared to the expected performance.

When our systems observe negative changes as an emerging trend, we need to flag the exception, visualize for the customer what has changed, and decide how to respond. Perhaps if the early innovators of smart phones could have foreseen the negative aspects these phones would have on people’s lifestyles – wasting a lot of time and ignoring each other on the bus and at the dinner table, for example, they may have designed smart phones slightly differently.

Imagine if instead of opening every email I received, my cell phone was smart enough to identify the emails I care about and redirect the rest. If my phone could automate my criteria, I could use my time for socializing or being productive in other ways, instead of constantly filtering my email. Likewise, exception-based interaction is the approach we need to take with vehicle connectivity.

Secondly, in connectivity we need to avoid the temptation to push functionality within applications just because we can. When I think about the various applications I use on a regular basis, it is my experience that I really only use the application for a small set of needs. This point is similar to my earlier blog post which emphasizes the utility of a product, feature or a service for a customer. If something is clever but not advantageous, then it should be omitted, so that only the most useful results can endure.

Now back to the shuttle bus. I know there are various reasons for this behavior. However, trucking is not much different than life. If we are always connected to the details, we might miss the exceptions.