Traffic Safety Experience

july 2019

saving lives with computer vision

The primary goal of this smart city service is to provide traffic engineers with insights about automatically detected and analyzed unsafe situations on intersections.

I designed a Traffic Safety Environment, including the Traffic Safety Platform, the Traffic Camera Mobile UI, the E-Commerce Platform, and the Service Model.

The Problem

6240 fatalities happen every year on U.S. intersections. Let's say you are a traffic engineer and want to figure out why the accident rate on a specific intersection is so high. You implement countermeasures based on your gut feeling and after three years, you will know if it worked or if another 12 mortalities have occurred. Isn't this a painful experience? I was getting in contact with the CEO of a tech startup in 2018. Two excellent Caltech graduates wanted to apply their hardware and software hacking skills to change the mobility industry. With computer vision and machine learning they tackled this in many ways old-fashioned transportation industry.

The biggest challenges that I was facing were:

How to get the team on board for a customer-centered design approach?
How to build trust in an established industry with a completely new unapproved product?
How to solve relevant problems that really matter with the right market fit?

The Journey

My Team:

1 Hardware Developer

1 Data Scientist

1 Backend Developer

1 UI & Frontend Developer

1 Me

Technologies:

IoT

Computer Vision

Machine Learning

Industries:

Transportation

Mobility

Smart City

My Roles:

Business Design

Service Design

UX Design

Technical Project Management

Business Development

Sales

1. Industry Analysis & Design Opportunities

I first tried to understand what was already there. The company was in an early founding stage. The founders already collected some Angle Investment and where willing to invest their time for their startup idea, so financing was nothing to worry about for the moment. Additionally, a basic mission for the company was pointing us into the direction to “change the industry with computer vision and machine learning to make transportation safer and more efficient”. Our team was engineering-heavy, so it was no surprise that they were pushing from the backend, working on an innovative traffic camera model, a micro-controller for traffic lights, and algorithmic intelligence with the goal to detect road users and optimize traffic flow with this information.

I was looking into industry reports and did some competitive research to see what was already out there. Screening the big incumbents’ and entrants’ homepages and looking up some industry outlooks gave me a good understanding of where the industry was heading.

2. Qualitative Research

Customer-centered innovation should start with exploring the customer’s needs. To overcome the fears of the rest of the team that we could loose credibility by reaching out to customers without a ready to go solution, I walking them through the concepts of user-centered design. Then I started with the search for our customers. I called industry consultants to find out who was actually managing traffic in cities and who would be finally paying for traffic optimization. Some calls later I had enough information to develop a persona draft and a screener for interviews candidates.

Now, I had to get in contact with potential customers. Cold-calling cities was a very frustrating business, since they were overwhelmed with calls from sales representatives. After many unsuccessful attempts I decided to change my strategy. Meeting people in person on conferences was the solution and I finally found some very innovative and some very conservative people from the industry for an interview. I discovered patterns about how business was done, where the pain-points where, and what varied between the interviewees.

"We are happy with everything that moves traffic!"

"Video technology is not accurate enough. I trust the good old pneumatic tubes!"

"Traffic Safety is coming, but it's hard to get funding for it"

The biggest takeaways:

We had to build trust for our new technology and our new startup, if we wanted to establish computer vision as a technology
Traffic Efficiency was easier measurable and therefore more tangible than making traffic safer.
There is a movement and an unsolved need to enhance traffic safety, but the traffic engineers and city planners are lacking the tools necessary to do that.

What surprised me most, was, that there was a tradeoff between moving traffic and making traffic safer. The industry was strongly leaning towards the optimization of traffic efficiency. The first takeaway felt like a hurdle to overcome and the last two takeaways were unsatisfied needs. This was a great design opportunity for us to support the industry with something useful.

3. Creating a vision

Back at the office, our data scientist was already mastering road user detection and starting to build some basic intelligence for safety and efficiency analytics. We realized that we had the potential to make a significant change for the industry. It was time to develop a vision for our team.

A companies vision and its core values have to be developed and carried on by the whole team. Having everyone at the table for the development was crucial for a successful implementation. I started the workshop explaining basic concepts about how companies successfully use visions and brand strategies. Then we started to define our core values. Customers and business partners need to be part of the development as well. I brought their opinions into the discussion by adding paper snippets with their thoughts and mixing them with ours.

Finally, the message was clear. Efficiency sells, but Safety has an impact. We wanted to transform traffic from something painful and unsafe into a joyful experience. And therefore we had to make streets safer. This added more value to the industry and had more meaning for us.

4. Value Propositions & Business Model Development

We took a step back and a time out to reflect. I used the time to reach out to some industry specialists for transportation safety and to take another look into my interview notes for a deep dive on safety-relevant comments. I prioritized the persona drafts in order of relevance for traffic safety. After that I worked on the value proposition for each of them.

We ideated on feasible business models. Theoretically, we had the skills to optimize complete city-wide traffic networks for safety by connecting autonomous cars to the city infrastructure and controlling traffic signals. But we had to start small and built trust, in order to get access to real-time traffic systems.

