Designing one operational system for an entire city

The founder contacted me through Upwork while ATLAS was still at seed stage. The product structure had already been established and an early homepage had been built, but the team needed a clearer visual direction and a designer who could complete the wider platform.

Over the next two years, I designed the product interface across traffic monitoring, infrastructure management, notifications, scheduling and field operations. The work began with screenshots and product references, then evolved through continuous feedback from city officials, traffic operators, field employees and the internal team.

Traffic monitoring, infrastructure, notifications and field work lived in separate tools. The product had to bring them together without overwhelming administrators, operators or field employees.

• I refined the existing visual direction instead of replacing it, reserving bright colour for data, status and key actions.
• I separated information by role, so each person sees what they need for their next decision.
• I reduced Asset Management to one clear loop between an administrator and a field employee.

When I joined ATLAS, the product already had an established structure and a visual direction the team liked. The dark interface and colourful data visualisations gave the platform a distinctive identity, but the amount of colour across cards, buttons and controls made the homepage feel visually intense.

My first task was to refine that direction rather than replace it. I kept the dark foundation and enough of the purple, pink and blue accents for the product to remain recognisable, while reducing the large gradients and using brighter colours more intentionally for data, status and important actions.

I also improved the organisation of the homepage, creating clearer groups for Scores, Asset Management, Live View, Traffic Count, Notifications and Intersection Health. The result retained the character of the original design while making the platform feel calmer, more structured and easier to scan.

Once the homepage direction was established, the work expanded into the wider platform. ATLAS combined traffic monitoring, infrastructure management, employee activity and city operations in a way that did not have one direct product reference.

The founder shared feature ideas and screenshots from adjacent systems to explain how different capabilities could work. I translated those references into connected ATLAS dashboards, giving each feature its own purpose while keeping the navigation, visual language and interactions consistent across the product.

The first complete version made the wider product vision tangible. It gave the team something concrete to demonstrate to potential users and investors, and became part of the product presentation that supported ATLAS in securing its seed funding.

The first version was not treated as the final answer. As the product developed, I showed successive versions to city officials, traffic operators, field employees and internal stakeholders. Feedback came through product calls, demonstrations and Figma comments, then informed the next round of design decisions.

One important pattern emerged: each role needed a different level of information. City administrators needed oversight and the ability to assign and confirm work. Traffic operators needed real-time monitoring and deeper operational detail. Field employees needed focused mobile tasks they could complete quickly while working on location.

This became especially clear during a conversation about Asset Management. What initially seemed like a complex infrastructure workflow could be reduced to a straightforward exchange between an administrator and a field employee. That insight shaped how I approached later versions of the platform: show each person what they need to make the next decision, rather than exposing the entire system at once.

Live View gives traffic operators a central view of what is happening across the city. It brings together intersection activity, traffic conditions, vehicle movement and emerging issues without requiring operators to move between separate systems.

The main design challenge was managing density. Operators needed access to detailed information, but displaying everything at once would make the dashboard difficult to scan during active operations.

Operators can choose what they want to monitor—from specific vehicle classes to mobility, infrastructure and construction—while visual overlays make lanes, movement counts and traffic elements easier to interpret in real time.

Asset Management was the most unfamiliar part of the product for me. I needed to understand how city teams track physical infrastructure, report faults, assign maintenance work and confirm that an issue has been resolved.

My initial research suggested a complicated system with detailed asset records, lifecycle information and multiple operational states. However, a conversation with a city official helped reduce the core experience to one clear exchange between an administrator and a field employee.

The administrator identifies an issue and creates a work order. The assigned employee receives the task on their phone, travels to the location and scans the QR code attached to the asset. After completing the repair, they add a brief update and mark the task as complete. The administrator can then review and confirm the work.

ATLAS receives updates from different parts of city operations, including maintenance issues, traffic violations, congestion, crashes and responder activity. Without a clear structure, important events could easily become buried in a long list of routine updates.

I organised the Notification Center around recognisable categories, making it easier for users to narrow the feed to the type of activity they were responsible for. Notifications could also be viewed at team or employee level, helping administrators understand both wider operational activity and individual updates.

The goal was to make a large volume of information easier to scan without removing the context users needed to decide what required attention next.

Scheduling and employee activity needed to work as one connected experience. Administrators required a clear view of upcoming work, employee availability and active assignments, while field employees needed a simpler way to understand and update their day.

I designed the administrative dashboard around the information needed for coordination: scheduled activities, attendance, task status and employee progress. The mobile experience was intentionally more focused, allowing employees to clock in, view assigned work and move a task from Started to In Progress and finally Completed.

Keeping both sides connected meant administrators could follow operational progress without requiring constant calls or manual updates from employees working across the city.

The first complete version became part of the product presentation that supported ATLAS in securing its seed funding. The platform is fully developed and in pre-launch testing with city teams.

ATLAS was the first city-operations platform I had designed, and many of its workflows particularly traffic monitoring and asset management were completely unfamiliar to me when I began.

The project taught me how to work through an unfamiliar technical domain without allowing that complexity to take over the experience. I learned when to question requests for more functionality, how to separate information by user role and how valuable direct feedback becomes when designing operational tools.

I am most proud that I was able to design the complete product experience across desktop and mobile, turning scattered references and evolving requirements into a connected system that could be developed and tested with real city teams.

If ATLAS launched tomorrow, my next priority would be testing and refining the complete Asset Management work-order loop—from an administrator creating the task to a field employee completing it and the administrator confirming the result. It is one of the platform’s most important workflows, and the area where small improvements could have the greatest operational impact.