Using AI to map a complex product

Traffic management centres use the platform to manage incidents, devices, signals and traveller information. A new platform was being built, and both were in use at the same time. To plan the rest of the move, the business needed a full map of the current one.

The project started as manual mapping. Partway through, the stakeholders and I agreed that AI could do much of the work. So I changed direction and designed a method where AI handled the volume of work, and I checked every result.

There was information, but it was in pieces. I started with a gap analysis of what already existed. Earlier maps and documents were based on features, user stories or projects. Someone had started mapping workflows, but it wasn’t finished.

So the business couldn’t answer three questions:

• What can customers already do in the new platform?
• Which of their workflows can they complete end to end if they move?
• What is the migration status of each workflow: migrated, partly migrated, planned or deprecated?

A feature list shows what exists, but not whether someone can finish a real task. So we chose to map the platform’s full functional footprint through workflows: the end-to-end tasks operators do, and the capabilities each one relies on.

I was the contract Senior Product Designer on this work, and I owned it end to end.

• I owned the project management, documentation, method and approach, and the mapping itself.
• I tested the taxonomy. A parallel project defined shared terms, based on industry standards and the work of Australian and international intelligent transport system (ITS) bodies. I applied them across the whole platform to see where they needed to change.
• I worked closely with a researcher, who gave support and guidance throughout.
• I worked with product stakeholders and 15 subject matter experts (SMEs).

I applied four terms from the shared taxonomy: workflow, use case, capability and feature.

Then I ran a proof of concept on one module with around 20 workflows. I identified them manually, and validated them with one SME who was the expert in that module. This set the level of detail, the structure and the wording for everything that followed.

The AI got workflows wrong many times, so the rules mattered. Each workflow needed to show who does it, when it happens, what steps it takes and what outcome it produces. If an entry didn’t have all four, I moved it to a list of partial or potential workflows. Then I checked each one against the product to decide whether it qualified.

I processed the documents batch by batch. That kept each review small enough to check properly.

The checks also found errors across the catalogue. A consistency check showed 43 capability references that didn’t match the capability register, such as an ID paired with the wrong name. I corrected each one by hand.

For the diagrams, I used Claude Code with Figma to draw each workflow in FigJam, with key steps under each box. Details the AI wasn’t sure about were marked in red, so reviewers knew where to look first. I tried other drawing tools and PDF outputs before choosing FigJam, because the diagrams needed to stay editable after SME review.

I ran three pilot tests with SMEs before involving all 15.

Having several SMEs on each section helped avoid individual bias, and made it more likely that one of them would spot a missing workflow. Every concern, even the smallest, went into a separate tab in the sheet, so we could investigate it. The process was asynchronous, so SMEs could review in their own time.

The last step was a workshop, planned for after the asynchronous review. I would first synthesise the SME responses. Then the workshop would resolve any disagreements between SMEs, and agree what to do with the missing or partial workflows they found. This was a crucial step, because it would turn many individual reviews into one agreed answer.

I defined success as three things the catalogue should make possible.

When my contract ended, SME validation was underway, and the migration status was planned for the next phase. Before I left, I handed the work over to the researcher, with the team leader present. All the documentation was complete, so the next person could pick it up where I left off. The result is a draft baseline, not a signed-off catalogue.

The method is what I’d take to any new role. Agree the definitions, set clear rules, let AI do the volume, check every result, then ask experts for what documents can’t show. I can use the same method on any large system that isn’t well documented.

AI made the work faster, but it also made it easy to produce results that looked finished. The rules and checks were what made the output trustworthy, so I’d set them up first again.

The work became more complex than planned, and validation started a few weeks late. Next time, I’d use shorter checkpoints, so stakeholders always know what’s done, what’s uncertain and what’s next.