top of page

Ericsson Connected Urban Transport

Project Overview

Connected Urban Transport is an

Advanced Traffic Management System developed

by Ericsson for the City of Dallas, United States.

 

The system provides real-time traffic data from

multiple sources such as sensors, cameras, traffic

lights, and school flashers. It allows the city to monitor traffic conditions and share this information with neighboring cities and counties to improve traffic flow and coordination.

Problem Statement

The City of Dallas wanted to modernize its traffic management system by replacing the existing legacy system with something more intuitive and easier to use. The goal was to support better monitoring and management across departments and neighboring regions.

 

The existing system lacked integration, real-time insights, and proper collaboration tools, which made it difficult to effectively coordinate traffic and respond to issues.

My Role

I worked as one of two UX designers on the project, collaborating with developers, engineers, and product managers. I was involved in the full design process, from early concepts to implementation.

My responsibilities included:

  • Translating requirements into UX tasks.

  • Designed wireframes and interaction flows

  • Collaborated closely with frontend developers and cross-functional teams.

  • Built custom UI components as Ericsson’s design system was still evolving.

  • Participated in program increment (PI) planning sessions.

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 insights were gathered through a one-time Dallas visit, which helped define key

user roles, needs, and tasks.

 

Examples user roles: ​

Design Challenges

Limited access to real users

One of the biggest challenges in this project was limited access to real users.

The sales representative who owned the client relationship did not allow the UX team to directly communicate with users in Dallas. Instead, she shared the requirements with us through long internal meetings. 

During the entire project, we only had one opportunity to meet real users in person.

This meant we couldn’t conduct interviews or usability testing in a typical way.

 

To validate our designs, we had to rely on indirect methods. In one case, we prepared specific scenarios and tasks, which were tested with users remotely by someone on-site. Their feedback was recorded, and we later analyzed and grouped the findings to identify issues and improve the design.

 

 

No mature design system

 

Another challenge was the lack of a mature design system.

Since Ericsson’s design system was still evolving, many of the components we needed didn’t exist. As a result, we had to design and build a large number of UI components ourselves while still trying to keep the interface consistent.

Design Process in Practice

We understood the system through detailed walkthrough sessions with sales representative, where requirements and system behavior were explained.

A UX team member visited real users in Dallas to observe their workflows.

This helped us better understand user roles, needs, and how the system is used in practice.

​​​We translated requirements into UX tasks.

Due to a limited design system, we reused existing components or created new ones when needed, working closely with developers to ensure feasibility.

User testing was limited and conducted remotely.

We reviewed recorded sessions, identified issues, and iterated on the design based on feedback.

Designs were refined through iteration and prepared for implementation.

We aligned closely with developers and stakeholders to ensure the solutions were feasible and correctly implemented.

Design system

At the time of this project, Ericsson’s design system was still evolving, and many of the components we needed didn’t exist yet.

As a result, we had to design UI elements ourselves, including icons, visual styles,

and reusable patterns across the system.

Final Design

In this section, I present two approaches I designed for creating device groups to support different user needs.

Create Device Group by Drawing on the Map

This feature allows users to create groups of devices directly on the map by selecting an area instead of choosing devices one by one.

 

Users can draw a boundary on the map, and all devices within that area are automatically selected and saved as a group. This makes it much faster to manage devices based on location, especially in dense urban environments.

Create Device Groups by Selecting Devices from a List

This feature allows users to create device groups by selecting devices directly from a list,

as an alternative to drawing on the map.

 

It allows users to pick specific devices without being limited to a single area, making it easier to create precise groups when devices are spread across the map.

bottom of page