At first glance, a travel information system seems like an uncluttered design task. The information is known, the user is clear, the purpose is clear. But those who look a little further will see that the traveler is not a constant. The same person who quietly seeks his connection in the morning is waiting on a crowded platform in the afternoon with heavy bags for a delayed train. Same system, totally different context.
We use travel information here as an example - not to judge existing systems, but because the domain makes the impact of context particularly clear. The traveler is recognizable, the situations are concrete, and the consequences of a wrong design choice are immediately felt. But the principles apply equally well to traffic management, planning software or any other digital system that people use in an operational context.
You design for the traveler. But which traveler, and at what moment?
Context determines the value of information. Not the information itself, but the situation in which someone receives it. That is the starting point: not the user in general, but the user at the moment the system really matters.
Three contextual factors deserve special attention: connectivity, time pressure, and physical situation. Each places different demands on the design. Together, they determine whether a system is usable when it really counts, or only when everything goes smoothly.
Connectivity: designing for the coverage gap
A travel information system that only works with a stable connection fails exactly where travelers need it most. Tunnels, rural routes, busy stations where hundreds of people open their app at once during a disruption. Those are precisely the moments when information is critical and the connection is least reliable.
The design question is not how the system works when everything is perfect, but what it does when the connection drops or slows down. Does it show outdated information without the user realizing it? Does it display an error message that doesn’t help? Or does the system have graceful degradation: a state in which it remains usable with the last known information?
Offline-first thinking changes fundamental design choices. Which information is stored locally? How old can cached data be before it becomes misleading? And how do you communicate uncertainty without causing panic in someone who is already stressed about their connection?
Questions you, as a designer, must be able to answer:
- On which routes or at which locations is poor connectivity structural, and how often is your target group there?
-
What is the minimum information the system must be able to show without a connection?
-
How does the system distinguish between “no connection” and “no disruption”?
Time pressure: the difference between three and thirty minutes
Time pressure is perhaps the most underestimated contextual factor in travel information design. A traveler who is calmly planning a day out reads. A traveler who has to catch a train in two minutes scans. Those two modes demand fundamentally different information structures.
In scan mode, the most relevant information must be visible immediately. No scrolling, no navigation, no thinking. Departure time, platform, delay: those are the three questions someone under time pressure has. Everything around that is noise in that moment.
But time pressure is not binary. There is a spectrum from “I have all the time in the world” to “I’m running now.” And the system does not know where on that spectrum the user is. That makes prioritization in the information structure all the more important: what always appears at the top, what must be reachable but not necessarily immediately visible, what can disappear in a simplified view?
A disruption makes time pressure both more acute and more complex. Exactly when someone must make a quick decision (continue, transfer, find an alternative) the amount of information increases. The design challenge then is: how do you reduce complexity at the moment reality becomes more complex?
Questions you, as a designer, must be able to answer:
- What is the user’s primary task in the first three seconds after opening the system?
-
How does the information structure behave during a disruption: does it become more or less?
-
Is a simplified view available for high-urgency situations, and who or what triggers it?
Physical context: designing for hands that aren’t free
A travel information system is rarely used from behind a desk. It’s used while standing on a platform, sitting in a swaying train, walking through a station hall, with luggage, a child, or simply two bags you can’t put down. The user’s physical situation determines how much attention and motor control they have available.
Small interface elements that feel natural on a desktop become frustrations in motion. Scrolling with one hand, tapping a tiny button while the train jolts, reading a screen in backlight – these are usage conditions you can’t design away, but you must design for.
Accessibility plays a role here too: an older traveler with reduced vision, someone with a disability, someone who doesn’t master the language well. Physical context and accessibility overlap more than they seem. Both call for larger elements, clearer hierarchy, and lower cognitive load.
The question is not whether the system works under ideal conditions. The question is whether it works when conditions are anything but ideal.
Questions you, as a designer, must be able to answer:
-
What are the most common physical usage conditions for the primary target group?
-
Are the interaction elements usable with one hand, without full attention?
-
Has the design been tested in the real environment, or only on a screen at a desk?
Context is not an edge case
The tendency in design is to design for the average user in the average situation, and to solve harder situations later. But in travel information, those “harder” situations are the most common use. Poor connectivity, time pressure, and physical constraints are not exceptions; they are the norm at the moment the system really matters.
The task is not to treat those contexts as an afterthought, but as a starting point. Not: how do we make this usable in difficult situations? But: if it works in the most difficult situation, it will work everywhere.
