Hankyu Railway Designing from Zero for Japanese Rail

A 0→1 staff-facing product across 88 stations, built for 700k daily commuters where precision is non-negotiable

OVERVIEW

Company

Transreport, UK

Partner

Hankyu Railway, Japan

My Role

Lead Product Designer (sole designer through MVP, then led 1 product designer in a team of 2 POs and 5+ engineers)

Scope

0→1 MVP · Concept · Research · End-to-end Design

Product

iOS and Android App

Duration

2022 June- 2024 April

OVERVIEW

Hankyu Railway operates one of Japan's busiest private rail networks, serving over 700,000 passengers daily across the Osaka-Kobe-Kyoto region. Despite its scale, passenger assistance at stations was managed entirely through paper-based processes — fragile, inconsistent, and error-prone.

Transreport was brought in to digitalise this process, re-creating its existing Passenger Assist platform for the Japanese rail market. As the lead product designer, I was responsible for the end-to-end mobile design — from product proposal, initial research and stakeholder engagement through to the design system, MVP delivery, and post-launch iteration.

This was not a straightforward localisation project. It required navigating cultural differences in working practice, building trust with stakeholders who were sceptical of change, and making considered decisions about what the product needed to be on day one.

Hankyu Railway operates one of Japan's busiest private rail networks, serving over 700,000 passengers daily across the Osaka-Kobe-Kyoto region. Despite its scale, passenger assistance at stations was managed entirely through paper-based processes — fragile, inconsistent, and error-prone.

Transreport was brought in to digitalise this process, re-creating its existing Passenger Assist platform for the Japanese rail market. As the lead product designer, I was responsible for the end-to-end mobile design — from product proposal, initial research and stakeholder engagement through to the design system, MVP delivery, and post-launch iteration.

This was not a straightforward localisation project. It required navigating cultural differences in working practice, building trust with stakeholders who were sceptical of change, and making considered decisions about what the product needed to be on day one.

88 stations live

100% adoption

70% faster request creation

12.5 hrs saved per staff per month

10-year partnership secured

0% missed assistance

CHALLENGES

CHALLENGES

Across 88 stations, Hankyu's staff coordinated over 1,000 passenger assistance requests every week — entirely on paper. Each request meant a physical record, tracked with timers and confirmed by phone calls between platforms. And every station had its own way of working.

When the system worked, it was invisible. When it didn't, a wheelchair user could be left waiting on a platform with no one coming. A visually impaired passenger could miss a connection because a handoff never reached the right staff member. Operators had no real-time way to see whether help was on its way.

For passengers the experience depended entirely on individual staff memory and information being relayed correctly — not on a system designed to support them.

For staff the assistance provider, cognitive load was constant in a time-sensitive environment: tracking multiple timers, capturing verbal handoffs, and reconciling duplicated paperwork.

For Hankyu the operator, paper meant no operational visibility — no way to learn from incidents, plan resourcing, or improve service at scale.

The challenge was to replace a deeply embedded paper system with a digital one staff would trust on day one — across cultural, operational, and generational contexts with no direct UK precedent to draw from.

Across 88 stations, Hankyu's staff coordinated over 1,000 passenger assistance requests every week — entirely on paper. Each request meant a physical record, tracked with timers and confirmed by phone calls between platforms. And every station had its own way of working.

When the system worked, it was invisible. When it didn't, a wheelchair user could be left waiting on a platform with no one coming. A visually impaired passenger could miss a connection because a handoff never reached the right staff member. Operators had no real-time way to see whether help was on its way.

For passengers the experience depended entirely on individual staff memory and information being relayed correctly — not on a system designed to support them.

For staff the assistance provider, cognitive load was constant in a time-sensitive environment: tracking multiple timers, capturing verbal handoffs, and reconciling duplicated paperwork.

For Hankyu the operator, paper meant no operational visibility — no way to learn from incidents, plan resourcing, or improve service at scale.

The challenge was to replace a deeply embedded paper system with a digital one staff would trust on day one — across cultural, operational, and generational contexts with no direct UK precedent to draw from.

CHALLENGES

CHALLENGES

Across 88 stations, Hankyu's staff coordinated over 1,000 passenger assistance requests every week — entirely on paper. Each request meant a physical record, tracked with timers and confirmed by phone calls between platforms. And every station had its own way of working.

When the system worked, it was invisible. When it didn't, a wheelchair user could be left waiting on a platform with no one coming. A visually impaired passenger could miss a connection because a handoff never reached the right staff member. Operators had no real-time way to see whether help was on its way.

For passengers the experience depended entirely on individual staff memory and information being relayed correctly — not on a system designed to support them.

