UX & Dashboard Redesign
Designing Data-Rich Tools for Traffic Device Management
Overview
Applied Concepts, Inc. develops radar, lidar, and traffic data collection technology used by municipalities, transportation departments, and law enforcement agencies across the United States.
I worked within a small team of three designers to redesign Street Dynamics: a traffic data dashboard that allows users to configure traffic devices and extract data to generate reports and charts. This dashboard will replace the current, dated software that city workers and traffic professionals rely on daily.
My ownership: the Device Management flow — from IA through high-fidelity
Impact
Because this project has been handed off and is still under development, I am not able to provide specific metrics. However, this design:
Reclaimed an estimated 40–60% of previously unused screen space.
Reduced clicks-to-status from an estimated 4–6 interactions to just 2-3 interactions.
Built to accommodate 2+ additional device types without requiring a structural redesign.
The Problem
The existing Street Dynamics software hadn't kept pace with the complexity of the work it supported. Through analysis of the portal, we identified three core issues:
Issue 1
Information was spread across modals, requiring multiple clicks to understand device status
Issue 2
Settings were flat and unprioritized with no guidance on what needed initial attention
Issue 3
Large parts of the screen sat empty despite the volume of data the software was meant to surface
Dated Software UI
The goal wasn't just to modernize the visual design, it was to restructure the experience so users could orient quickly, reduce unnecessary navigation, and move through configuration with more confidence.
My Role
My focus within the project was the Device Management flow. The purpose of this flow is to allow users to check device health and status at a glance. I worked alongside two other UX designers to take this flow from research through high-fidelity design.
Current Street Dynamics Software
Research and Early Ideation
My research had four focus areas:
The TDC2 Device
We studied the user manual in depth to understand the full scope of what needed to be configurable in the interface
Industry Standards
We researched device management flows in fleet technology products like Miovision and Intuit, identifying common patterns like at-a-glance status cards and online/offline device grids
Scalability
We made an early decision to design for scale, building a structure that could accommodate future devices without a full redesign
The Current Dashboard
We studied the current dashboard design to see what information was presented.
Information Architecture
Based on research findings, we mapped our IA starting with a Device Management homepage, branching into the individual device page. We took the one page layout very seriously here.
Device Management Landing Page - Wireframing
I set off to start wireframing the Device Management landing page, while Varshni did the individual device page.
My first iteration organized devices into two separate tables: Previously Connected and Connected. The goal was to surface as much relevant information as possible at a glance while reducing wasted space.
Device Management - Early Wireframe
After reviewing with my mentor, I consolidated the two tables into one. Two tables created unnecessary separation, a single table is easier to scan and allows more devices to be listed at once. I also reframed the categories from Connected/Previously Connected to Online/Offline, which is a clearer and more industry-standard distinction for this type of tool.
From there, I added summary cards at the top of the page to give users an immediate status overview before engaging with the table: total devices, how many are online, how many are offline. This kept the table focused on details while the cards handled the at-a-glance layer.
Finally, I incorporated a grid view toggle alongside the list view. This was requested by the Web Apps Developer and aligns with industry-standard device management patterns, giving users a visual alternative when scanning a large number of devices.
Device Management - High Fidelity Wireframe
Individual Device Page - Wireframing
I jumped in to help Varshni with her screens, as hers were very complex. One early stakeholder directive was to avoid tabs entirely. We took that seriously; we designed multiple low fidelity page-driven layouts first, seen below.
Individual Device Page Exploration
But the result was overwhelming. The volume of configurable settings for a single device was too dense to present without some form of sectioning.
I recommended that we revisit the tab-driven design. We found that tabs weren't the problem; they were the solution to it. We just needed to implement it in the right way. Seen below is the early exploration of the tab-driven design.
Individual Device Page Tab Exploration
Our medium fidelity version organized the individual device page across four tabs: Settings, Battery Trends, Deployment History, and Device Data.
While this moved us in the right direction, after reviewing it as a team, we came to the conclusion that the tab names were too narrow and technical: each one represented a single data type rather than a broader workflow. The page was also starting to feel fragmented, with too many isolated sections competing for attention.
In our next iteration, we consolidated and reframed the tabs into four broader categories: Device Overview, Device Settings, Scheduler, and Device History. This grouping better reflected how a user would actually think about and move through the page, starting with a high-level status view, drilling into settings when needed, scheduling device activity, and reviewing historical data. We also took this opportunity to adjust the UI design to better align with the rest of the application, by redesigning the header on the cards and spacing to fit more information and prevent scrolling.
Individual Device Page - High Fidelity
Next Steps
Due to the nature of the company, we weren't able to conduct user interviews or usability testing. If I had the opportunity, I'd want to test the Device Management flow with traffic professionals who configure and extract data from these devices regularly, specifically to validate whether the information hierarchy we built actually matches how they think about their work.
What I Learned
This project allowed me to grow exponentially in building confidence with pushing back on stakeholder feedback when necessary. The tabs were something that stakeholders were set on getting rid of, but explaining my design decisions and reasoning for taking a tab driven approach allowed us to put together the most ideal design, and allowed me to build my skills backing my design decisions.
Conclusion
The Device Management flow now gives traffic professionals what the original software couldn't: a clear picture of every device's status at a glance, and a logical path through configuration without unnecessary clicks.
UX & Dashboard Redesign
Designing Data-Rich Tools for Traffic Device Management
Before: Device status hidden across modals, flat settings, unused screen space
After: At-a-glance status cards, unified device table, scalable tabbed device pages
Overview
Applied Concepts, Inc. develops radar, lidar, and traffic data collection technology used by municipalities, transportation departments, and law enforcement agencies across the United States.
I worked within a small team of three designers to redesign Street Dynamics: a traffic data dashboard that allows users to configure traffic devices and extract data to generate reports and charts. This dashboard will replace the current, dated software that city workers and traffic professionals rely on daily.
My ownership: the Device Management flow — from IA through high-fidelity
Impact
Because this project has been handed off and is still under development, I am not able to provide specific metrics. However, this design:
Reclaimed an estimated 40–60% of previously unused screen space.
Reduced clicks-to-status from an estimated 4–6 interactions to just 2-3 interactions.
Built to accommodate 2+ additional device types without requiring a structural redesign.
The Problem
The existing Street Dynamics software hadn't kept pace with the complexity of the work it supported. Through analysis of the portal, we identified three core issues:
Issue 1
Information was spread across modals, requiring multiple clicks to understand device status
Issue 2
Settings were flat and unprioritized with no guidance on what needed initial attention
Issue 3
Large parts of the screen sat empty despite the volume of data the software was meant to surface
Dated Software UI
The goal wasn't just to modernize the visual design, it was to restructure the experience so users could orient quickly, reduce unnecessary navigation, and move through configuration with more confidence.
My Role
My focus within the project was the Device Management flow. The purpose of this flow is to allow users to check device health and status at a glance. I worked alongside two other UX designers to take this flow from research through high-fidelity design.
Current Street Dynamics Software
Research and Early Ideation
My research had four focus areas:
The TDC2 Device
We studied the user manual in depth to understand the full scope of what needed to be configurable in the interface
Industry Standards
We researched device management flows in fleet technology products like Miovision and Intuit, identifying common patterns like at-a-glance status cards and online/offline device grids
Scalability
We made an early decision to design for scale, building a structure that could accommodate future devices without a full redesign
The Current Dashboard
We studied the current dashboard design to see what information was presented.
Information Architecture
Based on research findings, we mapped our IA starting with a Device Management homepage, branching into the individual device page. We took the one page layout very seriously here.
Device Management Landing Page - Wireframing
I set off to start wireframing the Device Management landing page, while Varshni did the individual device page.
My first iteration organized devices into two separate tables: Previously Connected and Connected. The goal was to surface as much relevant information as possible at a glance while reducing wasted space.
Device Management - Early Wireframe
After reviewing with my mentor, I consolidated the two tables into one. Two tables created unnecessary separation, a single table is easier to scan and allows more devices to be listed at once. I also reframed the categories from Connected/Previously Connected to Online/Offline, which is a clearer and more industry-standard distinction for this type of tool.
From there, I added summary cards at the top of the page to give users an immediate status overview before engaging with the table: total devices, how many are online, how many are offline. This kept the table focused on details while the cards handled the at-a-glance layer.
Finally, I incorporated a grid view toggle alongside the list view. This was requested by the Web Apps Developer and aligns with industry-standard device management patterns, giving users a visual alternative when scanning a large number of devices.
Device Management - High Fidelity Wireframe
Individual Device Page - Wireframing
I jumped in to help Varshni with her screens, as hers were very complex. One early stakeholder directive was to avoid tabs entirely. We took that seriously; we designed multiple low fidelity page-driven layouts first, seen below.
Individual Device Page Exploration
But the result was overwhelming. The volume of configurable settings for a single device was too dense to present without some form of sectioning.
I recommended that we revisit the tab-driven design. We found that tabs weren't the problem; they were the solution to it. We just needed to implement it in the right way. Seen below is the early exploration of the tab-driven design.
Individual Device Page Tab Exploration
Our medium fidelity version organized the individual device page across four tabs: Settings, Battery Trends, Deployment History, and Device Data.
While this moved us in the right direction, after reviewing it as a team, we came to the conclusion that the tab names were too narrow and technical: each one represented a single data type rather than a broader workflow. The page was also starting to feel fragmented, with too many isolated sections competing for attention.
In our next iteration, we consolidated and reframed the tabs into four broader categories: Device Overview, Device Settings, Scheduler, and Device History. This grouping better reflected how a user would actually think about and move through the page, starting with a high-level status view, drilling into settings when needed, scheduling device activity, and reviewing historical data. We also took this opportunity to adjust the UI design to better align with the rest of the application, by redesigning the header on the cards and spacing to fit more information and prevent scrolling.
Individual Device Page - High Fidelity
Next Steps
Due to the nature of the company, we weren't able to conduct user interviews or usability testing. If I had the opportunity, I'd want to test the Device Management flow with traffic professionals who configure and extract data from these devices regularly, specifically to validate whether the information hierarchy we built actually matches how they think about their work.
What I Learned
This project allowed me to grow exponentially in building confidence with pushing back on stakeholder feedback when necessary. The tabs were something that stakeholders were set on getting rid of, but explaining my design decisions and reasoning for taking a tab driven approach allowed us to put together the most ideal design, and allowed me to build my skills backing my design decisions.
Conclusion
The Device Management flow now gives traffic professionals what the original software couldn't: a clear picture of every device's status at a glance, and a logical path through configuration without unnecessary clicks.