Steven Hart

Knowledge Architect

Snapshot of a knowledge graph

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.

Snapshot of a knowledge graph

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