Incident response.

The problem

VicRoads Incident Response Officers keep traffic moving after crashes, breakdowns, debris, and spills. Their reporting process was manual. Notes were taken in the field, then typed up on two shared desktops at the end of the shift.

It worked, but it was slow, inconsistent, and created rework. Officers were doing their job twice: once on the road, once back at base.

I joined as the UX and UI designer to translate existing discovery into an iPad-based web app officers could use on the road. The result needed to be a focused tool that simplified incident capture, supported stop-start conditions, and provided clear handover assets to reduce delivery friction.

Context and constraints

The solution had to run in Safari on iPad, portrait only, and integrate with ServiceNow. It needed to comply with Victorian Government branding and style rules. Connectivity could be unreliable, officers wore gloves, and shifts were busy and interrupted.

Formal testing was limited, but officers were available for interviews and quick reviews. I worked alongside a Service Designer and a small delivery team after environments were already stood up.

What I did

• Owned application flow, interaction design, and visual design
• Worked with Product Owner and Service Designer to confirm scope and fill missing flows
• Produced a UI kit so developers had a single source of truth for components, states, and spacing
• Kept decisions pragmatic so the team could ship

Getting aligned quickly

Met the Product Owner to confirm expectations and identify gaps. One immediate gap: application login and the ability to change the officer's vehicle or coverage area. Added these flows and their acceptance criteria to the backlog.

Key insight: Officers were blunt about what they didn't need. They wanted the fastest path to recording what mattered and getting back on the road. Anything decorative or "helpful" that slowed them down was noise.

Grounding decisions in real work

Worked with the Service Designer to interview officers and map the highest-frequency actions. Kept flows linear and form-based. Reduced choice on each screen to the essentials.

Planned for stop-start usage with a simple save-and-return pattern. Officers are interrupted, diverted, and often need to resume later without losing context.

Designing a structure that speeds up work

Critical design decisions:

• Home as the launcher for real tasks. Two primary buttons officers asked for were front and centre: "Add new incident" and "Incident list".
• Incident form as a guided workflow with status and a clear progress indicator. Only show what is needed to move forward.
• Full-screen overlays for sub-tasks such as "Add involved vehicle", "Record lane closures", and "Add other services", preserving context.
• Incident list compact enough to scan on a busy shift, with colour for incident type and an explicit status field. Sorting and filtering kept strict to avoid confusion.

Building in compliance and consistency early

Embedded Victorian Government style rules directly into the Sketch library so typography, spacing, colours, and components were aligned from the start. This reduced rework and helped the UI kit match what was built.

Validating, trimming, and handing over

Officers reviewed early prototypes and were blunt about what they didn't need. That let me remove low-value options and simplify labels. I iterated the list view several times to balance information density and legibility.

Once stable, I delivered a UI kit with component specs, states, spacing tokens, and examples, so developers had clarity without guesswork.

What happened

The team replaced end-of-shift re-typing with an on-shift, structured workflow. Officers could record an incident, add vehicles and lane closures, and capture supporting details while still on the job.

The interface reduced cognitive load through large targets, clear labels, and only the next necessary decision on each screen. The UI kit reduced ambiguity for developers and sped up delivery because component behaviour and spacing were already decided.

While formal metrics were outside my remit, stakeholder feedback focused on fewer end-of-shift queues, cleaner data entry, and less double handling.

What I learned

This is practical product thinking. Join late, find the gaps, simplify decisions, and give delivery exactly what it needs. It's not glamorous. It works.

If I could do it again, I'd instrument key steps to track time to complete, edit rates, and abandon points. Add offline caching to cover dead zones. Expand filters and search on the list once real usage patterns are known. Integrate basic analytics into ServiceNow dashboards so operations can see where incidents stall and where training would help.