For staff the assistance provider, cognitive load was constant in a time-sensitive environment: tracking multiple timers, capturing verbal handoffs, and reconciling duplicated paperwork.

For Hankyu the operator, paper meant no operational visibility — no way to learn from incidents, plan resourcing, or improve service at scale.

The challenge was to replace a deeply embedded paper system with a digital one staff would trust on day one — across cultural, operational, and generational contexts with no direct UK precedent to draw from.

MY ROLE AND DESIGN LEADERSHIP

Leading through scepticism

As the lead product designer, I joined a project where not everyone was convinced that digitalisation was the right path. One operations lead was openly sceptical — preferring to preserve the existing paper-based process rather than introduce an unfamiliar system to frontline staff. Rather than debating the merits of digital tools, I focused on making the research process visible and inclusive. By involving their team directly in workshops and reflecting their operational knowledge visibly in early concepts, the conversation shifted. They moved from resistance to advocacy.

Shaping the right scope in ambiguity

The scope was loosely defined from the start — the problem was understood, but the right solution was not. I facilitated a product-design workshop with product owners and senior management to define the most valuable MVP scope. Through structured discussion and design-led framing, we reprioritised the feature set and established clearer boundaries — ensuring the product could launch with confidence rather than stall under its own complexity.

What I Led

  • Defined MVP scope under ambiguity

  • Planned and led field research in Japan

  • Aligned stakeholders through research-driven workshops

  • Synthesised insights into design principles and product strategy

  • Shaped the MVP scope in collaboration with product and engineering

  • Established design system for scalability

Leading through scepticism

As the lead product designer, I joined a project where not everyone was convinced that digitalisation was the right path. One operations lead was openly sceptical — preferring to preserve the existing paper-based process rather than introduce an unfamiliar system to frontline staff. Rather than debating the merits of digital tools, I focused on making the research process visible and inclusive. By involving their team directly in workshops and reflecting their operational knowledge visibly in early concepts, the conversation shifted. They moved from resistance to advocacy.

Shaping the right scope in ambiguity

The scope was loosely defined from the start — the problem was understood, but the right solution was not. I facilitated a product-design workshop with product owners and senior management to define the most valuable MVP scope. Through structured discussion and design-led framing, we reprioritised the feature set and established clearer boundaries — ensuring the product could launch with confidence rather than stall under its own complexity.

What I Led

  • Defined MVP scope under ambiguity

  • Planned and led field research in Japan

  • Aligned stakeholders through research-driven workshops

  • Synthesised insights into design principles and product strategy

  • Shaped the MVP scope in collaboration with product and engineering

  • Established design system for scalability

MY ROLE AND DESIGN LEADERSHIP

RESEARCH AND DISCOVERY

Rather than beginning with the UK product and adapting it, I led the team to start it from a blank canvas — treating this as original research into an unfamiliar context, without assumptions.

Field visits to Hankyu stations
I led the team on station visits and asked: how the current process worked, who communicated with whom, what triggered a handoff, what's individual responsibility, and where friction occurred.

Rather than beginning with the UK product and adapting it, I led the team to start it from a blank canvas — treating this as original research into an unfamiliar context, without assumptions.

Field visits to Hankyu stations
I led the team on station visits and asked: how the current process worked, who communicated with whom, what triggered a handoff, what's individual responsibility, and where friction occurred.

Contextual interviews with station staff
I made a research plan and interviewed gate staff, station managers, and operations leads to understand the work from each role's perspective — the pressures, the workarounds, and the moments where the current system broke down.

Workshop facilitation
I led five ideation workshops with 50+ Hankyu staff members, working alongside a translator to validate research findings and test early assumptions about what a digital tool could realistically support

Stakeholder Landscape

This project involved a wide range of stakeholders — the client project team, operational managers, contact centre staff, gate staff, and labour union members — each with different priorities and concerns. I designed and facilitated workshops that created a safe space for these groups to align, surface tensions early, and build collective ownership of the direction.

Insight

We'd assumed hierarchical workplace norms meant designing for top-down task assignment. The workshops showed the opposite — gate staff routinely self-assigned during peak periods, and removing that flexibility broke the workflow. We designed for both modes from day one, treating flexibility as a core requirement rather than an edge case.

Quote from staff

"I was worried about a foreign company designing our product because we've never worked this way before — but I have faith in the product now."

RESEARCH AND DISCOVERY

SHARED UNDERSTANDING THROUGH ARTEFACTS

I created shared artefacts (personas, journey maps, operational diagrams) to align Transreport and Hankyu teams and make complex workflows visible., building a common visual language that bridged operational differences.

