Adelaide Metro: Customer support forms

Adelaide Metro is South Australia's public transport network. Trains, trams and buses, used across the state every day. When a journey goes wrong, the forms on the Adelaide Metro website are how most people reach the team who can do something about it.

I joined the project as design lead for those support forms, in a team of six. My remit covered the full suite, feedback, enquiries, compliments and complaints, plus the design system underneath them. The complaints form was the hardest of the four, and it's the one worth talking about.

Nobody fills out a complaint form on a good day. Their trip has gone wrong, they're already frustrated, and now they have to explain what happened to a website.

The old form made that harder than it needed to be. The categories people picked from were built around the organisation's internal departments, not around how a customer actually thinks about their problem.

The single most common complaint, a late bus, was buried three levels down: Bus, then Service reliability, then Late.

So a stressed person had to learn the organisation's structure before they could say what was wrong. Some did. Others gave up looking for the right category and filed under whatever was closest, which meant the complaint landed with the wrong department and took longer to resolve. The form also revealed one field at a time as you answered, which made a quick task feel slow.

I couldn't see exactly how long people spent hunting for the right category. But the pattern in where complaints landed told the story clearly enough.

The fix was to stop asking people to think like the organisation, and instead let them describe what happened in their own words.

I rebuilt the information architecture around the customer's experience. The late-bus path is the clearest example. Same destination, but the new path meets the frustration first and gets people to the form faster. It opens with the thing that's actually on their mind.

I also clustered categories by where the customer's attention sits, not where the org chart puts them. Complaints about InfoLine staff used to live under "Information and communication"; customers look under "Staff", so that's where they went. Security staff issues had been split by whether the incident was onboard or off; but to a customer, the point is that it involved a security staff member, not where it happened, so those came back together.

The constraint that made this interesting: none of it could disrupt the teams receiving the complaints. The internal, department-based structure still exists in the CRM. I designed a mapping so every new customer-facing category resolves cleanly back to an existing back-end one. I owned the information architecture and the form design; engineering implemented the configuration against that mapping. Customers get language that makes sense to them, and every complaint still routes to exactly the right team.

The rest of the work ran underneath this: building and maintaining the design system the whole suite uses, designing to WCAG 2.2 throughout, synthesising years of past user research with LLMs to find the real pain points, and prototyping quickly in Figma Make. Throughout, I worked with the product owner, engineers, and the customer experience and care teams, and ran workshops to gather requirements and bring people along.

The complaints form is still rolling out, so I can't point to a post-launch number for it yet. But the same approach shipped earlier on the feedback and enquiries form, and the early signal is encouraging.

In the three months after that form went live, submissions rose by about a third year on year (March to May in 2025 v 2026). That's an engagement signal rather than a controlled result, but it points the right way. One piece of anonymous user feedback put it simply: the new form was easier to navigate and better to use than the old one.

The deeper result is the one that doesn't show up in a chart. The customer-facing experience was rebuilt around how people actually feel, with zero disruption to the operations behind it. That was the hard part, and it held.

The natural next step is conversational support on the landing page, meeting people with a plain "what's gone wrong?" before they touch a form at all. That work is still an early concept, not something that's shipped. But it's the logical end of the same idea: let people describe their problem in their own words, and do the translation for them.