
Steven Hart
Knowledge Architect

Gatwick Airport: organising knowledge and actions around a single identifier
For the airport traveller, almost everything is determined by one piece of information: the flight number. That single piece of data tells the traveller:
Where they need to be
When they need to be there
Which airport services are relevant
What can be ignored
My work on Gatwick Airport’s website began by recognising this not as a user insight, but as a structural fact.
The solution looked like navigation design, but the problem under the surface was that the old website had no organising principle.
The solution was to rebuild the experience around its structural anchor, the traveller's flight number.

The problem: complexity without structure
The existing site reflected the organisation, not the traveller. Instead of forming itself around user goals, the information on the old Gatwick website had:
Thousands of pages
Overlapping content
Multiple pathways to the same information
Inconsistent interaction patterns
Instead of helping travellers and reducing anxiety, it put a high cognitive payload onto the user to:
Search
Compare
Remember
Decide
In other words, the system exported its complexity directly onto the user.
This is a common failure mode in large systems: when no clear organising principle exists, everything becomes navigation and search overhead.

Understanding the domain
My exploratory work started in the physical environment, not the digital interface. I visited the airport and tried to map arrivals, departures, and transition zones. It became clear that even in real life, the dominant problem wasn’t a lack of information but a lack of orientation.
Travellers weren’t just confused. They were uncertain:
Where am I in the journey?
What happens next?
Am I about to miss something important?
That uncertainty creates cognitive load. Which, when under time pressure, quickly becomes anxiety.
So the objective wasn’t just to "improve usability of the website”, but to reduce cognitive load and anxiety when interacting with the whole airport as a system.
To do that, I used the website to become an explainer for the system.
I wanted to take the task of constructing a usable mental model of the airport away from the traveller, and have the website do that work on their behalf.

The structural insight
From my field research, including interviews with people travelling through the airport in real life, a consistent pattern emerged: every traveller organised their journey around their flight number.
The flight number acts as a primary key across the entire airport system.
It connects:
Terminals
Gates
Timings
Check-in
Security
Shopping
Parking relevance
Onward travel
Once you know the flight number, most other decisions are either resolved or dramatically simplified, and the content can shape itself around that piece of context.
The question was no longer How should we structure the website? but How do we structure an information system so everything can be derived from this identifier?

From designing content, to designing information systems
A good example was the car parking section of the website.
The original site presented more than twenty pages of parking information and options including:
Products
Pricing tiers
Distances
Terminals
Booking flows

Users had to read, compare, and mentally model the differences before they could select the option that best suited their needs: a decision problem.
I rebuilt that structure was around parking decisions users actually need to make:
Are you departing, picking up, or dropping off?
Which terminal is relevant?
What constraints matter most (time, cost, proximity)?
Once those are known, irrelevant options disappear. What was previously a large, flat, unfriendly content set became a structured decision system.

The product now didn’t just present options, it performed the filtering work on behalf of the user.

The architecture
With the flight number as the organising principle, and the idea of information systems established as a pattern, site information architecture followed quickly.
The system was structured around the traveller’s real sequence:
Getting to the airport
At the airport
Onward travel
Within each stage, content was dynamically constrained by:
Flight
Terminal
Journey type
This allowed the system to determine relevance instead of asking users to do it manually.
An early attempt to organise navigation strictly around the physical journey—from home to destination—tested poorly. Travellers prioritised “At the Airport” as the primary concern, regardless of sequence.
This is where many projects fail: logical models that don’t match lived mental models. It's why user testing and research are so important. I adjusted the structure accordingly.
Interface as a consequence of structure
With a knowledge architecture defined, the interface naturally became simpler. A key shift was from page-based navigation, and towards self-contained, progressive components.
For example:
Complex booking journeys became single, self-contained flows
Irrelevant options were removed upfront
Interaction patterns were standardised
The interface didn’t introduce new ideas, it just needed to express the underlying structure consistently.
Outcome
Winner: EpiServer Best B2C Website of the Year
Significant reduction in content volume
Improved engagement and commercial performance
Multi-year lifespan of core structural elements
One of the decision structures, the check-in flow, was later installed as physical signage in Departures. No photograph survives, but the fact that a piece of information design transferred directly from screen to wall is a reasonable measure of whether it was structurally right.
Reflection
This project was more than just a website redesign. The real work was identifying organising principles, self-contained flows, and redundant or repeated information.
Then finding ways to put only relevant information in front of people, in a way that matched their own mental model of the system they were navigating.
The thought processes called upon feel very similar to more recent work involving knowledge graph design, data modelling, and design for large-scale information systems.

Steven Hart
Knowledge Architect