top of page

Ericsson Connected Urban Transport

Project Overview

Ericsson Connected Urban Transport is a web-based traffic management system developed for the City of Dallas.

 

It supports real-time monitoring and management of traffic infrastructure by bringing together data from multiple sources into one operational platform used by different roles across the city.

Problem Statement

The City of Dallas was using an outdated traffic management system where data and operations were spread across different tools and departments.

 

Because of this, operators didn’t have a clear real-time overview and it was difficult to monitor traffic, coordinate actions, and respond quickly to issues in a complex urban environment.

My Role

I worked as one of two UX designers on a large-scale traffic management system, taking ownership of designing features for complex operational workflows.

  • Designed interaction flows and UI for managing traffic devices and system operations.

  • Translated complex requirements into clear, structured designs that could be implemented by developers.

  • Worked closely with developers and stakeholders to make sure designs were realistic and aligned with system constraints.

  • Since there was no design system at the time, I created reusable components and patterns to keep the UI consistent across the system.

  • Participated in PI planning sessions, contributing to discussions around feature scope, requirements, and feasibility

Understanding the Users

The system supports multiple user roles with different responsibilities across traffic management operations. Each role interacts with the system differently based on its responsibilities.

These roles were identified based on stakeholder input and insights from a one-time on-site visit in Dallas.

 

Examples user roles: ​

Design Challenges

Working on this system came with a few challenges:

  • There were multiple user roles with different responsibilities, which made it harder to design flows that worked well for everyone.

  • Technical constraints had a big impact on what could actually be built, so I had to work closely with developers.

  • The design system was still evolving, so keeping the UI consistent across different parts of the product required ongoing effort.

  • Access to real users was limited, so many decisions were based on indirect insights and internal feedback.

Creating Device Groups
One of the features I designed as part of this system

Creating device groups needed to support different situations. In some cases, users needed to build a group by selecting devices one by one, while in other cases they needed to select multiple devices at once based on their location on the map.

To support this, I designed two ways of creating a device group. Users could add devices individually for more controlled selection, or draw a boundary on the map to select and group multiple devices at once that allowed them to choose the most efficient way depending on their task, especially when working with many devices in dense areas.

1-Create Device Group by Drawing on the Map​​​

This approach allows users to create a group by selecting an area directly on the map instead of adding devices one by one.

 

Users can draw a boundary on the map, and all devices within that area are automatically selected and added to a group. This is especially useful when working with many devices in the same location.

2-Create Device Groups by Selecting Devices from a List​

This approach allows users to create a group by selecting devices individually from a list.

 

It works well when users need to pick specific devices that may not be located close to each other on the map.

Design Process in Practice

The design process followed a typical UX approach, but in practice it was shaped by system complexity and limited access to users.

  • Requirements mostly came from stakeholder discussions and internal walkthroughs.

  • User understanding was based on indirect insights and one on-site visit.

  • Designs were iterated through feedback from developers and internal reviews.

  • Close collaboration with developers was important to ensure feasibility.

bottom of page