How do you redesign a national train schedule website used by millions—while enhancing the user journey?
Here’s my approach.
Overview
pkp-rozklad.pl is Poland’s official train schedule website, used by millions to plan rail journeys across the country. While functionally reliable, the site struggled with outdated design and poor usability on both desktop and mobile.
This redesign aims to modernize the interface, streamline the user experience, and enhance accessibility—without compromising the core features travelers depend on.
Team
Duration
Tools
Key Skills
Individual
150+ Hours
Figma, Chat GPT
UX Research, Qualitative Interviews, Visual Design, Wireframing, Prototyping, User Testing
But wait a second.
Do people still travel by train these days?
Yes they do!
The key problems
The core challenge was to modernize rozklad-pkp.pl and make it more user-friendly. While functionally reliable, the platform suffered from several key issues:
The desktop layout wasn’t adapted to large modern screens
Users weren’t informed when redirected to external ticketing sites
Useful features like delay tracking and arrival-time search were hard to find
The mobile experience felt cramped and inconsistent
The visual design was outdated
Although the core functionality was solid, the overall user experience needed a major upgrade.
Goals
At the start of this project, I defined three main goals:
01. Simplify navigation and search by resolving key usability issues
02. Modernize the layout and visual style for both large screens and mobile devices
03. Create a clear, consistent experience across platforms and during external redirects
However, as I conducted in-depth research and tested various features, I discovered that the site had more to offer — but many of these functions were poorly exposed or lacked proper explanation.
This led to the addition of a new goal.
04. Highlight valuable features
Solution
The redesigned pkp-rozklad.pl website features:
01. Clear information about redirection to carrier websites for ticket purchases
02. Easy connection search
03. The site now displays the minimum ticket price
RESEARCH
I can divide my research into three main stages:
Exploring the current PKP Rozkład website — both desktop and mobile versions
Competitor analysis
User interviews
EXPLORING THE CURRENT PKP ROZKŁAD WEBSITE
Design Flaws in the Existing Interface
The desktop version appears to have been designed with smaller or outdated screen resolutions in mind.
Lack of language consistency – despite setting the interface to English, a key stop like the airport is still shown in Polish. Also, the “Important Information” section appears in Polish.
Overwhelming number of ads – visual clutter negatively impacts the user experience.
Search issues – no suggestions appear while typing, there’s no clear indication of the main (central) station, and the label “WARSZAWA-” in mobile results is confusing and unclear.
Inconsistent stop naming – in a three-leg trip example, station names vary in format. Additionally, the “Buy ticket” button appears only for the full trip, not for individual segments.
Mobile UI issue – in the mobile version, the stations entered by the user are displayed in grey text, which gives the impression that the fields are empty or still require input.
The user is redirected to a different website without any prior warning or clear indication.
Searching for a train on the original rozklad-pkp.pl website
COMPETITOR ANALYSIS
The Insights
USER INTERVIEWS
Research Goals & Objectives
I want to understand the most frustrating or challenging moments in users’ journey so I can design solutions that directly address those pain points.
01. Identify Primary User Groups
02. Understand User Goals and Pain Points Across the Booking Journey
03. Understand user expectations for mobile train booking and the reasons behind mobile search behavior
Details:
6 interviewed
Age: 30-35
Different reasons and frequency for choosing trains as a means of transport
Key Takeaways from User Interviews
01 Clear Priorities
Users expect to see available seats early (70%+), value fast booking, transparent pricing, and a visual seat selector.
02 Booking Frustrations
They include discovering no seats too late, unclear train layouts, and search flow disruptions (like filter resets or missing swap direction buttons). Users also report technical issues such as crashes and failed payments.
03 Mobile Over Desktop
Most avoid downloading apps. Blik payments make mobile web the most convenient choice. (To use BLIK, a one-time code must be generated from their banking app, and the transaction needs to be confirmed on the phone—making mobile the most convenient option.)
04 Desired Extras
Wi-Fi, real-time delay info, multilingual UI, and consistent experience across devices matter to users.
05 User Segments
Interviews revealed 3 key types: Existing User, New to the City, and Travel Agent.
🚧 Obstacle for my project
Unfortunately, rozklad-pkp.pl redirects users to external carrier websites for ticket purchases, which means that seat selection is not available within the main booking flow. This option becomes accessible only after being redirected.
USER PERSONA
Who am I designing for?
Based on insights gathered during interviews, I was able to identify three distinct user groups: Existing User, New User to the City, and Travel Agent. In my project, I focused on the first two groups, as Travel Agents have different needs and, as professionals, typically do not use mobile devices to search for train schedules for their clients.
How might we enhance the mobile experience to enable users to quickly and easily find clear, comprehensive train schedule information supporting a seamless transition from planning to travel?
The current rozklad-pkp.pl platform presents usability challenges, particularly on mobile devices, resulting in user frustration when attempting to efficiently access train schedule information.
FEATURE SET
Features Overview
The selection of features was limited by the capabilities of the system in which PKP operates; that is, the inability to purchase tickets directly on the PKP main website, which redirects users to the carriers’ sites to complete the purchase.
IDEATION
USER FLOW
How would the users navigate through main workflow?
DESIGN
LOW FIDELITY WIREFRAMES
Defining the layout during early-stage exploration
-
Most voted for ver 1
Feedback: Version 1 offers a much clearer visual hierarchy.
-
Most voted for ver 2
Feedback: It’s more readable and has a layout similar to a flight booking page.
-
Most voted for ver 1
Feedback: Everything is visible right away, but where is the delay information?
#1 USER TESTING
Usability Test: Key Findings
Goals
- Detect points of confusion or hesitation in the journey.
- Check if users can easily find the most important information.
““Trip Details” and “CO2” don’t clearly communicate what info is inside.”
Tasks
- Find a train from “Warszawa Centralna” to “Gdansk Centralny” at 3.00PM
- Check the details of the train.
- Proceed as if you were going to buy this ticket.
Discoveries
Details
The same group that took part in the user interviews.
“ There’s no information about price.”
💡
Hold on!
And what about responsiveness?
Since this was my first experience with responsive design, I initially focused solely on low-fidelity wireframes for the mobile version, as interview feedback indicated that users accessed the mobile website much more frequently to search for trains. After consulting with my mentor, I recognized the importance of also incorporating desktop responsiveness into the project.
Since I was lacking low-fidelity wireframes for desktop screens, I developed both mobile and desktop wireframes for hi-fidelity stage and ensured the screens are responsive.
UI KIT
Redesign: UI Components & PKP Brand Adaptation
In this project, I developed a comprehensive design system tailored to the PKP brand identity. While maintaining the original PKP logo to preserve brand recognition, I adapted the color palette to reflect the company’s official colors more effectively. Additionally, I redesigned key UI components such as buttons, forms, and navigation elements to improve usability.
HIGH FIDELITY WIREFRAMES
Evolving the Design: From Wireframes to Visual Identity
In the initial versions of the high-fidelity designs, I aimed to stay as close as possible to the original visual style of the PKP website. This approach helped ensure visual continuity and user familiarity, especially for returning users accustomed to PKP’s current interface.
💡Idea
I decided to introduce pricing in the form of "from" because it was one of the key factors influencing user decisions, as revealed during interviews. Users emphasized that having an upfront price—even if approximate—helped them quickly evaluate the attractiveness of a connection.
When users begin entering the details of their chosen route, they can specify the number of passengers, including adults, children, and students (the latter being eligible for discounts). This selection directly affects the displayed price. However, since the final ticket purchase is completed on the carrier’s website—where prices may still vary—the pricing is intentionally labeled as "from" to set accurate expectations.
#2 USABILITY TEST
High-Fidelity Wireframes in Action: Testing
Overview:
Ensure users can easily understand searching for a train connection, using filters and checking for delays.
For the purposes of the project and due to limited time, I only tested the mobile version.
“It looks like Booking.com”
“There is all important information. It’s not confusing.”
Key Iterations
Mobile Website
OUTCOME
One of the participants mentioned:
“I always use the ‘arrival by’ option because it makes it easier for me to search for connections when I need to be somewhere at a specific time.”
My initial wireframes lacked the ability to search by departure or arrival time — a feature that turned out to be important for many users.
💡On the original website, this option is quite unclear. Several users (including myself) didn’t know how to use it properly. That’s why I decided to make it more visible, intuitive, and readable.
I designed three different versions of how to present this feature. Version 3 was the most successful. As one developer pointed out:
“People get confused when there are two fields to fill in, but they should only use one (in this case, either departure or arrival time).”
OUTCOME
One user pointed out that trains from Katowice Główny only go to Kraków Główny. From a UX/UI perspective, showing in suggestions only the main station simplifies the experience, reduces errors, aligns with real travel patterns, and keeps the UI clean and mobile-friendly.
I increased the font weight and size in the filled input fields to improve readability.
I moved away from the original layout of the PKP website.The “Travel with your pets” promotion and footer sections are now visually separated and balanced that creates a more scannable layout with less visual clutter. The lighter background and structured containers help users focus on individual elements more easily.
A yellow "Important Information" banner has been introduced below the search section since it’s present on the original PKP site and is essential for conveying important information to passengers.
OUTCOME
The biggest issue users faced was sorting results by price. By default, results are sorted by direct connections, which caused confusion. To make it clearer where users should click, I added a sorting icon next to the price column.
I removed the date scroll bar from the search results page (since it’s less relevant for train travel) and replaced it with “Earlier trains” and “Later trains” buttons. This change reflects how only a limited number of connections are shown at once, and users told me they like to browse earlier or later options — even after selecting a specific time.
I also improved the layout because in the previous version, it was visible that with a longer station name (Kawice Główny), the name would break and shift.
OUTCOME
I removed the Edit button from the train details screen — none of the users noticed or interacted with it during testing, as they simply went back to the results page to make changes.
Final Design
TAKEAWAYS
Reflections
This project was like a box of chocolates – every time I discovered something new. Sometimes it was interesting, and other times it required me to dedicate more time to properly 'chew' and 'digest' it. I learned a lot while preparing this project, primarily that good initial research is fundamental.
Also, designing responsive wireframes for both desktop and mobile so that everything was cohesive, aesthetic, and at the same time user-friendly, while also considering the specifics of the industry and remembering that I was only redesigning an existing website, not building it from scratch according to my own preferences.
Trade-offs I had to make
Functionality vs. Simplicity/Time: Initially, I wanted to add many new features, but I had to forgo some to maintain interface simplicity and meet the set timeframe.
Ideal Solution vs. Existing System Limitations: I had to adapt the design to local specifics and the capabilities of the existing website, instead of implementing ideal but unfeasible solutions.
All User Groups vs. Priority Groups: I decided to focus on "Existing User" and "New User to the City," so I did not delve deeply into addressing the needs of "Travel Agents."
What I liked about this project
I appreciated that this project allowed me to visit various travel websites as part of my research. I searched for exotic train connections and observed how different railway websites reflected the specific travel characteristics of various countries. I noticed that certain solutions, despite appealing to me on the original sites, on the original sites couldn’t be directly adapted to the Polish context, and the design had to adapt accordingly. (An example of this is the way hours or dates are recorded in English-speaking countries, or the abbreviations for cities where stations are located in the USA—in Poland, we don't use such abbreviations, which directly impacts the design of longer input fields.).
If I can do it again
Definitely, if I'm tasked with designing for both desktop and mobile,.I will approach both desktop and mobile more simultaneously in the future. In this project, I primarily focused on mobile because that's what the project mainly required of me, somewhat neglecting desktop. I later realized thatthis approach turned out to be less efficient.