Concept · Functional web prototype · 2026
Leeway helps travelers plan their arrival at Ben Gurion Airport by booking a security screening time slot and following their progress through the airport.
A concept project. The prototype runs in any browser but is not connected to the airport’s booking or security systems.
01 The challenge
At Ben Gurion, departing travelers pass a short security interview at the terminal entrance, before check-in. Its length is hard to predict, so most people simply arrive three hours early. Leeway replaces that guess with a booked window.
“I always get to the airport about three hours before the flight.”Interviewee 4 (translated from Hebrew)
02 Research & Direction
Four interviews pointed to the same thing: travelers couldn’t tell how long the airport would take, so they arrived early just in case.
2.5–3.5 hours before departure, every trip.
Design responseWindows are generated from the flight’s departure time.
Security on one trip, check-in on the next.
Design responseOnly security is booked. Check-in is shown, never promised.
Passport and boarding pass at the desk.
Design responseThe QR works alongside the documents, not instead of them.
Counts are from four real interviews. Four simulated scenarios were used only to flag assumptions. Research methodology
Primary persona
Once lost over an hour when a desk closed. Now he always arrives three hours early. He lacks control, not patience.
Secondary persona
Plans with her own tools. Her longest wait was at check-in, so Leeway serves her least.
Scores (1 = frustration, 5 = motivation) are my scenario-based estimates from the journey-mapping exercise, built on the persona research. They were not measured with participants.
Leeway books the security screening and follows the traveler until check-in ends. Check-in appears as the next stage without a reserved time, because its length depends on things nobody can book.
03 Designing Leeway
One booking choice, a home screen that follows the trip, and a confirmation that works under pressure.
A · Book
Early wireframes asked for a security window and a check-in window. I removed the second: after an unpredictable screening, a check-in slot would be a guess dressed as a reservation.
The screen now offers nine 20-minute windows built from the departure time. The last ends two hours before take-off.
B · Track
The home screen keeps one layout, but its status card changes with the traveler’s state, so the next useful action is always the obvious one.
C · Access
At the desk, the QR opens full screen in one tap, and the app shell is cached so it loads without a signal.
Many travelers don’t read Hebrew, so the interface runs in Hebrew, English, Arabic and Russian, with right-to-left layouts where needed. The language switch sits on the home screen, where someone who can’t read the interface will find it.
Visual language
Of four explored directions, I set aside the most playful: a cheerful tone didn’t fit the journey’s most stressful moment.
04 Interaction & Prototype
A working HTML, CSS and JavaScript prototype. Step through the main flow, then try it.
Captured from the prototype. The flight card uses a sample departure record; window availability is simulated.
Enter a real flight leaving Ben Gurion in the next few days, and the windows are calculated from its departure.
05 Outcomes & Reflection
I watched up to seven people try the prototype, informally. Their reactions led to these changes.
An empty field used to open a full error screen, and people froze. Now the form marks what’s missing in place.
After: the fields to fix are marked in place.
The first round offered a date strip and windows across the morning. The final grid shows only the nine that fit the flight.
After: windows derived from the departure time.
People asked what they were booking. A first-visit walkthrough now points at the real controls.
Several testers didn’t read Hebrew. This had the largest effect of any change.
The field now accepts non-Israeli passport formats.
The first build froze Figma’s example windows; a 21:10 flight got a 6:40 slot. The rule now lives in one place in code.
One bookable stage kept the flow short and made it easy to cut screens.
A value in a design file can be an example or a rule. I now mark which before anything is built.
Appendix
Full research boards, methodology and implementation notes, for anyone who wants to go deeper.
I interviewed four people. In parallel, I wrote four simulated interviews to test assumptions I had no one to ask about: a frequent business traveler, a parent of small children, a retiree who avoids new apps, and an airport operations worker. They are labeled as simulated in every document, were not used to form the personas, and are not quoted as evidence.
| Insight | Real interviews | Simulated scenarios | Used as |
|---|---|---|---|
| Fixed early arrival, regardless of load | 3/4 | 3/4 | Evidence |
| The bottleneck shifts between security and check-in | 3/4 | 2/4 | Evidence |
| Identification runs on physical documents | 3/4 | 1/4 | Evidence |
| Name and flight number may not be enough to identify someone | 0/4 | 1/4 | Hypothesis |
| Low-tech travelers may abandon digital pre-registration | 0/4 | 1/4 | Hypothesis |
The passport field came from the first hypothesis. I added it anyway because the costs weren’t symmetric: one more field against a traveler who can’t be identified at the desk. It is also consistent with the real finding that the passport is the first document staff ask for.
Testing was informal observation of up to seven people, with no recordings and no defined tasks. Analytics were installed but did not record visits reliably, so there is no quantitative data.
One real interviewee said the line had become faster on its own over the past year. People still arrived three hours early, which pointed to uncertainty, rather than line length, as the problem.
I checked every journey-map stage against the sitemap twice. Screens with no stage in the journey (FAQ, Contact us, flight history) were removed, and so was the check-in window at registration. The final structure has two states with automatic transitions between them. The primary persona’s acceptance test is marked on the board as partially met: the app can’t yet predict check-in load.
The prototype is plain HTML, CSS and JavaScript, hosted on GitHub Pages. I built it with an AI coding assistant, working from my Figma file and reviewing the result screen by screen. The flight lookup uses keyless public sources: the Israel Airports Authority’s open departures feed for date, time and terminal, and a route database as a fallback. No name or passport number leaves the device.
| Behavior | First build | Refined |
|---|---|---|
| Time windows | Example values copied from the Figma frame | Nine 20-minute windows built backward from departure, defined in one place |
| Unknown flight | Fell back to the demo route | Shows the number actually typed, with a neutral card |
| Extra passengers | Could be added but not removed | Remove action with renumbering |
The question that most changed the design came during the build: if the check-in window depends entirely on an unpredictable screening, why offer it as a choice at all? It removed a whole selector from registration.