Two distinct user roles emerged from the research, each with different goals, pressures, and definitions of success. Rather than optimising for one and accommodating the other, a decision that shaped the information architecture and permission model.

Station Manager — needed oversight : tracking service quality, monitoring resourcing, and intervening when things went wrong.

Gate Staff — needed execution: delivering assistance, communicating with passengers, and moving through requests under time pressure.

What united them was a high-pressure, multitasking environment where minimising errors and working efficiently were non-negotiable. The personas and journeys I built captured this shared context, but the design decisions flowed from the different user flows.

Furthermore, I created clear diagrams for edge cases to make the complexity visible and give the team a shared reference point for design decisions, helps us cover the high-risk scenarios and reduce the chance of failed assistance.

SHARED UNDERSTANDING THROUGH ARTEFACTS

IDEATION AND ITERATION

Continuous co-creation with users and internal team

I planned and facilitated multiple rounds of ideation workshops with station staff and the internal team, exploring which product workflows mattered most to the target user.

Continuous co-creation with users and internal team

I planned and facilitated multiple rounds of ideation workshops with station staff and the internal team, exploring which product workflows mattered most to the target user.

From client–vendor to genuine partnership

Rather than one side leading and the other adapting, the process became genuinely collaborative. The Transreport team brought product and accessibility expertise; the Hankyu team brought deep operational knowledge and an uncompromising standard for passenger experience. The strongest design decisions came from the intersection of both — not from compromise between them.

I worked through multiple rounds of wireframes and prototypes, using the UK product as a reference point rather than a template.

The most important design decision wasn't what to build — it was what to leave out.
The UK product had mature functionality built up over years of iteration, but introducing that complexity on day one would have overwhelmed staff already adapting to a new way of working. Our users included older staff less familiar with digital tools, and forcing in features that didn't map to Japan's current process risked creating something inflexible from the start. I made the case to descope that functionality from the MVP — a simpler, focused system would drive faster onboarding and generate the real-world feedback needed to improve meaningfully.

I worked through multiple rounds of wireframes and prototypes, using the UK product as a reference point rather than a template.

The most important design decision wasn't what to build — it was what to leave out.

The UK product had mature functionality built up over years of iteration, but introducing that complexity on day one would have overwhelmed staff already adapting to a new way of working. Our users included older staff less familiar with digital tools, and forcing in features that didn't map to Japan's current process risked creating something inflexible from the start. I made the case to descope that functionality from the MVP — a simpler, focused system would drive faster onboarding and generate the real-world feedback needed to improve meaningfully.

Before launching the MVP, I led a series of validation sessions with our Japan-based colleagues — surveys, interviews, and usability testing on the core flows.


The primary features were usable, but several friction points were costing staff time. The biggest was the assistance request creation flow: too many optional fields and no clear sense of priority.

We made four changes — removed optional fields, broke the flow into one page per action, anchored key interactions at the bottom of the screen for comfortable one-handed use, and introduced pre-defined options to speed up data entry. Request creation time dropped from 60 seconds to 30. A 50% reduction across the most-used flow in the product.

Iteration on the findings

Behaviour at the plaform
At the platform, staff don't read — they scan. The most important design decisions were about what information appeared first, and how quickly a staff member could move from seeing a request to acting on it. Because trains can be just five minutes apart and the same actions repeat dozens of times a shift, we designed for muscle memory: consistent placement of primary actions, predictable interaction patterns, and steps simple enough to perform without conscious thought.

Behaviour at the plaform
At the platform, staff don't read — they scan. The most important design decisions were about what information appeared first, and how quickly a staff member could move from seeing a request to acting on it. Because trains can be just five minutes apart and the same actions repeat dozens of times a shift, we designed for muscle memory: consistent placement of primary actions, predictable interaction patterns, and steps simple enough to perform without conscious thought.

IDEATION AND ITERATION

THE SOLUTION

End-to-End Workflow

The operational flow was complex — multiple staff members coordinating across departure and arrival points, with different paths depending on whether the passenger booked ahead or turned up on the day. I simplified it to a single high-level core flow that the team could understand at a glance, keeping secondary flows (assignment, decline-request, and other edge cases) in separate diagrams so they didn't dilute the main view.

Home page for the staff app

Assistance Request Creation

Staff create a passenger assistance request in 30 seconds — half the time of the original flow — at the moment a passenger arrives to catch the next train. Common fields are pre-filled, and the remaining details are captured in a structure the receiving staff member can act on without a verbal handoff.

Home page for the staff app

Passenger Assistance Management

Every assistance request is logged and tracked in one place, in real time. Managers see all active requests across the station; gate staff see only the ones assigned to them. Gesture controls — swipe to update status — let staff act on requests without opening a full screen.

