4-way intersection of a city

Traffic Data Collection

Making Intersection Annotations Less Ambiguous

Imagine recording cars driving through an intersection using a camera, uploading the video to the cloud and then getting accurate counts of all the vehicles approaching and leaving the intersection from each direction. This information is called Turning Movement Counts (TMCs) in the traffic engineering industry. TMCs are used to plan signal timings and has historically been difficult to collect accurately.

With Miovision’s equipment and service, traffic engineers can record traffic using video and then get accurate data from the video without having to send people to manually count cars at an intersection. Awesome, right!?

miovision traffic data equipment and software

Now imagine being the traffic engineer, having a very clear expectation of the data you want to get back because you know the intersection intimately. However, when you get the data back, you’re confused and frustrated at why there are only three legs of the intersection counted instead of four. What’s going on, you may ask?

nighttime shot of intersection and trailing lights from car movement

Problem Statement

Customers Frustrated & Operations Team Under Stress

Customers didn’t receive the complete report they were expecting and became frustrated. Miovision was also losing money by having to reprocess the count, and the operations team was under a lot of stress to get correct data back to the customer immediately.

My Role

I was the sole designer responsible for finding the root cause of some quality issues, designing a solution to solve the root problem and validating the design.

Discovery

Identifying the Root Problem

Quality in manufacturing and software design became a growing issue as Miovision scaled.

As part of the organisation’s quality improvement initiative, I synthesised support cases to arrive at the most impactful quality issues that software could solve.

In sifting through thousands of support cases, identifying patterns and labelling them, the first problem which we decided to address was the case of incomplete traffic data.

Amongst all the cases of missing traffic data, a recurring theme was that our operations team did not fully understand what the user wanted. It became evident that our operations team was not able to interpret an intersection based solely on the video and the limited information our users provided us.

complex intersection

Limitations

A Complete Redesign Was Not Feasible

The goal of the project was to address low hanging fruits – biggest return for the least amount of work. Our software was archaic and had a lot of tech debt which meant any change would require a lot of development and QA effort. I was limited in what I could redesign and was confined to use the existing UI framework as well.

There was also a sense of urgency to fix the problem ASAP. It didn’t have to be perfect. It just needed to solve the problem.

Design Process

Focus on Usability and Functionality

I wanted to allow users to easily tell us what data they were expecting so that we could reduce the ambiguity for our operations team.

In the original version, the user was only able to tell us which leg of the intersection was considered “North” and where he/she placed the camera for the recording.

Screenshot of Original Annotation Step

screenshot of original annotation step

Challenges with this Annotation
  • What if there was no North direction?
  • What if the number of legs in the intersection on the map didn’t match the video? Was the map out-of-date or was the video of a different intersection due to user error?
  • What if the there was a driveway slightly offset from the intersection that the user wanted to include in the TMC?
  • What if a street was one-way? The report would publish a zero count for a particular movement when that movement technically didn’t exist and should not be included in the report.
Ideal User Flow for Less Ambiguity

Define the number of legs in the intersection

Allow naming and visual annotating of each leg in the intersection

Place the camera(s) on the map to identify the vantage point(s)

Provide help text to prompt for clarification of complex intersections

The lead developer quickly informed me that it was going to be very time intensive to re-order the annotation steps because the back-end required a “North” leg to be specified first. We could change the back-end but then major code refactoring would be required because the back-end integrated with an even older system that was bug prone. If I wanted a fast implementation, I could only insert additional steps after “North” was defined.

Practical User Flow for Quick Fix

Given the time urgency and limitations, I arrived at a modified user flow which would still capture the necessary information to make the intersection less ambiguous.

Place the North icon on the map (even if there is no North leg)

Place the camera(s) on the map to identify the vantage point(s)

Define the number of legs in the intersection

Allow naming and visual annotating of each leg in the intersection

Provide help text to prompt for clarification of complex intersections

Wireframes of Redesigned Annotation Steps

wireframe of redesigned annotation step 1

Wireframe of redesigned annotation step 2

(1) Provide more prominent instructions for the beginner user.

(2) Require the user to specify the exact number of legs at the intersection to reduce ambiguity.

(3) Give the user the option of specifying the exact cardinal directions of the legs of the intersection and the ability to name the streets which would customise their reports.

(4) Give the user the option of annotating each leg on the map to provide a visual reference for themselves and our operations team.

(5) Give the user the option of specifying more instructions on how they want the traffic counted in atypical situations.

Validation

Can Our Users Understand the Change?

Before going to the customer, I guerilla tested using internal teams (operations, support, sales, engineering) to make sure I wasn’t totally off the mark. Colleagues understood the interface, so next step was to get validation from real customers.

We set up conference calls with two customers, shared our screen to show them what was being proposed, and asked if the new design would help them feel more confident in getting the correct data that they wanted. Both customers concurred that the new design would allow them to be more specific in defining what they wanted. They also liked the ability to label their streets within the interface ahead of getting their reports so that when the data came back to them, it would be easier to read and interpret.

I wanted to express praise for the revision of TDO, because you can enter the street name before the upload now.

Mit freundlichen Grüßen
i.A. Tino Junker
Outcome

Saved Over $180K in Annual Operations

By fixing this usability issue, the company stopped receiving support cases of inaccurate or missing data due to ambiguous annotations and the estimated savings based on past service revenues would be $182,500 annually. A value-add was also created for the user by allowing them to label the intersection legs during the upload configuration process as opposed to after downloading the reports.

Screenshot of Redesigned Annotation Step in Production

screenshot of redesigned annotation step in Production

Reflections & Learnings

Working Within the Confines of Archaic Code

It was a challenge to work within the limitations of what could or could not be easily changed in the existing user flows and UI because of back-end implications.

Start-ups often rush to make MVPs of everything and soon tech debt starts accumulating. When designing fixes to usability bugs for software that was written without a lot of planning or foresight, one is tempted to axe everything and start fresh. However, that isn’t always practical nor does it make business sense.

On the other hand, it’s also unwise to take a developer’s word of technical limitations at face value. In hindsight, I could have tried harder to challenge the status quo and brainstorm of a way to get around the technical limitations. Maybe it didn’t need to involve major code refactoring if we could think of a creative solution? In the future, before giving up on what I believe to be the best solution for our users, I would set a time-boxed session with the developer(s) to brainstorm ways to overcome the limitation.