After conducting research and extrapolating crucial insights, we started to develop ideas for how an interaction medium between police and autonomous trucks might take shape.
Based on the research findings we surfaced, there are some key implications for which directions to take as we begin our design process. For example, multiple modalities of input and output might be necessary to accommodate different interaction circumstances. As a result, we built and tested solutions in a wide variety of modalities.
It’s no doubt that many different possibilities exist for enabling and streamlining interactions between officers and autonomous trucks. Before identifying and zeroing in on the most viable and valuable opportunities, we let our minds run wild and untethered to explore the breadth of options. From device types to input and output modalities... We considered many different permutations before slimming the pool of ideas.
We generated ideas primarily based on the following principles:
Meet AViD (Autonomous Vehicle Interaction Device)—a testament to our avid efforts in designing usable solutions for law enforcement to communicate with Torc’s driverless trucks. AViD includes unique features such as multimodal input, automatic mode for inspecting the vehicle, and autofill for inspection reports.
After testing with different variants of authentication such as entering a badge number and taking a photo of the police vehicle’s license plate, etc., we ultimately opted for a simple and common two-factor authentication flow, which already exists for most software applications that officers currently use.
For the purposes of helping officers identify and connect to vehicles, we leverage near-field communication (NFC) between the vehicle and the officer’s device, an entry point that spares officers the manual effort of finding and scanning a code. Officers mentioned that they may want to sort vehicles differently depending on the context. Since they were commonly mentioned, we include time of last inspection and distance from the officer as the two sorting parameters in AViD.
For the purposes of helping officers identify and connect to vehicles, we leverage near-field communication (NFC) between the vehicle and the officer’s device, an entry point that spares officers the manual effort of finding and scanning a code. Officers mentioned that they may want to sort vehicles differently depending on the context. Since they were commonly mentioned, we include time of last inspection and distance from the officer as the two sorting parameters in AViD.
Across different inspection levels, there are a variety of tasks, including checking driver credentials and inspecting the actual vehicle. However, not all tasks will be relevant for each level. For instance, the Level V Vehicle-Only Inspection naturally won’t involve checking information related to a driver. Selectively showing or hiding certain action items based on the intended inspection level seems to spare officers the cognitive load of deciding which actions are relevant.
Furthermore, officers voiced the desire to be able to export basic information from shipping documents to the inspection report they need to complete. As of now, they typically need to input the carrier information manually. However, this can be time-consuming and increase the opportunity for human error. Any effort to decrease the need for manual input for inspection report seems welcome.
We got early feedback that touchscreen interactions are not always the most feasible. For example, officers may get their hands greasy or wet during inspections or wear gloves in cold weather. In these circumstances, it would be critical to provide an alternative method of user input. Voice input proved to be one of the most well-received ideas among officers we spoke to.
Different officers may have varying preferences for how they process information, so we organized inspection items and categories into two views: list view and truck view. The list view shows a scrollable list of all the inspection item categories, each of which can be expanded to show more granular items. The truck view doesn’t show the categories all at once, but instead shows different regions of the truck in a visual format and includes the inspection item categories as hotspots on corresponding regions.
Because the task of activating inspection items such as headlamps and brakes is a repetitive task throughout the inspection, we wanted to make sure the mechanism for doing so stayed at the most easily accessible part of the screen: the bottom. We also included an “automatic” mode that can be toggled on or off at any point. When turned on, activate inspection items one by one automatically instead of manually requesting activation each time
Currently, with an unformatted notepad, officers lack a systematic way to document information while inspecting the vehicle. With AViD, officers can easily and consistently check off inspection steps. We hypothesized that this would help reduce the officer’s cognitive load, and many officers were quick to validate this impact. Furthermore, they can optionally add a more descriptive note with images, voice memos, etc. to elaborate on their decision.
Because the inspection process can be long and exhaustive, officers value being able to see what they have and have not completed. This can help them easily recognize where they are in the process and minimize their margin for error. Indicators of progress are present in the list view, truck view, and a persistent progress bar at the top of the screen.
Currently, officers need to complete a mandatory inspection report after each inspection. Requiring officers to do the same tasks on both the inspection report and AViD would be redundant work. As such, we envision an option to export data directly to the officer’s inspection report. The officer can choose what information they want to include or exclude from the export.
The question that Torc tasked us to answer is: How might police interact with driverless trucks?
As such, our problem space lies at the intersection of three different domains: law enforcement, the trucking industry, and autonomous technology. Each of these domains is highly complex and variable, consisting of many moving parts.
From interviewing key stakeholders to directly observing police-truck interactions, we conducted research from multiple angles and surfaced some important insights. Continue reading to learn more!
The question that Torc tasked us to answer is: How might police interact with driverless trucks?
As such, our problem space lies at the intersection of three different domains: law enforcement, the trucking industry, and autonomous technology. Each of these domains is highly complex and variable, consisting of many moving parts.
From interviewing key stakeholders to directly observing police-truck interactions, we conducted research from multiple angles and surfaced some important insights. Continue reading to learn more!
The question that Torc tasked us to answer is: How might police interact with driverless trucks?
As such, our problem space lies at the intersection of three different domains: law enforcement, the trucking industry, and autonomous technology. Each of these domains is highly complex and variable, consisting of many moving parts.
From interviewing key stakeholders to directly observing police-truck interactions, we conducted research from multiple angles and surfaced some important insights. Continue reading to learn more!
After conducting research and extrapolating crucial insights, we started to develop ideas for how an interaction medium between police and autonomous trucks might take shape.
Based on the research findings we surfaced, there are some key implications for which directions to take as we begin our design process. For example, multiple modalities of input and output might be necessary to accommodate different interaction circumstances. As a result, we built and tested solutions in a wide variety of modalities.
It’s no doubt that many different possibilities exist for enabling and streamlining interactions between officers and autonomous trucks. Before identifying and zeroing in on the most viable and valuable opportunities, we let our minds run wild and untethered to explore the breadth of options. From device types to input and output modalities... We considered many different permutations before slimming the pool of ideas.
We generated ideas primarily based on the following principles:
We discussed and tested ideas and prototypes with officers from across the country, as we anticipated regional differences to create discrepancies among our target users' experiences. The states we focused on reaching out to were those that
Meet AViD (Autonomous Vehicle Interaction Device)—a testament to our avid efforts in designing usable solutions for law enforcement to communicate with Torc’s driverless trucks. AViD includes unique features such as multimodal input, automatic mode for inspecting the vehicle, and autofill for inspection reports.
After testing with different variants of authentication such as entering a badge number and taking a photo of the police vehicle’s license plate, etc., we ultimately opted for a simple and common two-factor authentication flow, which already exists for most software applications that officers currently use.
For the purposes of helping officers identify and connect to vehicles, we leverage near-field communication (NFC) between the vehicle and the officer’s device, an entry point that spares officers the manual effort of finding and scanning a code. Officers mentioned that they may want to sort vehicles differently depending on the context. Since they were commonly mentioned, we include time of last inspection and distance from the officer as the two sorting parameters in AViD.
To minimize the risk of error (e.g., inspecting a vehicle that isn’t the one the officer’s device is connected to) and danger (e.g., standing in front of the vehicle while its brakes are released), officers want to see identification and status information about the connected vehicle at all times. This information is available after the officer is accounted
Across different inspection levels, there are a variety of tasks, including checking driver credentials and inspecting the actual vehicle. However, not all tasks will be relevant for each level. For instance, the Level V Vehicle-Only Inspection naturally won’t involve checking information related to a driver. Selectively showing or hiding certain action items based on the intended inspection level seems to spare officers the cognitive load of deciding which actions are relevant.
Furthermore, officers voiced the desire to be able to export basic information from shipping documents to the inspection report they need to complete. As of now, they typically need to input the carrier information manually. However, this can be time-consuming and increase the opportunity for human error. Any effort to decrease the need for manual input for inspection report seems welcome.
We got early feedback that touchscreen interactions are not always the most feasible. For example, officers may get their hands greasy or wet during inspections or wear gloves in cold weather. In these circumstances, it would be critical to provide an alternative method of user input. Voice input proved to be one of the most well-received ideas among officers we spoke to.
Different officers may have varying preferences for how they process information, so we organized inspection items and categories into two views: list view and truck view. The list view shows a scrollable list of all the inspection item categories, each of which can be expanded to show more granular items. The truck view doesn’t show the categories all at once, but instead shows different regions of the truck in a visual format and includes the inspection item categories as hotspots on corresponding regions.
Because the task of activating inspection items such as headlamps and brakes is a repetitive task throughout the inspection, we wanted to make sure the mechanism for doing so stayed at the most easily accessible part of the screen: the bottom. We also included an “automatic” mode that can be toggled on or off at any point. When turned on, activate inspection items one by one automatically instead of manually requesting activation each time
Currently, with an unformatted notepad, officers lack a systematic way to document information while inspecting the vehicle. With AViD, officers can easily and consistently check off inspection steps. We hypothesized that this would help reduce the officer’s cognitive load, and many officers were quick to validate this impact. Furthermore, they can optionally add a more descriptive note with images, voice memos, etc. to elaborate on their decision.
Because the inspection process can be long and exhaustive, officers value being able to see what they have and have not completed. This can help them easily recognize where they are in the process and minimize their margin for error. Indicators of progress are present in the list view, truck view, and a persistent progress bar at the top of the screen.
Currently, officers need to complete a mandatory inspection report after each inspection. Requiring officers to do the same tasks on both the inspection report and AViD would be redundant work. As such, we envision an option to export data directly to the officer’s inspection report. The officer can choose what information they want to include or exclude from the export.
