UX Analysis - Heuristics - Mobile
Dear DB Navigator: Two Date Issues That
Cost Your Users Money
I use the DB Navigator app almost every day. Hamburg to Bremen, Hamburg to Berlin, back again. It works well most of the time - but there are two date-selection issues that have caused me to buy the wrong ticket more than once. I reported them directly to Deutsche Bahn. And since I was writing it up anyway, I thought it was worth mapping them to Nielsen's heuristics - because these aren't random bugs. They're predictable UX failures with a clear explanation.
Good UX feedback isn't just "this is broken." It's "here's why it breaks, here's who it affects, and here's how to fix it."
The issues
#01
Travel date isn't reset when you change destination
Here's the scenario. I search Hamburg to Bremen and pick August 20 as my travel date. Later - maybe the same day, maybe a week later, in the same session - I change the destination to Berlin. I don't change the date because I'm thinking about the destination. The date field doesn't draw my eye. And so the app quietly carries over August 20 from my previous search.
I've bought the wrong ticket because of this more than once. And it's not just me - this week a friend of mine ran into the same issue trying to buy a daily ticket. He'd searched a different city with a different date about a week earlier. When he switched to "daily ticket," the app still had that old future date loaded. Since daily tickets can't be bought for future dates, the app showed zero results. He had no idea why. From a UX perspective, that's not a confused user - that's a broken system state.
the heuristics this violates
01
Error prevention (Heuristic 5)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
02
Visibility of system status (Heuristic 1)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
03
Match between system and the real world (Heuristic 2)
In the real world, if you change where you're going, your travel date for that destination is undefined until you decide it. The app's mental model - that your previous date applies to your new destination - doesn't match how people actually think about booking a journey.
My suggested fix
The date should reset automatically to today whenever the origin or destination changes. To keep things convenient for users who do want to carry a date forward, add a "last search" option - a chip or link directly under the date field that lets you deliberately restore the previous date. That way, resetting is the safe default and carrying forward is an explicit choice.
Design principle
Safe defaults protect users. If a system state could lead to an error, the default should be the one least likely to cause harm. Users can always override - but they shouldn't have to opt out of a mis-purchase.
#02
Return date can be set before the outward date
This one is simpler to describe but just as serious. When booking a return journey, the app allows you to select a return date that's earlier than your outward date. Outward journey: August 20. Return journey: today. The app accepts this without complaint.
A return journey that arrives before the outward journey departs is not a journey - it's a logical impossibility. And yet the system lets you book it.
the heuristics this violates
01
Error prevention (Heuristic 5) - again
This is one of the clearest possible violations of error prevention. The system has both dates. It knows the return is before the outward. The constraint that a return must follow an outward journey is not ambiguous. Preventing the user from selecting an impossible date combination is a trivial validation that simply isn't there.
02
Help users recognise, diagnose and recover from errors (Heuristic 9)
If the system does allow an impossible date combination through, it should at minimum show a clear error message in plain language that explains the problem and how to fix it. Something like: "Your return date is before your outward journey. Please select a return date on or after August 20." Currently there's no such warning.
My suggested fix
The return date picker should simply not allow selection of any date before the outward date - those dates should be greyed out or disabled. If for some reason the UX needs to allow any date to be tapped, a clear inline validation message should appear immediately, explaining the conflict and what to do.
Why I reported this - and why I'm writing about it
Both of these issues are fixable with reasonable effort. They're not architectural problems - they're validation gaps and default-state decisions that weren't thought through from the user's perspective.
I'm writing about them because they illustrate something important: the most damaging UX problems aren't usually the dramatic ones. They're the quiet ones. The date that persists silently. The validation that doesn't fire. The system state the user can't see. These are the issues that real users hit every day, that generate real financial consequences, and that are genuinely hard to notice if you're not the one using the product in a real-world context.
That's why regular, honest heuristic evaluations of your own product matter. Not just at launch. Ongoing. Because the problems are usually already there - they just need someone to look.
If you use DB Navigator too
Always double-check the date field when you change destination or ticket type. Until this is fixed, it's the one thing worth a second glance before you confirm.
more to discover
Most Viewed
Dark UX - Ethics - Personal
My mum got scammed by a beautifully
designed app. That broke something in me.
Scammers used to rely on bad grammar and obvious lies. Now some of them are hiring designers. And that changes everything.
Read More
UX Analysis - Good Design
A small UX win: how Hermes gets parcel tracking right
So it is only fair to call it out when an app actually gets the details right. This week that app is Hermes.
Read More
UX Analysis - Heuristics - Mobile
Dear DB Navigator: Two Date Issues That
Cost Your Users Money
I use the DB Navigator app almost every day. Hamburg to Bremen, Hamburg to Berlin, back again. It works well most of the time - but there are two date-selection issues that have caused me to buy the wrong ticket more than once. I reported them directly to Deutsche Bahn. And since I was writing it up anyway, I thought it was worth mapping them to Nielsen's heuristics - because these aren't random bugs. They're predictable UX failures with a clear explanation.
Good UX feedback isn't just "this is broken." It's "here's why it breaks, here's who it affects, and here's how to fix it."
The issues
#01
Travel date isn't reset when you change destination
Here's the scenario. I search Hamburg to Bremen and pick August 20 as my travel date. Later - maybe the same day, maybe a week later, in the same session - I change the destination to Berlin. I don't change the date because I'm thinking about the destination. The date field doesn't draw my eye. And so the app quietly carries over August 20 from my previous search.
I've bought the wrong ticket because of this more than once. And it's not just me - this week a friend of mine ran into the same issue trying to buy a daily ticket. He'd searched a different city with a different date about a week earlier. When he switched to "daily ticket," the app still had that old future date loaded. Since daily tickets can't be bought for future dates, the app showed zero results. He had no idea why. From a UX perspective, that's not a confused user - that's a broken system state.
the heuristics this violates
01
Error prevention (Heuristic 5)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
02
Visibility of system status (Heuristic 1)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
03
Match between system and the real world (Heuristic 2)
In the real world, if you change where you're going, your travel date for that destination is undefined until you decide it. The app's mental model - that your previous date applies to your new destination - doesn't match how people actually think about booking a journey.
My suggested fix
The date should reset automatically to today whenever the origin or destination changes. To keep things convenient for users who do want to carry a date forward, add a "last search" option - a chip or link directly under the date field that lets you deliberately restore the previous date. That way, resetting is the safe default and carrying forward is an explicit choice.
Design principle
Safe defaults protect users. If a system state could lead to an error, the default should be the one least likely to cause harm. Users can always override - but they shouldn't have to opt out of a mis-purchase.
#02
Return date can be set before the outward date
This one is simpler to describe but just as serious. When booking a return journey, the app allows you to select a return date that's earlier than your outward date. Outward journey: August 20. Return journey: today. The app accepts this without complaint.
A return journey that arrives before the outward journey departs is not a journey - it's a logical impossibility. And yet the system lets you book it.
the heuristics this violates
01
Error prevention (Heuristic 5) - again
This is one of the clearest possible violations of error prevention. The system has both dates. It knows the return is before the outward. The constraint that a return must follow an outward journey is not ambiguous. Preventing the user from selecting an impossible date combination is a trivial validation that simply isn't there.
02
Help users recognise, diagnose and recover from errors (Heuristic 9)
If the system does allow an impossible date combination through, it should at minimum show a clear error message in plain language that explains the problem and how to fix it. Something like: "Your return date is before your outward journey. Please select a return date on or after August 20." Currently there's no such warning.
My suggested fix
The return date picker should simply not allow selection of any date before the outward date - those dates should be greyed out or disabled. If for some reason the UX needs to allow any date to be tapped, a clear inline validation message should appear immediately, explaining the conflict and what to do.
Why I reported this - and why I'm writing about it
Both of these issues are fixable with reasonable effort. They're not architectural problems - they're validation gaps and default-state decisions that weren't thought through from the user's perspective.
I'm writing about them because they illustrate something important: the most damaging UX problems aren't usually the dramatic ones. They're the quiet ones. The date that persists silently. The validation that doesn't fire. The system state the user can't see. These are the issues that real users hit every day, that generate real financial consequences, and that are genuinely hard to notice if you're not the one using the product in a real-world context.
That's why regular, honest heuristic evaluations of your own product matter. Not just at launch. Ongoing. Because the problems are usually already there - they just need someone to look.
If you use DB Navigator too
Always double-check the date field when you change destination or ticket type. Until this is fixed, it's the one thing worth a second glance before you confirm.
more to discover
Most Viewed
Dark UX - Ethics - Personal
My mum got scammed by a beautifully
designed app. That broke something in me.
Scammers used to rely on bad grammar and obvious lies. Now some of them are hiring designers. And that changes everything.
Read More
UX Analysis - Good Design
A small UX win: how Hermes gets parcel tracking right
So it is only fair to call it out when an app actually gets the details right. This week that app is Hermes.
Read More
UX Analysis - Heuristics - Mobile
Dear DB Navigator: Two Date Issues That
Cost Your Users Money
I use the DB Navigator app almost every day. Hamburg to Bremen, Hamburg to Berlin, back again. It works well most of the time - but there are two date-selection issues that have caused me to buy the wrong ticket more than once. I reported them directly to Deutsche Bahn. And since I was writing it up anyway, I thought it was worth mapping them to Nielsen's heuristics - because these aren't random bugs. They're predictable UX failures with a clear explanation.
Good UX feedback isn't just "this is broken." It's "here's why it breaks, here's who it affects, and here's how to fix it."
The issues
#01
Travel date isn't reset when you change destination
Here's the scenario. I search Hamburg to Bremen and pick August 20 as my travel date. Later - maybe the same day, maybe a week later, in the same session - I change the destination to Berlin. I don't change the date because I'm thinking about the destination. The date field doesn't draw my eye. And so the app quietly carries over August 20 from my previous search.
I've bought the wrong ticket because of this more than once. And it's not just me - this week a friend of mine ran into the same issue trying to buy a daily ticket. He'd searched a different city with a different date about a week earlier. When he switched to "daily ticket," the app still had that old future date loaded. Since daily tickets can't be bought for future dates, the app showed zero results. He had no idea why. From a UX perspective, that's not a confused user - that's a broken system state.
the heuristics this violates
01
Error prevention (Heuristic 5)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
02
Visibility of system status (Heuristic 1)
Nielsen's fifth heuristic says good design prevents problems from occurring in the first place. A date that persists silently across destination changes is a problem waiting to happen. The system has all the information it needs to prevent this error - it knows the destination changed - and does nothing with it.
03
Match between system and the real world (Heuristic 2)
In the real world, if you change where you're going, your travel date for that destination is undefined until you decide it. The app's mental model - that your previous date applies to your new destination - doesn't match how people actually think about booking a journey.
My suggested fix
The date should reset automatically to today whenever the origin or destination changes. To keep things convenient for users who do want to carry a date forward, add a "last search" option - a chip or link directly under the date field that lets you deliberately restore the previous date. That way, resetting is the safe default and carrying forward is an explicit choice.
Design principle
Safe defaults protect users. If a system state could lead to an error, the default should be the one least likely to cause harm. Users can always override - but they shouldn't have to opt out of a mis-purchase.
#02
Return date can be set before the outward date
This one is simpler to describe but just as serious. When booking a return journey, the app allows you to select a return date that's earlier than your outward date. Outward journey: August 20. Return journey: today. The app accepts this without complaint.
A return journey that arrives before the outward journey departs is not a journey - it's a logical impossibility. And yet the system lets you book it.
the heuristics this violates
01
Error prevention (Heuristic 5) - again
This is one of the clearest possible violations of error prevention. The system has both dates. It knows the return is before the outward. The constraint that a return must follow an outward journey is not ambiguous. Preventing the user from selecting an impossible date combination is a trivial validation that simply isn't there.
02
Help users recognise, diagnose and recover from errors (Heuristic 9)
If the system does allow an impossible date combination through, it should at minimum show a clear error message in plain language that explains the problem and how to fix it. Something like: "Your return date is before your outward journey. Please select a return date on or after August 20." Currently there's no such warning.
My suggested fix
The return date picker should simply not allow selection of any date before the outward date - those dates should be greyed out or disabled. If for some reason the UX needs to allow any date to be tapped, a clear inline validation message should appear immediately, explaining the conflict and what to do.
Why I reported this - and why I'm writing about it
Both of these issues are fixable with reasonable effort. They're not architectural problems - they're validation gaps and default-state decisions that weren't thought through from the user's perspective.
I'm writing about them because they illustrate something important: the most damaging UX problems aren't usually the dramatic ones. They're the quiet ones. The date that persists silently. The validation that doesn't fire. The system state the user can't see. These are the issues that real users hit every day, that generate real financial consequences, and that are genuinely hard to notice if you're not the one using the product in a real-world context.
That's why regular, honest heuristic evaluations of your own product matter. Not just at launch. Ongoing. Because the problems are usually already there - they just need someone to look.
If you use DB Navigator too
Always double-check the date field when you change destination or ticket type. Until this is fixed, it's the one thing worth a second glance before you confirm.
more to discover
Most Viewed
Dark UX - Ethics - Personal
My mum got scammed by a beautifully
designed app. That broke something in me.
Scammers used to rely on bad grammar and obvious lies. Now some of them are hiring designers. And that changes everything.
Read More
UX Analysis - Good Design
A small UX win: how Hermes gets parcel tracking right
So it is only fair to call it out when an app actually gets the details right. This week that app is Hermes.