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!?
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?
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.
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
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
(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
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
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.