Role and scope
One designer across a connected product portfolio.
Railflow products are connected by shared operational concepts: requests, offers, capacity, assets, transport states, exceptions and commercial closure. My work was not limited to isolated screens. It involved listening across customer, product and development perspectives, then making the next decision visible in flows, states, components and documentation.
- Listening to customer feedback, requests and recurring operational problems
- Working with business analysts, product owners and project managers to clarify rules and priorities
- Mapping user journeys, task flows and information structures before moving into interface design
- Producing mockups, prototypes, high-fidelity UI and reusable design-system patterns
- Aligning designs with developers for handoff, implementation and feedback after delivery
- Moving parts of the design workflow toward AI-native production with structured automation and MCP-assisted workflows in the latest phase
Use cases
One platform,different operational realities.
The product system serves different roles in the rail and intermodal chain. Each role changes the information hierarchy, decisions and handovers the interface must support.
Intermodal operators
Managing loading-unit moves across rail and other modes, through the terminal and into the last mile.
Rail freight forwarders
Quoting, planning, steering and billing rail freight without stitching together disconnected tools.
Shippers
Getting automation and visibility on rail shipments without needing to become rail operations specialists.
Rail freight operators
Running the commercial rail business from offer through invoice inside one transport-management flow.
Intermodal forwarders
Selling, planning and executing rail, water and road moves from one operational cockpit.
Software
Products that connect order to cash.
These products describe the software side of the Railflow ecosystem. The summaries below use public product context; the design contribution is described from my stated role and remains subject to project-level evidence.
Railflow software platform
A connected system for planning, dispatching, tracking and invoicing rail and intermodal transports.
Design angleCreating a shared product language across commercial, planning, execution and invoicing workflows.
View public product contextTransport Management System
A transport management system connecting planning, execution, visibility and commercial closing across the transport lifecycle.
Design angleMaking before-transport planning, during-transport monitoring and after-transport closure legible as one operational chain.
View public product contextFleet Management
A platform for wagon master data, location, damage management, maintenance, availability and lease information.
Design angleTurning scattered fleet information and workshop communication into operational states that support daily decisions.
View public product contextTerminal Operating System
A system connecting gate, yard, train, maintenance and invoicing work for inland terminals and container depots.
Design angleDesigning time-critical handovers between terminal roles without splitting the operational picture across paper, spreadsheets and calls.
View public product contextOffer Management and CRM
A rail-specific workspace for opportunities, cost-aware offer calculation, customer context and handover into operations.
Design angleStructuring commercial decisions around block trains, single-wagon loads, intermodal services and asset rentals.
View public product contextMarketplace
Products that coordinatesupply, demand and capacity.
The marketplace side adds multi-sided workflows: requesters, providers, operators, forwarders, carriers, lessors and lessees must act on compatible information.
Railflow Marketplace
A connected marketplace for rail capacity, intermodal slots, rolling-stock assets and tender workflows.
Design angleDesigning for two-sided coordination where requesters, carriers, operators, forwarders and asset owners need compatible information.
View public product contextPurchase and Tender Management
A digital workflow for sourcing rail freight, comparing structured offers and keeping a clear compliance trail.
Design angleReducing ambiguity in a multi-party procurement flow by making requests, provider responses and comparison criteria inspectable.
View public product contextResource Sharing Broker
A workflow connecting rental requests, offers, orders, handover documentation and invoicing between lessors and lessees.
Design angleMaking asset sharing transparent across both sides of a transaction while preserving the contractual steps before handover.
View public product contextRail Capacity Broker
A matchmaking concept combining published rail capacity, transport demand and operational constraints into feasible options.
Design angleRepresenting a constraint-heavy matching problem without hiding the operational reasoning behind a simple search result.
View public product contextIntermodal Capacity Broker
A marketplace connecting forwarders, carriers and operators through request, comparison, booking and tracking flows.
Design angleMaking a complex intermodal purchase inspectable and actionable while keeping role responsibilities visible.
View public product contextWorking model
Listening, structuring, testing and handing over.
I worked between customer feedback and internal product direction. Customer requests, support conversations and operational friction informed the questions I brought back to business analysts, product owners and project managers.
From there, I mapped flows, clarified states and produced mockups and prototypes that could be discussed with the people who understood the domain and the developers who would implement the result.
The work continued through design-system alignment, specification, handoff and feedback after delivery. That made the design process part of the product system rather than a one-time visual exercise.
Latest phase
Extending the workflow toward AI-native delivery.
During the latest phase, I worked toward turning parts of the design and documentation flow into a more AI-native system. The aim was not to replace product judgment, but to reduce repetitive translation between requirements, design decisions, documentation and implementation.
That direction included structured automation and MCP-assisted workflows, connecting product context with the design and delivery tools used by the team. The portfolio should show the concrete workflow and artifacts once the relevant material is approved for publication.
Evidence boundary
What this overview does and does not claim.
This portfolio page describes product context and my stated role. Product-level dates, team composition, exact ownership, research samples, implementation status and measurable outcomes require project evidence before publication as individual claims.
The next step is to select the strongest Railflow product stories, attach approved visuals and document the specific decisions that can be discussed in an interview.