Brief

Quality Counts had an experimental web app for exploring traffic-count data, but the product needed a production-ready experience. I led creative direction, redesigned DataPoint, and created the Cardinal design system while partnering with Quality Counts and a contracted development team. The team shipped DataPoint 2.0 with new tools for understanding whether road sections and intersections were below, near, or over capacity.

Operating context

City planners and traffic engineers needed enough detail to analyze intersections and midblocks. Residents needed a faster way to check traffic conditions and test assumptions about their communities. The same product had to support both groups without turning every view into an expert-only interface.

The original product centered on a map. Customers selected an intersection or midblock, reviewed a small overview panel, and opened a separate view for detailed count data. That model exposed useful information, but it did not provide a clear product structure for search, comparison, deeper analysis, or future modules.

Constraints

• I entered the project without prior traffic-planning or city-government experience.
• Quality Counts was building its first production software product.
• Historical traffic data varied in structure and quality.
• The product had to work for residents and technical customers with different levels of domain knowledge.
• Each customer had a separate DataPoint instance and city-specific URL.

Responsibility

I was the sole designer on the project. I owned the product experience, interface design, visual direction, and Cardinal design system. I also studied the traffic-planning domain, interviewed Quality Counts staff and prospective city customers, and translated that research into product scope and interaction decisions.

Quality Counts supplied domain and business context. I partnered with its internal team and the contracted development team as they implemented the product. Decisions about product scope were collaborative; I did not write the production application.

Decision 01 — Design for the web

Condition

Traffic engineers often used desktop software built around older Windows interaction patterns, while residents arrived with expectations shaped by modern map products.

Decision

I defined DataPoint as a web-native product instead of reproducing a desktop application in the browser.

Rationale

The interface could remain available from any connected computer while using familiar web navigation, search, filtering, and progressive disclosure.

Tradeoff

Some expert workflows could not be copied directly from legacy tools. We had to decide which controls belonged in the main interface and which required a deeper analysis view.

Evidence

Competitive analysis, an audit of the original product, and conversations with Quality Counts and prospective city customers established “modern” and browser access as recurring needs.

Decision 02 — Separate overview from analysis

Condition

Some customers wanted a quick status check. Others needed detailed count files, turning movements, peak periods, vehicle types, and capacity controls.

Decision

I organized DataPoint 2.0 around three connected surfaces: a search and filter bar, a map, and a contextual inspector. Selecting a station opened deeper analysis in a modal, with an option to move the station into a separate browser tab for comparison.

Rationale

The map and inspector kept common information close to the current task. The modal created room for detailed analysis without loading every control into the default view.

Tradeoff

The modal worked for one station at a time. Comparing several stations still required separate tabs, which became a clear follow-up problem.

Evidence

The shipped structure supported browsing visible stations, inspecting one station, and moving into detailed intersection or midblock data without changing the product’s core map model.

Decision 03 — Provide basic and advanced capacity controls

Condition

Newer engineers needed a readable starting point, while experienced customers needed control over the inputs behind intersection-capacity analysis.

Decision

The Capacity Planner and Simulator used a basic mode for common decisions and an advanced mode for direct control. The calculation was based on the Highway Capacity Manual and a formula supplied by engineers at Kittelson.

Rationale

One module could support different levels of expertise without forcing every customer through the most complex version of the workflow.

Tradeoff

Progressive disclosure reduced the initial density, but it also made the transition between quick review and detailed analysis an interaction that required continued validation.

Evidence

The shipped intersection workflow included both modes and exposed the underlying traffic-count inputs in the advanced view.

Decision 04 — Create a shared product foundation

Condition

Quality Counts needed to improve DataPoint while testing other software ideas.

Decision

I created Cardinal as the shared design system for DataPoint and adjacent product concepts.

Rationale

Reusable interface patterns gave the team a consistent base for product work instead of treating every concept as a separate visual system.

Tradeoff

The system introduced shared patterns that needed maintenance and adoption. The project did not measure either cost.

Evidence

The team used Cardinal while exploring related concepts, including computer-vision traffic counting as an alternative to physical road tubes.

System specification

DataPoint 2.0 used a small set of stable interface regions:

• Search and filter bar: Located stations and narrowed the data shown on the map.
• Map: Displayed intersections, midblocks, traffic signals, bus stops, and crash data with distinct iconography.
• Contextual inspector: Summarized either all visible stations or the currently selected station.
• Intersection analysis: Organized station details, traffic counts, and capacity planning into three tabs.
• Midblock analysis: Separated station details from directional vehicle-count charts and filters.
• Support: Integrated Intercom into the application to connect onboarding and customer-support workflows.

The detailed views retained export paths for customers who needed to continue analysis in tools such as Excel.

Validation

I spent my first month studying the existing product and traffic-planning domain. I interviewed Quality Counts staff and contacted cities that had already seen a DataPoint demonstration. I also audited the original interface and compared the tools used by engineers with the map products familiar to residents.

These inputs shaped the product scope and interaction model. The project did not produce a reliable task-success, support-volume, or implementation-time metric, so those claims are not part of this retrospective.

Outcome

The team shipped DataPoint 2.0 and its new capacity-planning workflow. When I last spoke with Quality Counts, about 30 customers were waiting to be onboarded. That queue was a demand signal, not evidence of adoption, retention, or task efficiency.

Cardinal also gave the team a shared interface foundation for testing adjacent product ideas. We did not measure how much time the system saved or how consistently it was adopted across those concepts.

Revision notes

The most durable decision was separating quick checks from detailed analysis. Expert users still benefit from a clear default view when the product provides deliberate paths into advanced controls.

I would now prioritize three follow-up areas:

1. Build internal tools to validate and clean historical data before import.
2. Test a unified DataPoint instance so cities can share data without separate product URLs. I proposed this direction, but the team postponed it beyond the 2.0 release.
3. Test windowing or minimized stations for side-by-side comparison instead of relying on separate browser tabs.

I would measure onboarding completion, time to find a station, errors during data import, use of basic versus advanced capacity controls, and the number of stations compared during a planning task.

Artifacts

• DataPoint 2.0 Figma file
• Original DataPoint interface audit