Our task was to develop a service that would utilize the automobile as an Internet of Things platform.
The Internet of Things (IoT) provides a variety of platforms with the ability to move significant amounts of sensor data from one product service system to another, enabling use in new and different industries. The automobile is growing into one of those platforms as the cost of connecting to a network decreases and data speeds increase. The goal of this project was to conceive of and design a new service that could leverage data from cars, drivers, or passengers as an IoT platform. To do this, we were put into teams and tasked with conducting research and developing new concepts based off of what we found.
TEAM MEMBERS
John DeGore, Lizzie Miller, & Jacqueline Young
Multi-Modal alerts that notify drivers about road conditions and potentials risks provide value to all vehicles on the road.
We decided to model a new service that would leverage a car's sensors to share road conditions and minute-to-minute weather conditions. Multi-modal alerts will notify the driver of any changes in road condition or weather on their route. The service would be useful to drivers and the data gathered could be valuable to third parties. For example, the data could help municipalities be more strategic when deploying salt and plow trucks and increase efficiency. Another example would be services that report on traffic and weather. This data could provide them updates without having to use their resources. We created models to showcase the impact it would have on drivers, how it would work and the value of the service.
New Service Journey Map
New Service System Blueprint
New Service System Blueprint
New Service Value Flow Model
We needed to know more about the technology in cars and driver expectations.
Our research focused on few areas: how cars utilize technology, the experience of driving, and the needs of drivers and passengers. To start everyone on the team did literary research. From our literary research, we developed a survey, in-person interview questions, and finally a concept model.
Approximately 70% of those we surveyed had been in an accident.
Our survey had 43 participants and focused on learning about driving habits, phone usage, and safety & maintenance. We found that the most annoying aspects of driving for our respondents were other drivers and traffic. The most enjoyable parts for them was the independence it offered and driving while listening to their favorite music. Almost all of the participants multitask to some degree while driving, including using navigation, changing the music, and checking texts or emails. About 70% of respondents had been in an accident of some sort, the most common reasons being that it was another driver’s fault, weather conditions, and drunk drivers.
People love the independence driving affords them but hate being on the road with other drivers.
We conducted interviews to probe a couple of topics from our survey with greater depth. The people we interviewed didn’t drive as much as the survey participants, but they enjoyed the independence it offered and were also annoyed by other drivers like the survey participants. The annoyance other drivers cause is part of why they didn't drive a lot. However, the independence it offers allows them to get to places inaccessible by public transport. Common themes found were the high costs of insurance, maintenance, and repairs, as well as accidents and damage that were not their faults such as being hit by another car, weather damage, or theft.
Cars are filled with sensors tracking a variety of data.
The goals of the concept model were to help us better understand what sensors and data connections were utilized currently by automobiles and what pieces of that data could be used by a smart car platform. We used our findings from the survey and interviews to help identify pain points. Each of us brainstormed a few ideas, and then we worked together to flesh out some of them in a whiteboarding session. Eventually, we developed one that combined and organized everything into four categories: performance, safety, location, and cabin comfort. Lizzie then designed a refined concept model.
The sketches of our initial ideas and the final concept model whiteboard draft.
Finalized Concept Model
We identified fours opportunity areas to explore.
Using our initial research and concept model, we worked together to determine areas of opportunities through a whiteboarding session. We identified the stakeholders, goals, technology, value proposition and use case for each opportunity. We ended up with four different areas to explore:
• Maintenance via Sensor Platform
• Car Settings
• Mood Settings via Sensory Output
• Good Driver Insurance & Tutor
• Maintenance via Sensor Platform
• Car Settings
• Mood Settings via Sensory Output
• Good Driver Insurance & Tutor
White-boards from our identifying opportunities session.
Car settings strayed away from the concept of the car as an IoT platform. So we took a closer look the insurance and tutor idea.
After some deliberation, we decided that the adjustable car and mood settings weren't faithful to the concept of using an automobile as an IoT platform. So we broke down the good driver insurance and tutoring into two separate opportunities. Then, we developed service concepts that would provide value to the opportunity areas; they were direct to insurance reporting, third party tracking and reporting, and a bad driver alert.
Exploring our ideas through speed dating and user enactments helped us narrow down and refine our concept.
People only want alerts or reports when they provide them with something tangible enough to act upon.
There was a lot of overlap between some of the service concepts, so we broke them down into smaller components and created storyboards to use in speed dating sessions. Speed dating would help us learn which ideas people were open too. We even created different versions for some of the components, so we could A/B test different executions. We sketched out six scenario storyboards and developed the speed dating questions together. Then we broke them up to create finalized storyboards to use in our sessions.
From the speed dating session we learned that, while people hate other drives, they didn't like being alerted about them. They thought the alert would be annoying or unactionable. Drivers also felt that driving summaries and reports would also be unactionable or tell them things they already knew. We received a lot of positive feedback around storyboards that offered tips and informed them of dangerous road conditions.
The initial storyboard whiteboard sketches
The finalized storyboards used for speed dating our concepts
The insurance concept was already available, and people weren’t thrilled with it. So, we needed to go a different direction.
Initially, our focus had been on developing a service that would be related to insurance. We had even developed current state models for automobile insurance. The speed dating results combined with learning that a couple of insurance companies were already providing similar services forced us to pivot away from insurance. Knowing we had positive feedback around the storyboards for informing drivers about dangerous road conditions, we decided to develop a service that would help drivers navigate adverse weather and road conditions.
Developing current state models provided us with a path to discover the value our service could provide.
To start developing new service models, we first had to redevelop our current state models to reflect the pivot. Mapping out how drivers currently deal with adverse weather conditions helped us identify where and how our service could fit in. We worked collaboratively sketching the current state models and the new service models in a whiteboard session. We decided to combine the customer journey maps for the current state and the new service. So, it would be easy to compare the differences between the experiences. After refining all of the models, we divided them up between the team to digitize.
Initial Current State Model Whiteboard Drafts
Initial Current State Models
Revised Current State Model Whiteboard Drafts
Revised Customer Journey Map
Revised Current State System Blueprint
Revised Current State Stakeholder Model
New Service Model Whiteboard Drafts
A combination of visual and audio feedback is the most effective for delivering notifications while driving.
After finishing up the models, we worked on developing user enactments to learn what modalities (haptic, visual and audio) would work while driving. Our user enactment would simulate driving a car and receiving different types of notifications alerting the driver to adverse road and weather conditions and possible tips or navigation changes to help avoid them. We utilized a combination of tools and the Wizard of Oz technique of prototyping to create the simulation. A participant would sit in front passenger seat of the car with a small setup that included a PS3 steering wheel & pedal controllers and an iPad that displayed a car dashboard. There was also an iPhone placed under the steering wheel controller to simulate haptic feedback while the iPad provided visual and audible feedback.
Once the participant was set up in the car, we took them on a pre-determined route. I drove the car while Jacqueline sat in the back seat with a laptop that monitored the actions of the participants and controlled the iPad dashboard. She also had an iPhone, which she used to send texts to iPhone under the steering wheel. At designated landmarks, the Jacqueline would use her laptop and phone to deliver audio, visual and haptic feedback to the user in random order. Then she would observe the actions taken by a participant and update their dash display. We tried out each style of feedback individually and a variety of combinations.
The majority of participants liked the service and felt that the visual and audio combination was the most effective at getting their attention. It also happened to be the one they responded to the most during the enactment. They didn't like haptic because either it wasn't a strong enough vibration to get their attention or because the roads we drove on were rough, and it was hard to tell what was vibrating. We used this feedback to develop the models for our Multi-Modal driving alerts service.
Whiteboard sketch from our brainstorming session for the enactment, photos from the beginning of an enactment, and an example the dashboard we created
Post Project Assessment
What went well?
Our user enactments went over really well with our teacher. It also provided us with a lot of positive feedback about our concept, letting us know it was a good direction to go. We did a lot of modeling, which helped me at my job. I’ve incorporated using a lot of these models into my process.
What could have been different?
We could have researched our opportunity area more. If we had, we likely would have learned our insurance concept was already being implemented much earlier, and that would have saved us some time. Also, a better implementation of haptic feedback in the user enactments could have lead to different results. Using the phone didn’t work well.
What’s next?
If I were to continue working on this project, I would do another iteration of the user enactments. I would redo the haptic feedback notification to explicitly rule it out, and focus on a more limited set of feedback combinations to fine tune the delivery.