Transport NSW — SCATS Traffic System

Translating policy-heavy transport operations into scalable, usable workflows

Overview

SCATS is a legacy desktop-based traffic control system used to monitor and manage live intersection performance. The goal of this project was to modernise the interface into a web-based application, improving usability, accessibility, and operational clarity while respecting strict architectural constraints.

I led the redesign of site investigation workflows, focusing on map-based context, note management, and operational visibility.

Context

SCATS (Sydney Coordinated Adaptive Traffic System) supports traffic management operations and service workflows.

The platform involved:

• Data-heavy operational dashboards

• Policy-driven processes

• Multi-role user access (operators, analysts, administrators)

• Strict governance and regulatory constraints

Users needed to interpret complex operational data and execute time-sensitive decisions within defined compliance frameworks.

However, the existing workflows were:

• Fragmented across modules

• Dense with policy and operational detail

• Inconsistent in interaction patterns

• Difficult for new users to onboard into

My Role

Senior Product Designer (Accenture delivery team):

• Led workflow mapping and service blueprint creation

• Conducted stakeholder workshops and co-design sessions

• Translated policy and operational requirements into structured interaction patterns

• Built reusable Figma design systems for consistency

• Partnered closely with product managers, BAs, and engineers

Outcome

Impact included:

• Reduced clarification cycles between designers, BAs, and engineers

• Improved workshop alignment across cross-functional teams

• Faster design production through reusable components

• Increased consistency across operational modules

Strengthening the design system reduced design time from 8 hours to 1 hour and shortened elaboration from two sprints to half a sprint — improving delivery speed and predictability.

This project laid the foundation for more structured, scalable UX practices in later enterprise roles.

Current application

The Problem

The core issue was not missing functionality — it was structural complexity.

Users struggled with:

• Navigating between operational views

• Interpreting dense policy language in workflow steps

• Understanding task ownership and sequence

• Managing data-heavy interfaces with limited hierarchy

Operational teams often relied on internal knowledge or manual clarification rather than trusting the interface.

This created friction and slowed service processes.

Discovery & Approach

Research & Stakeholder Alignment

Due to limited direct access to end users, I worked closely with internal stakeholders across Product, Engineering, and Operations to align on business goals, constraints, and existing assumptions.

This phase focused on:

• Understanding regulatory and operational constraints

• Identifying known friction points from support and internal teams

• Mapping existing workflows and data dependencies

• Aligning on technical feasibility early

By bringing Product, Design, and Engineering together at the outset, we reduced downstream rework and ensured the solution balanced user needs with architectural realities.

User Persona Caption (SCATS)

User Persona — Traffic Operations Officer

To ground the redesign in real operational context, I developed primary personas representing traffic operations and service teams.

The primary persona — a Traffic Operations Officer — was responsible for monitoring live data, responding to incidents, and coordinating across departments under time pressure.

Key characteristics:

• High-stakes, time-sensitive decisions

• Dependent on accurate, structured data

• Working within strict policy and compliance frameworks

• Low tolerance for ambiguous workflows

This persona helped anchor design decisions around clarity, speed, and error prevention in regulated environments.

Journey mapping - Operational Workflow Analysis

I mapped the end-to-end service workflow from incident identification to resolution, identifying friction points across:

• Data interpretation

• Task ownership

• Policy validation steps

• Cross-team handoffs

The journey map revealed:

• Redundant navigation between modules

• Policy instructions embedded inside action screens

• Lack of clear progression indicators

• Unclear accountability during escalation

These insights informed the restructuring of task flows and the separation of policy guidance from actionable UI components.

Problem Definition Workshop

With limited customer access, I facilitated a cross-functional workshop with 9 representatives from Product, Design, and Engineering to surface assumptions and define the real problem space.

Goal:
Move from feature requests to validated problem statements.

Activities included:

• Knowledge sharing session to align on current system behavior

• Assumption mapping to uncover hidden constraints

