Applied Concepts, Inc. / Stalker Radar
Designing Data-Rich Tools for Traffic Device Management
Introduction
Applied Concepts, Inc. is the manufacturing name behind the brand Stalker Radar. They develop 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 design Street Dynamics — a next-generation traffic data dashboard that allows users to configure highway traffic devices and extract data to generate reports and charts. This dashboard is intended to replace dated Stalker software that city workers and traffic professionals rely on daily.
My focus within the project was the Device Management flow — the entry point for the entire dashboard, since users cannot access any other part of the product until they've successfully connected and configured their devices. 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.
The Problem
The existing Street Dynamics software hadn't kept pace with the complexity of the work it supported. Through analysis of the dated portal, we identified three core issues:
Device information was fragmented across tabs and modals, requiring multiple clicks to understand a single device's status
Settings were a flat, unprioritized list with no guidance on what needed attention or in what order
Large portions of the screen sat empty despite the volume of data the software was meant to surface
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.
Research and Early Ideation
We started by auditing the existing Street Dynamics portal to understand what it surfaced, what it was missing, and where it was breaking down.
From there, our research had three 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
We also incorporated a recommendation from senior guidance to add device history to the settings — something the existing software didn't support.
Information Architecture
We mapped our IA starting with a Device Management homepage, branching into individual device pages.
Wireframing Process
We set off to start wireframing both of these pages, the Device Management landing page and the individual device page.
Device Management Landing Page - Low Fidelity
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.
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.
Individual Device Page
One early stakeholder directive was to avoid tabs entirely. We took that seriously — we designed a full page-driven layout first. But when we put it in front of us, the result was overwhelming. The volume of configurable settings for a single device was too dense to present without some form of sectioning.
That's what led us to a tab-driven design. Tabs weren't the problem — they were the solution to it.
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.
Impact
Because this product is still in development, I'm not yet able to provide usage data or metrics. That said, the design decisions made throughout this flow were intentional in reducing cognitive load — through clear information hierarchy, scannable layouts, and at-a-glance status indicators that let users quickly assess device health without digging.
What I Would Do Differently
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 was my first time designing for information-dense screens, and it pushed me to think more deliberately about hierarchy than any project before it. Designing for users who need to assess device status quickly — often under time pressure — meant every layout decision had a direct consequence on clarity.
I also learned how much context matters before a single wireframe gets drawn. Studying the existing software closely shaped what we included, what we cut, and how we structured the flow.
Conclusion
The final Device Management flow addressed the core issues we identified at the start — fragmented information, flat hierarchy, and underused screen space — by giving users a single scannable entry point into their devices, a clear at-a-glance status layer, and a tab structure that reflects how they actually move through their work rather than how the data happens to be organized.