JFK Airport
Streamlining visitor escort requests for the largest terminal at JFK International Airport.
- Role: UX Designer — Interaction Design, Visual Design, User Flows, Prototyping
- Team: 2 UX Designers — 1 Senior Web Developer, 1 Project Manager, 1 Creative Director
- Timeline & Status: 3 Months — Launched in January 2025
Overview
JFK Terminal 4 is the largest terminal at New York's John F. Kennedy International Airport, and it's full of businesses that aren't T4-affiliated. When those businesses host a temporary visitor — a repair worker, a contractor, a visiting manager — that person needs to get past security to reach the store, restaurant, or lounge they're there for.
That vetting ran entirely on a web form and email replies. To replace this cumbersome email-based process, I designed an all-in-one dashboard where employees can submit requests, track their statuses, and see exactly why something was rejected.
The dashboard launched in January 2025 and has been in use at Terminal 4 ever since.
- 12,000+ — employees directly served
- 7,000+ — escort requests handled a month
Figures: Walkthrough of the dashboard in use.
Context: Every business inside the terminal must have their visitors screened beforehand and assigned a certified escort to get past security.
T4 spans over 2 million square feet, houses 22 airlines, and serves 25+ million passengers a year. Businesses often have temporary visitors (e.g. repair workers, contractors, visiting managers) who need to enter the Sterile Area — the zone past the TSA checkpoint.
Visitors must be given a gate pass, which means they must be screened beforehand by the terminal security team and paired with a certified escort. Any employee at a business can start this visitor vetting process by submitting a form.
The original form was unnecessarily long. After submission, all updates were sent via email.
Employees had to dig through their inbox to find every update, including whether a submission was approved or rejected. Specific details like access location and badge number only arrived on the day of the visit.
Figures: The original Escort Authorization Portal — a single long form with a wall of instructions above it.
Figures: The T4 security protocol and how a visitor escort gets requested.
The Problem: Terminal 4 had no way to view or track escort requests, so employees managed visitor access out of their inboxes.
Once a request was submitted, every update — approved, rejected, pending — arrived as an email. With thousands of requests a month, statuses got buried in inboxes and employees lost track of what they had already sent.
Rejections were the worst case: they arrived with no reason attached, so employees had to guess what to fix before resubmitting. For time-sensitive visits, that guesswork meant real delays.
Key issues
No visibility
Statuses were scattered across email threads with no single place to check them.
Repetitive work
Employees would unknowingly resubmit requests they had already sent.
No transparency
Rejections came with no reason, making corrections a guessing game.
No room to grow
A single form left nowhere to add guidelines, FAQs, or new features later.
Figures: The problems with the original email-based system.
Solution: An all-in-one digital dashboard to easily view and submit visitor escort requests.
Our Solution
The dashboard replaces the email-based process entirely. Employees can now search, filter, and sort every request they've submitted in one place.
- Centralized requests — track pending, approved, and rejected statuses at a glance
- Full request details — visitor info, escort, and visit dates in one view
- Search and filtering — get to any request quickly
- Clear rejection reasons — know exactly what to fix before resubmitting
Track at a glance: Every request from the past 120 days, with its status visible without a single click.
The dashboard leads with the five things employees actually need to compare: visit date, visitor names, reason for escort, status, and submission date.
Requests whose visit date has passed drop into a separate Past Requests section with a grayed-out date tag, so the active queue stays clean.
When visitors in one request get different outcomes, the row splits — but stays grouped and readable at a glance.
A submission can cover up to five visitors, and T4 security doesn't always return the same answer for all of them — one person approved, another rejected, a third still pending.
Rather than force a single status onto the whole request, those visitors split into their own rows and stay visually grouped by status. Employees can see exactly who was cleared and who needs a resubmission without opening anything.
Figures: How one submission renders as grouped rows when visitor statuses differ. · Grouped rows in the dashboard, separating visitors by status.
Figures: The request queue, with status visible on every row.
Expand for details: Requests open accordion-style, revealing all the visitor and escort details when you want it.
Expanding a row shows the full submission without navigating away — useful for confirming visitor details, checking whether a request was already sent, and reading the rejection reason.
Rejected requests now tell you what to fix for resubmission.
Rejected requests carry an explanation at the top of the expanded view, so employees know exactly what to fix before resubmitting.
Figures: A rejection reason surfaced directly in the request, on desktop and mobile.
Figures: Expanding a request to reveal full visitor and escort details. · Expanded request details on mobile.
Search and filter: Filters for the three things employees search by most.
Status, visit date, and submission date cover nearly every lookup, and the search bar handles the rest — finding a specific visitor by name, for instance.
Applied filters appear as dismissible chips above the queue, so it's always clear what's narrowing the list.
Figures: Filtering and searching through requests. · The three filter panels: status, visit date, and submission date. · The filter modal and applied-filter chips on mobile.
Announcements: A place for admins to reach all 12,000 employees at once.
Portal admins can post a non-dismissable announcement to the top of the dashboard — the first thing employees see when they log in.
Figures: An announcement pinned to the top of the dashboard. · The announcement on mobile.
A home for information: The wall of text moved off the submission form and into a page built to hold it.
The instructions that used to sit above the submission form now live on a dedicated Information page, organized into sections with a side navigation: general information, submission guidelines, reminders for escorts, and privacy statements.
Giving this content a real home also made the portal scalable. We used the new space to add an FAQ section — a long-requested feature that previously had nowhere to go.
Figures: The Information page, with a side navigation for jumping between sections. · The Information page on mobile, including the new FAQ section.
Account details: No more logging back in for every submission.
One login, one portal, and a dedicated Account page where your details always live.
Figures: The Account page on desktop and mobile.
Final Designs: Final Design Gallery
Figures: The dashboard end to end. · The Escort Authorization Portal across desktop and mobile. · Announcements on desktop. · An expanded request with its rejection reason, on desktop and mobile. · Filtering and searching on desktop. · Filtering on mobile. · The Information page on desktop. · The Information page on mobile. · The Account page on desktop and mobile. · Loading and empty states. · Additional mobile screens.
The Process
As we identified earlier, the main problem with the previous email-based process was…
The problem: Terminal 4 had no way to view or track escort requests, so employees managed visitor access out of their inboxes.
So building visibility, transparency, and a single place to track every request was the next step.
Research & scope: Mapping how escort requests actually move through the terminal.
JFKT4 has been a longtime client of Ronik, the NYC agency where I worked as one of two UX designers on this project. That existing relationship meant direct access to the people running the vetting process.
We mapped the full lifecycle of a request and found the edge cases that made the old system painful.
- A single submission can include up to 5 visitors
- A single submission can span multiple visit dates
- Employees often have many requests pending at once, and submit in bulk
- Rejected requests must be corrected and resubmitted
- One request can end up with different statuses per visitor
- Every update arrives only by email
Storyboarding the process to understand the user.
To make sure the whole team shared the same picture of the problem, we storyboarded the process end to end — first the security protocol and how an escort request gets made, then the pain points employees hit once they'd submitted one.
Walking through it scene by scene surfaced exactly where the email-based workflow broke down, and gave us a reference we could put in front of the client.
Figures: The T4 security protocol and how a visitor escort gets requested. · The problems with the original email-based system, and the proposed all-in-one dashboard.
Defining requirements with the client before designing anything.
We proposed an all-in-one dashboard, then worked with the client to pin down requirements that fit their needs, budget, and three-month timeline.
- A branded dashboard as the landing page after login
- Display submissions from the past 120 days
- Sort and filter by status, visitor name, reason, submission date, and request date
- Submissions expandable by accordion within a single page
- Show visitor details, account details, and terminal info
Wireframes: Brainstorming different layouts before touching Figma.
I wireframed a range of dashboard layouts first — different column orders, ways of grouping requests, and places to put filters and search. Working rough meant I could throw out a bad structure in seconds instead of rebuilding a Figma file around it.
Those wireframes became the shortlist for what to actually build. Each one I kept turned into a direction worth trying digitally, so by the time I opened Figma I already knew which ideas were worth the effort and which had been ruled out.
Figures: Early wireframes for the dashboard.
Screen iterations: Finding the balance between simplicity and information density.
The dashboard holds a lot of content, so most iteration went into the table itself. I built a component system in Figma so I could spin up a new variant of any UI element and drop it into a premade page — fast enough to explore dozens of directions.
Iterating on the request table.
I explored column ordering, row styles (strokes versus pajama stripes), tag styles for visit dates and statuses, selected-state colors, and how rows should group.
Figures: Table style explorations.
Building a component system to iterate faster.
Throughout the design and iteration stage, I built every UI element as a Figma component with variants — row styles, status tags, date tags, visitor indicators, expanded detail panels.
That let me assemble a new version of the table in seconds and test different combinations of components against each other, instead of rebuilding a layout by hand for every direction I wanted to try.
Figures: The Figma component system behind the explorations.
How do you show that only some visitors in a request were rejected?
A submission can include five visitors, and their statuses often differ — everyone approved except one person, for example. A single status tag per row couldn't represent that.
I explored circle indicators for each visitor, colored names, pajama stripes, visual grouping bars, and fully separate rows.
Figures: Explorations for showing mixed visitor statuses within one request.
Iterating on how full request details open.
Accordion rows, a separate detail page, and a modal were all on the table. We debated the trade-offs with each of these versions to decide what to use in the final design.
Figures: Explorations for opening full request details.
Refinement: Simplicity won.
After pitching several directions, we went with the minimalistic accordion. Because the dashboard carries so much content, reducing visual clutter mattered more than added indicators — so out went the excess boxes, icons, and complex status markers.
For mixed statuses, visitors from the same request split into separate rows that stay visually grouped. That came straight from user feedback: people wanted visitors from one request kept together, but still wanted a clean UI.
Figures: The final design for the table, with a minimalistic accordion UI style.
Retrospective
The dashboard launched in January 2025 and is in active use at JFK Terminal 4, serving 12,000+ employees and handling 7,000+ escort requests a month. It replaced a process that ran entirely on email.
- “It's so nice having one place for all my requests.” — Employee of a JFK T4 business
- “Wow, this is going to make resubmissions so much easier.” — Employee of a JFK T4 business
- “This is so much better than searching through my email.” — Employee of a JFK T4 business
Lessons learned
The power of iteration and exploration 🔁
Exploring many directions early is what surfaced the good solutions — not settling on the first idea. Generating a wide range let me find what actually resonated with stakeholders and refine from there.
Collaborating efficiently with others 🤝
With this much collaboration and critique, I learned to organize design files so anyone could follow them: clear ownership, version history, structured iterations, and heavy use of auto-layout and reusable components.
Communicating and presenting your design 💬
Presenting to non-designers sharpened how I justify decisions. Walking clients through multiple options with honest trade-offs is what got us to a final design that met their goals without compromising the experience.