• Categorising site notes, messages, and system messages

• Defining in-scope vs out-of-scope boundaries

Key outcomes:

• Clarified ownership and lifecycle differences between message types

• Identified redundancy between site notes and system messages

• Defined MVP scope (create, edit, delete)

• Parked complex areas (permissions, migration, search) for future phases

  This workshop prevented over-engineering and helped the team align on a realistic first release.

Ideation & Rapid Exploration

Following alignment, I translated workshop insights into rapid sketch explorations.

The goal was to:

• Explore multiple layout options

• Test interaction models for message creation and editing

• Balance system-wide visibility with contextual relevance

• Validate feasibility with Engineering early

Over several iterations, concepts evolved from broad structural changes to lighter, incremental improvements that respected existing architecture.

Concept Exploration

Design A — Dedicated Pop-up Panel

This concept introduced a focused pop-up panel for creating and viewing notes without leaving the map context.

Strengths

• Provides more visual space for content, improving readability.

• Allows larger icons and typography — better suited for eligibility and status visibility.

• Enables users to review multiple items without navigating back and forth.

• Reduces cognitive switching between map and content views.

Trade-offs

• Requires additional UI layer and engineering effort.

• Introduces another interaction state to manage.

• Potential complexity in maintaining consistency with existing panel patterns.

This option prioritised usability and clarity but required additional development investment.

Integrated Info Panel (All-in-One)

This concept reused the existing information panel to manage notes and messages within a single structured layout.

Strengths

• Keeps all interactions within the existing system pattern.

• Minimises development effort by leveraging current components.

• Maintains interface consistency.

Trade-offs

• Limited space reduces readability.

• Smaller icons and typography impact scanability.

• Requires more back-and-forth navigation to review content.

• Less suitable for content-heavy workflows.

This option was technically efficient but introduced usability compromises under high-volume scenarios.

Slack-Style Inline Composer

Inspired by chat-based interaction patterns, this concept allowed users to type and post notes directly within the map interface.

Strengths

• Encourages fast note entry.

• Familiar interaction model for users.

• Lightweight and flexible for quick updates.

Trade-offs

• Disconnected from structured note management.

• More complex to implement within the existing architecture.

• Risk of increasing information noise without hierarchy controls.

• May not align with enterprise governance requirements.

This concept optimised speed but raised concerns around structure, scalability, and technical feasibility.

Decision Rationale

After evaluating usability impact, development effort, and system constraints, we prioritised a solution that balanced readability improvements with architectural feasibility.

Rather than pursuing a full structural redesign, we adopted a lighter implementation that improved clarity while remaining within delivery timelines.

This demonstrates trade-off management — not just design preference.

UI workflow

Scope of Design & Delivery

The release focused on enabling full lifecycle management of site notes within the map interface.

Core Capabilities

• View existing notes

• Create new notes

• Edit and save updates

• Delete notes

System States Considered

• Overview visibility while editing

• Maximum character limits

• Empty states

• Loading indicators

• Error states (update failure, load failure)

This ensured the experience was robust — not just visually complete.

User Workflow — Editing and Saving Notes

Edge Cases & System States

To ensure the experience was production-ready, I designed for key edge cases beyond the happy path.

Covered States

• Confirmation before deletion to prevent accidental data loss

• Inline error handling when notes fail to save or load

• Loading indicators during network delays

• Clear empty states when no notes exist

• Capacity warning when maximum notes are reached

Designing these states ensured the feature was resilient, predictable, and aligned with operational governance standards.

Reflection

This project shaped my approach to enterprise UX.

Key learnings:

• In regulated environments, clarity must coexist with compliance.

• Service design and workflow mapping are critical before UI decisions.

• Standardised patterns reduce long-term delivery friction.

• Large-scale systems require alignment across policy, operations, and engineering.

SCATS marked my transition from interface design to systems thinking — a foundation that later informed my work on complex SaaS platforms like Capsifi and LandIQ.

Next Case Study