Overview
Autonomous vehicles are the way of the future—they are likely the only scalable solution to the 80,000 driver shortage problem. In order to get driverless trucks on roads at scale, they need to operate in today’s world of road regulation centered around police officers. Current police interactions require driver involvement to provide paperwork or inspect trucks, but in a world with level 5, fully-autonomous trucks without a driver in the vehicle, there is no human driver to interact with a police officer. The challenge for our team was to figure out how we could enable police officers to communicate with driverless trucks.
Process
We leveraged the double diamond model as a wholistic approach to our design process, while also following a iterative process—cycling through research to prototype testing multiple times, as we continued to learn more and work our way to solving problems in a testing-heavy approach rather than committing ourselves to one specific solution too early.
Framing the Problem
Since this was a very 0 to 1 project we started with a very much 0 understanding of how commercial trucks are regulated and policed. Since our team was fairly scrappy, I partnered with our researcher to explore how police currently interact with commercial trucks and drivers.
From our initial contextual inquiries, we quickly learned that there are a variety of reasons a police officer might interact with a commercial truck along it's journey:
Since this was a very 0 to 1 project we started with a very much 0 understanding of how commercial trucks are regulated and policed. Since our team was fairly scrappy, I partnered with our researcher to explore how police currently interact with commercial trucks and drivers.
From our initial contextual inquiries, we quickly learned that there are a variety of reasons a police officer might interact with a commercial truck along it's journey:
Since this was a very 0 to 1 project we started with a very much 0 understanding of how commercial trucks are regulated and policed. Since our team was fairly scrappy, I partnered with our researcher to explore how police currently interact with commercial trucks and drivers.
From our initial contextual inquiries, we quickly learned that there are a variety of reasons a police officer might interact with a commercial truck along it's journey:
While there are similarities in these interaction types, we needed to pick an area of focus to design our solution for that interaction in mind. Our north star metric is to save time—since each minute a truck is off the road the customer is losing money. Looking at time spent in interaction + frequency of interaction led us to pick truck inspections as the most critical interaction type to solve for right now. Our challenge was to figure out how we can enable police officers to inspect a driverless truck.
Researching…aka Ride Alongs
We interviewed several local and federal police officers and transportation agencies, and spent a few days in the field with officers conducting truck inspections. Our goal was to understand the interactions between officers, truck drivers, and the vehicle itself.
We learned:
There are 8 levels of inspections--ranging from documents to detailed physical audits and each level includes dozens of steps.
Police Officers rely on drivers to provide material and control the truck during almost all parts of the inspection process.
Police Officers like the fluidity of giving verbal commands to drivers, as well as non-verbal, gestural-based cues during inspections.
Drivers have to earn the trust of officers, often based on the reputation of their company and how successful an inspection goes.
We synthesized our research into a journey map based on pre/post and during inspections, and the actions, touchpoints, experiences, and opportunities for each stage.
Design Principles
Before we began designing product and features, I worked with closely with product, eng, and strategy teams to align on key principles:
Familiarity: moving a non-digital experience to digital requires us to leverage existing mental models in our design.
Flexibility: allow police officers to conduct inspections in a manner that they choose rather than a forced structure.
Relevance: optimize for showing information that is most relevant to officers within the context of the inspection procedure.
Trust: design with trust as the priority so officers can conduct the inspection without human involvement.
Design Process
Through several months, our team worked on sketches, to mid-fi wireframes, and eventually hi-fi prototypes to be shipped. We tested rigorously, so we structured our work using Sprint forms—roughly 2 weeks per sprint where we would identify a design problem, ideate solutions through testing, collaborate cross-functionally to align on a few directions to explore, create wireframes/mid-fi (sometimes click-able prototypes), conduct conceptual and usability testing with both police officers and non-police officers, and then align on areas to improve and move features forward to a more hi-fi design solution.
Example of a mid-fi flow used in testing:
Using a Sprint structure allowed us test specific features in isolation like onboarding, citation reporting, vehicle selection, etc. with several explorations in each of these areas. This process also worked well since we had a few months to design an end-to-end, 0 to 1 software that was in a very new space.
Launching AViD
Over the course of several months, we created AViD (Autonomous Vehicle Interaction Device)—a human-vehicle interaction software that allows police officers to communicate with Daimler's (eventually beyond) driverless trucks. Officers use AViD at all the stages of a truck inspection—with a focus on dead-simple UX for inspection procedures.
My work focused on several features, some of which I've discussed in more detail here.
Onboarding
Our initial GTM strategy was focused on top-down incentives—police officers being told to use AViD from their police chiefs, and also officers learning AViD during training. We noticed that officers struggled to fully understand the product value early in their experiences, and needed to fix this to reduce friction and churn.
I designed an onboarding sequence to provide some context around what AViD can do—highlighting the features that are most likely to make the officer’s job easier (ex. ability to use voice command, autofill of inspection reports, etc.). the course of several months, we created AViD (Autonomous Vehicle Interaction Device)—a human-vehicle interaction software that allows police officers to communicate with Daimler's (eventually beyond) driverless trucks. Officers use AViD at all the stages of a truck inspection—with a focus on dead-simple UX for inspection procedures.
Officer Authentication
Without a driver present, autonomous trucks can be more vulnerable to a bad actor trying to access vehicle controls or information without proper credentials. Today, drivers can easily if the police officer appears to be a legit officer, and can ask to see their badge to confirm. We needed to a design a way for Daimler to authenticate an officer before giving access to vehicle data.
We tested several different variants of authentication such as entering a badge number and taking a photo of the police vehicle’s license plate, etc., but ultimately opted for a simple and common login flow with two-factor authentication, which already exists for many software applications that officers currently use. The challenge here was primarily to find a method that works with existing infrastructure and still provides a level of security and failsafes for Daimler.
Vehicle Control Simulation
Perhaps the biggest product challenge was around how to operate the truck for an inspection. We observed officers asking drivers to "hit the brakes…10 percent, little more, little more, all the way." Without a driver in the cabin, inspection items such as brake checks will not be able to operate since police officers won't enter the cabin for liability reasons. The constraint here is that we could not provide direct control of the vehicle to any third-party. This was tricky since we also wanted to balance the officer having control which leads to trust, but also could not let them directly operate the vehicle. We needed to design a way that officers could initiate inspection items in a simulated manner.
I took inspiration from music players to create a sense of playing a simulation—running breaks through different levels without letting the officer directly control brakes. I also leveraged existing mental models with remote controls that made the phone feel like a remote control in their hand during the inspection.
Progress Tracking
Our initial goal was to not add any time to the existing inspection process with humans (~45 - 90 min), but I wanted to explore ways to potentially reduce the inspection time which would create more value for Daimler's customers. During our research I noticed that officers spent a little bit of time switching between items in an inspection. Our initial cohort of users also showed gaps in time when finishing one inspection task (front headlamps) and switching to another (rear brakes). I wanted to design the inspection process to push progress along.
Taking inspiration from steppers in set-up flows, I hypothesized that showing a persistent progress bar could subtly nudge officers to stay on track and move from item to item in an effort to finish the inspection, without being too obtrusive to suggest cutting corners. We found great success with this, noticing that users reduced ~3-4 minutes in a total inspection through reduced time switching from task to task.
Safety Nudging
Another area that I explored was improving the safety protocols since we had more direct attention of officers. Without a digital companion, officers today rely on their memory to make sure they follow safety standards—making sure the vehicle is turned off when appropriate, is in park, and that they put wheel chocks under the vehicle before beginning, all of which can have a major impact on officer lives.
I designed a loading screen interaction that nudged officers to chock wheels before inspection. Since this was pretty subtle, officers seemed to find it helpful and not annoying within the context. Using a sticky module on top of the inspection screen allowed us to include indication of parking and brakes being on, and I used color to make it incredibly easy for officers to glance and make sure the vehicle's status is safe.
Shipping & Impact
AViD is currently still in use within Daimler's autonomous truck testing facilities across North America, as well as continuing to explore applications for AViD outside of Daimler's trucks (part of a strategic service model shift for Daimler). This product has so far made a huge impact on Daimler's push to be a market leader in the autonomous vehicles space by allowing trucks to get on roads as soon as possible.
Due to NDAs, I am not able to publicly disclose all the metrics we measured against and the impact across the project, but the key metric we were measuring against was time spent in inspection, which we were able to reduce by ~13 minutes for a 45-90 minute inspection.
Personally, this experience was a great challenge for me to study a new space in a different context rapidly, embrace ambiguity and complexity, work within PM and Eng constraints (a huge factor in the autonomous space), and ultimately allowed me to solve a people problem that is changing an entire industry.
