Overview
Multi-stakeholder platform. One AI system. Zero margin for error.
MTR's operational communications involve five distinct user types —Traffic Controllers, Train Captains, Station Controllers, Chief Controllers, and Business stakeholders —each with fundamentally different workflows, information needs, and cognitive loads. They all operate on the same voice communication channel, but none of them experience the system the same way.
ASTRI contracted me to embed AI into that ecosystem: an Auto-Speech-Recognition platform that transcribes live communications, flags content mismatches before they escalate, and generates structured incident reports. I was the only designer on the engagement —responsible for scope definition, research, IA, and end-to-end delivery of two products.
The core design challenge: how do you build a platform that serves multiple distinct user types simultaneously, without creating a fragmented product that serves none of them well?
01 —Stakeholder Mapping
Before designing, map who the platform connects —and who decides.
The stakeholder landscape was structurally complex: MTR Operations users had direct product requirements; MTR Business had compliance and reporting requirements; ASTRI had technical integration requirements. I mapped all three independently before the first workshop, then identified where they conflicted.
The critical insight: Traffic Controllers were the highest-leverage user —the communication pivot connecting all other stakeholder types. Designing primarily for TCs would produce the most value across the entire network. That single framing shaped every downstream product decision.
36 multi-stakeholder interviews —mapping workflows and pain points across all user types in the MTR operations team
Staff relied on memory or incomplete logs —critical details were frequently missed at handover points between stakeholder types.
Miscommunication between roles created downstream errors —the problem wasn't individual users, it was the connection layer between them.
Post-incident reviews were fragmented because no single system captured the full cross-stakeholder communication record.
Three key personas —Traffic Controller, Train Captain, and Station Controller —each with distinct workflows and information needs
02 —Product Architecture
Three IA directions. One right answer —chosen by users, not gut.
I developed three distinct information architecture proposals —Timeline-Oriented, Line-Oriented, and Noticeboard-Oriented —each foregrounding a different mental model for how TCs manage multi-stream information. All three were real product directions, not straw men. I presented them to user groups before making a recommendation.
Problem framing (left) and IA direction exploration (right) —three genuine product directions tested with real users
Line-Oriented won —its messaging-channel structure matched the mental model TCs already used with WhatsApp, reducing learning time and cognitive load under pressure. This was a product recommendation backed by user data, not just a UX preference.
Three IA directions explored
- Timeline-Oriented —chronological event tracking; supports sequence understanding and response-time analysis
- Line-Oriented —organises by train line/route segment; familiar messaging-channel mental model; selected by users
- Noticeboard-Oriented —central dashboard summarising incidents by status; minimises information overload
Three IA directions —Timeline (left), Line-Oriented (centre, selected), Noticeboard (right). Tested with real users before any recommendation was made.
Low-fidelity wireframes —tested before committing to high-fidelity UI
03 —AI Integration & Two-Product Scope
Scoped and shipped two products from a single brief.
The original brief was scoped around the ASR communication platform. During research, I identified that post-incident investigation was equally painful —fragmented records, manual report writing, no cross-stakeholder search capability. I proposed a second deliverable: an Incident Report Generation System.
Both products were designed within the same engagement, sharing a single design system and component library. I used AI-assisted workflow tools throughout: AI-supported research synthesis to process 36 interview transcripts, rapid wireframe generation for initial IA exploration, and automated component documentation to accelerate handoff.
Two delivered products —real-time ASR communication platform (left) and Incident Report System (right)
04 —Design & Test
8 iterations. 42 usability tests. No idea survived first contact unchanged.
I moved into iterative prototyping —taking wireframes back to users at each stage before progressing to high-fidelity UI. 42 usability tests across 8 iterations refined information hierarchy, alert colour-coding, and the cross-stakeholder communication visualisation.
The final UI balanced MTR's brand and accessibility requirements against the urgency of critical alerts —using colour, iconography, and visual hierarchy to distinguish routine updates from safety-critical mismatches, without adding cognitive load in already high-pressure multi-tasking environments.
Design workshop —presenting wireframe directions to Traffic Controllers and Station Staff for structured feedback before iteration
Final ASR communication platform UI —8 iterations, 42 usability tests. Click to enlarge.
Impact
A platform that connects five user types around a single source of truth.
Outcomes
- Two enterprise products delivered solo —communication platform and incident report system
- Multi-stakeholder IA designed to serve five distinct user roles from one system
- Proactive mismatch flagging reduces preventable communication errors before they escalate
- Line-Oriented design adopted —familiar mental model minimised training overhead
- Searchable, timestamped archive enables cross-stakeholder compliance and continuous improvement
- Design system documented for ongoing product development by MTR/ASTRI teams
Incident Report Generation System (Investigator) —the second deliverable, scoped and designed within the same engagement
"The design problem wasn't how to visualise voice data —it was how to connect five different user types around a single shared workflow, without creating a platform that felt like five different products bolted together."
Key design principle from the project