Home page for the staff app

Auto Alarm System

Previously, gate staff set individual kitchen timers by hand for every request, calculating each alarm time from train arrival schedules. The system now generates the alarms automatically — one per request, timed to surface exactly when the staff member needs to act.

Home page for the staff app
Home page for the staff app

Notification Flow

Building on the auto alarm system, I designed a notification flow that determined when staff received alarms versus push notifications — making sure the right message reached them at the right time. In collaboration with the client, we also designed distinct ringtones for urgent and non-urgent alerts.

THE SOLUTION

RESULTS

As a 0→1 project, the results spoke for themselves. We collected data six months after launch through station visits and user testing sessions. Beyond the metrics, the project established Transreport's first foothold in the Japanese market — demonstrating that accessible transport design can cross cultural and regulatory borders when rooted in genuine research, co-creation and iteration.

10 years

Partnership contract secured

Partnership contract secured

88

Stations live

Stations live

70%

Faster request creation

Faster request creation

100%

Station adoption rate

Station adoption rate

12.5 hrs

Saved per staff member per month

Saved per staff member per month

1000+

Assistance requests weekly

Assistance requests weekly

12.5 hrs

Saved per staff member per month

1000+

Assistance requests weekly

RESULTS

DESIGN OPS AND CROSS FUNCTIONAL LEADERSHIP

Pre-MVP, I was responsible for building the mobile design system from scratch. As the project grew, I took on Design Ops responsibilities to support the expanding team — establishing the design system's version control and contribution roadmap, streamlining how design work moved through the cross-functional pipeline with engineering and product, and mentoring a junior designer joining the team.

The shift was from doing the design work to making sure the design work could scale — building the systems, processes, and people, alongside other design peers, that would let the product keep evolving after launch.

DESIGN OPS AND CROSS FUNCTIONAL LEADERSHIP

DESIGN OPS AND CROSS FUNCTIONAL LEADERSHIP

Pre-MVP, I was responsible for building the mobile design system from scratch. As the project grew, I took on Design Ops responsibilities to support the expanding team — establishing the design system's version control and contribution roadmap, streamlining how design work moved through the cross-functional pipeline with engineering and product, and mentoring a junior designer joining the team.

The shift was from doing the design work to making sure the design work could scale — building the systems, processes, and people, alongside other design peers, that would let the product keep evolving after launch.

DESIGN OPS AND CROSS FUNCTIONAL LEADERSHIP

REFLECTIONS
  • The workshops demonstrated how user-centred evidence could align business goals across two organisations — but the deeper shift came when Hankyu staff felt genuinely heard. That trust became the foundation for both the design work and the business relationship, and shaped every decision that followed.

  • Cross-cultural design isn't just translation. Starting from research rather than from the existing UK product revealed both fundamental differences and unexpected common ground.

  • Scoping is a design skill. Deciding what not to build in the MVP required as much design thinking as any interface decision. Getting that boundary right meant the product could actually launch — and become the foundation for future iterations — rather than stalling under its own complexity.

REFLECTIONS

REFLECTIONS
  • The workshops demonstrated how user-centred evidence could align business goals across two organisations — but the deeper shift came when Hankyu staff felt genuinely heard. That trust became the foundation for both the design work and the business relationship, and shaped every decision that followed.

  • Cross-cultural design isn't just translation. Starting from research rather than from the existing UK product revealed both fundamental differences and unexpected common ground.

  • Scoping is a design skill. Deciding what not to build in the MVP required as much design thinking as any interface decision. Getting that boundary right meant the product could actually launch — and become the foundation for future iterations — rather than stalling under its own complexity.

REFLECTIONS

NEXT STEP

With the MVP live across 88 stations and the partnership secured, the roadmap is focused on three strands: expanding accessibility features for passengers, deepening integration with Hankyu's operational flow, and building toward a scalable model for the seven other Japanese rail operators in the market.

Since I left the project, the product has continued to gain traction, with multiple potential clients already in conversation.

With the MVP live all stations and the partnership secured, the roadmap is focused on expanding accessibility features for passengers, deepening integration with Hankyu's operational flow, and building toward a scalable model for other Japanese rail operators.

Even after I left the project, the product has continued to gain traction — with multiple potential clients already in conversation.

NEXT STEP

NEXT STEP

With the MVP live across 88 stations and the partnership secured, the roadmap is focused on three strands: expanding accessibility features for passengers, deepening integration with Hankyu's operational flow, and building toward a scalable model for the seven other Japanese rail operators in the market.

Since I left the project, the product has continued to gain traction, with multiple potential clients already in conversation.

NEXT STEP