Our first product should be a smart city service that automatically analyze traffic footage from intersections for safety concerns. We used traffic cameras to record intersections for some days and algorithms to automatically analyze the footage. Our dashboard showed safety-relevant patterns on schematic views, and extract short video snippets of the most dangerous situations. The data could be used to apply for grant money, plus it would deliver pinpointed information about the biggest risk factors of an intersection, so that the engineers were sure to invest the money into the right expensive countermeasures.

5. Minimum Viable Product

We decided to build an MVP, to get some early feedback on our most risky assumptions:

Can we convince traffic engineers to let us conduct studies, if we provide them with safety analytics?
Are we feasible of developing safety studies that add real value?
Are customers willing to pay as much as we thought was necessary to run a scalable business?

Our MVP was a mobile traffic camera and a small set of analytics that could detect and capture near-misses – dangerous maneuver that did not turn into accidents. Statistically speaking, these incidents could have led to a number of crashes. Identifying the reason for these events, allows you to take the right countermeasures and increase safety for your intersection.

For this purpose, we optimized our camera prototype so that we could easily install it to any intersection pole. While our engineers developed the technical features, I developed the sales material for our business model and started to offer free beta studies. Some innovative cities were willing to work with us, so the first studies were performed. And the technology worked, but the output was ugly. While our engineer was fixing some technical issues, I used the meetings with the traffic engineers to identify for more risk factors on intersections that traffic engineers were interested in investigating. I had a list of 20 relevant features.

So, we already proved that two of our most risky assumptions were right. But we still had no feedback on how much cities would be willing to pay for our product. None of our questions about pricing was getting answered during our interviews. My intuition told me that showing them a higher fidelity product would help to answer this question.

6. Design Sprint

I figured out that parts of our team couldn’t let go of our big plan to optimize whole traffic networks in real-time. We were constantly running into discussions if safety would have an impact and if we shouldn't switch to develop efficiency analytics. I had to admit, I was spending a lot of time to get customer insights, but I forgot to share them with the team. I brought interview recordings to our next meeting. This helped a lot - the customer voices emphasized the high value that safety features would deliver to traffic engineers if they just were available. This built trust within the team that we were designing for the right problems.

A prototype of our final product – a digital safety analytics dashboard - should show the customer what they would get out of working with us and had the potential to create a login effect. My feature-value matrix provided the cost-benefit-ratio of all potential features. I compared the expected development time of our engineer with the anticipated value of insights for our customers.

I brought the team together for a design sprint. We ideated on how the winning features could be presented to give the traffic engineers the best insights and to take informed decisions on safety concerns. We also ideated on how our solution could be aligned with the typical working day of a traffic engineer. After creating some initial paper drafts, I created digital mockups and we evaluated in the team which ones would go into development.

7. Prototyping & Testing

After this very intense design sprint, I designed mockups and built a clickable prototype with Sketch app. I already knew from my business development meetings with cities, that traffic engineers were working in a control center on several HD format displays. Usually they used one extra screen for each application they applied. Mobile Apps for phones or tablets were uncommon, but maybe interesting for further applications. Now I could test the completeness of our feature bundle, the usability of our prototype, and the price of our service.

InVision seemed to be the right platform for collaboration and testing, because I could share prototypes and receive fast feedback from the team. Plus, I could do the first round of CTA testing via phone. To test the value of our feature set I conduct an online CTA testing with the consultants, as they were the experts in safety. The feature bundle that we provided was valuable, but the structure of our dashboard had to be adjusted. RP testing with our beta test customers showed that user flows were intuitive and that the structure of our platform was understandable. Only some minor adjustments were necessary. To find out the right price for our service, I updated the sales deck with my prototypes and tried to sell the product to cities for the price we thought we could be profitable. The feedback that we received was very promising. After some adjustments our pricing seemed to hit the spot where we were able to get many customers on board and create enough revenues to grow organically.

That worked well. After the first revision of the prototype and repeated testing, I was sure, that the safety platform was ready for a release.

8. Product Development

While we were getting feedback for our platform we hired some contractors to start building the components. We found a talented backend developer who started to bring our code to the cloud. We also had a frontend developer, who built the single components for the platform. He was the perfect fit, as he could communicate very well with our data scientist and also provided feedback on the look and feel of the platform. We worked together intensively to optimize the UI and also found solutions for usability problems that I discovered during my usability testing.

It was a very intense time for me, as I had my hands full of work getting feedback from the tester, managing the product development with the four developers, and starting to selling our product to customers. The hardest part about it was to choose between sides if the customer had expectations and the developers complained about the workload. The feature-value-matrix and the intuition that I built during my interviews helped a lot to give directions.

The Result

In the end, we were able to collect preorders from multiple customers within the first month after the launch. The startup is doing great and I am looking forward to seeing how they continue to grow and hopefully build enough trust with the product to being to avoid more unnecessary mortalities on intersections.

The key learnings:

Interview summaries have to be transparently displayed to your team frequently, so that they never lose track on the user’s needs.
Grow business and tech roles simultaneously, so that you keep the balance.
Present visuals and prototypes as fast as you can to your customers. That provides the most honest feedback and creates buy-in.