BlogComparisonbooking transit
The national railway: Deutsche Bahn vs IRCTC
Two railways a whole country depends on, measured on the same ten minutes. Deutsche Bahn gets a traveller from the home page to a priced connection in four interactions and tells them what is late; IRCTC asks for two dismissals before the form, six gestures to search, and a login before a fare. On the booking task DB wins clearly. On giving information to people without an account, IRCTC does one thing DB does not. Both fail the keyboard.
- Date
- Reading time
- 9 min
- Status
- Draft
Why this matchup
The task is universal and the audience already has opinions. A national railway's booking site is the interface a country cannot opt out of, which makes it the fairest place to compare design decisions: the same job, under the same pressure, for very different populations. Deutsche Bahn carries about two billion passengers a year on a network that is famously late. IRCTC sells tickets for Indian Railways, which moves more people in a day than most countries do in a year, on devices and connections that are often constrained.
Both were run through the same script: land, clear whatever blocks the form, search a fixed route, read the results, proceed as far as possible without paying or logging in, look for live disruption information, then sample fonts, buttons, images and focus behaviour. Where a step could not be completed live, it is marked below rather than guessed.
The criteria, side by side
| Criterion | Deutsche Bahn | IRCTC |
|---|---|---|
| Consent and entry | No consent dialog on the international portal; form above the fold. 0 dismissals. | Bilingual language modal, then an "Explore beta" banner, on every cold load. 2 dismissals. |
| Search form | 5 controls; one-way, 2nd class, one adult 27 to 64 pre-set. 4 interactions to results. | 7 visible controls (3 required); date pre-filled with today. 6 gestures to results. |
| Autocomplete | "Munich" resolves to "Munich Central (München Hbf)"; hotels and airports mixed into the station list. A typo ("Municch") returns silence: no suggestion, no message. | Accepts codes ("NDLS") and names. "Mumbai" returns "MUMBAI CENTRAL - MMCT" and "MUMBAI CENTRAL - BCT" as consecutive entries with identical display names, distinguishable only by code. |
| Results clarity | Table of departure, arrival, duration, changes, train type, price. Direct connections labelled. Week-wide best-price scan available. | Not verified live in this audit (see below). |
| Price transparency | Prices shown as "ab 94,99 €": a minimum, with the real fare one click deeper per connection. Fare families (Supersparpreis, Sparpreis, Flexpreis) explained only inside the funnel. | No fare before a class is chosen, and no class can be chosen before login. |
| Funnel and upsells | Results, ticket type, seat reservation, passenger details: 3 screens to the last pre-payment step. Seat reservation offered, not pre-selected. BahnBonus and Deutschland-Ticket cross-sells; insurance at payment. | Login wall at the first class click, before any fare or terms. Travel insurance reported as pre-ticked in the post-login flow; wording not verified this session. |
| Real-time and disruption | Integrated into the planner: cancelled legs struck through, "Aktuelle Alternative" connections offered automatically, minute-level delay forecasts. A separate live map lives on another subdomain with a different look. | PNR status and seat charts open without an account. No disruption board on the home page; live running status needs a train number via a secondary link. |
| Mobile | Not captured in this audit. | Not captured in this audit. |
| Accessibility sample | 0 of 21 buttons unnamed. 14 of 16 images without alt text. A stylesheet sets outline: none on :focus. Skip links present. |
Script could not run. Structural: inputs without ids, six dialog instances in the DOM at once, no skip link found, "Copyright © 2026" in the footer (a double-encoding bug). |
| One design system? | Yes on the main domain: DBScreenSans, 16px body, DB red (#EC0016) reserved for the Search button, one card grid. The live-traffic map breaks the family. | No: PrimeNG defaults, an IRCTC-branded search block and a tourism carousel coexist as three visual registers; a footer of 20+ link groups with no hierarchy. |
Readout: Deutsche Bahn
Strengths
- Defaults that match the modal traveller. One-way, second class, one adult, no card. Most searches need no adjustment. Principle: progressive disclosure; the first view carries only what most people need.
- An autocomplete that bridges languages. English input resolves to German station names without the user knowing them. Principle: forgiving input prevents errors before they happen.
- Disruption data where the decision is made. Alternatives appear inside the journey list, not on a status page the user has to know about. Principle: show the state of the world at the point of choice.
- Every button has a name. 21 of 21. On a site this size that is rarer than it should be. Principle: accessible names are the baseline, not the polish.
- One typographic system. A brand font at a readable body size, one accent colour used for one purpose. Principle: restraint in colour makes the one action obvious.
Weaknesses
- Prices that are not prices. "ab 94,99 €" is a floor. Comparing three connections means three extra clicks, and nothing on the page explains the "ab". Principle: a price list should let a person decide without opening each row.
- Silence on a typo. "Municch" produces an empty dropdown and no message. Principle: error recovery means telling the user what went wrong.
- Images without alt text. 14 of 16 on the home page. Principle: WCAG 2.1 1.1.1 is a Level A requirement.
- Focus outlines removed in CSS.
outline: noneon:focusin at least one stylesheet. Principle: WCAG 2.1 2.4.7; a keyboard user has to see where they are. - Two visual systems for one service. The live-traffic map on verkehrslage.bahnhof.de has its own header and palette and is not linked from the search widget. Principle: a product's state should be reachable without leaving the product.
Readout: IRCTC
Strengths
- Information without an account. PNR status and seat charts work for anyone, which serves the people meeting a train as well as the people on it. Principle: do not gate information that is not transactional.
- Codes and names both work. "NDLS" is enough for a user who knows it. Principle: serve expert input without penalising novices.
- Concessions at the search stage. Disability and railway-pass quotas are visible on the form, not buried after login. Principle: eligibility should shape the search, not surprise the checkout.
- Searching does not require registration. The login wall comes at booking, not at the door. Principle: let people look before they commit.
- Hindi and English at the first touch. The language choice is the very first interaction, which fits the population. Principle: localisation is a first-screen decision.
Weaknesses
- Two forced dismissals on every cold load. The language modal does not remember its answer; the beta banner follows it. Principle: an interruption that repeats is a tax, not a welcome.
- Two stations with one name. MMCT and BCT both render as "MUMBAI CENTRAL". The only difference is the code, which is exactly what a first-time user does not know. Principle: a label must be distinguishable without external knowledge.
- Login before any fare. The first click on a class asks for credentials; no price, no terms, no insurance wording have been shown. Principle: ask for identity after informed intent, not before.
- A character-encoding bug on every page. "Copyright © 2026" is UTF-8 read as Windows-1252. Small, visible, and a signal about the rendering pipeline. Principle: production quality is judged on what is visible.
- Three visual registers on one page. Component-library defaults, a branded search block and a tourism carousel, plus a footer with no hierarchy. Principle: one system, or the user pays the integration cost.
What this audit could not verify
Honesty about method is part of the format. In this session the two railway audits ran in parallel and the browser sessions collided, so for IRCTC the results page, the per-class availability clicks, the pre-ticked insurance wording and the accessibility counts were not executed live and are reported from page structure and prior documentation only. For both sites the mobile pass was not captured. A second, sequential pass on those steps is queued before this comparison is published; the verdict rests only on what was observed first-hand.
Verdict
On the task both sites exist for, Deutsche Bahn wins, and not narrowly: four interactions to a priced list against six gestures and two dismissals to reach a list that then asks for a login; disruption information inside the journey rather than behind a train number; one design system rather than three. IRCTC wins one criterion outright, access to status information without an account, and holds its own on expert input and early concessions. Neither site passes the keyboard test as audited: DB removes focus outlines in CSS, and IRCTC could not demonstrate them at all.
Takeaway
The difference between the two is not polish. It is the order of operations: DB shows the information, then asks for commitment; IRCTC asks for commitment, then shows the information. Everything else in the comparison follows from that one decision.
Counts
| Count | DB | IRCTC |
|---|---|---|
| Dismissals before the form | 0 | 2 |
| Interactions to results | 4 | 6 (plus the 2 dismissals) |
| Required form fields | 3 | 3 |
| Screens from results to last pre-payment step | 3 | 0 (login wall at first class click) |
| Upsells or pre-selected extras seen | 3 offered, 0 pre-selected before payment | 1 reported pre-ticked (unverified this session) |
| Buttons without accessible name | 0 of 21 | not measured |
| Images without alt | 14 of 16 | not measured |