CEKAP

Airport guidance for the day you have the least capacity to think.

Role
Research, UX, design system, front end
Timeline
May 2026 - Present
Team
Self-Initiated Project
Status
v1 built, not yet tested with travellers
Design
Figma
Build
Expo React Native, Claude Code

Where it starts. The closed gate was not the hard part.

March 2025. Weeks after surgery for a herniated disc, I flew from KLIA2 with my sister. We dropped bags upstairs, went down to sit because sitting was the whole point of my recovery, then misjudged the walk back. We hit security ten minutes past the line. The flight left without us.

There is no “average” traveller

Airport journeys are planned around an average person: average pace, attention, confidence and ability to stand and walk. Real capacity moves. It can be permanent, like a mobility or sensory condition. Temporary, like recovering from surgery. Or situational, like rushing through an unfamiliar terminal with bags on both arms. The design has to serve reduced capacity without asking anyone to diagnose themselves first.

What the existing ecosystem already does well

I mapped seven products across nine capabilities: MYairports, Malaysia Airlines, AirAsia MOVE, Batik Air and Firefly.

Information is everywhere. Flight status, check-in, maps and boarding details are covered several times over. The gap opens after the information arrives. A traveller can know the gate and the departure time and still not know whether they can sit down, whether the queue is turning risky, or which task matters first.

That moved the concept away from another airport app and towards a thin layer that interprets what already exists.

What reported experiences suggest

Interviews fell through twice. Rather than let one bad day stand in for research, I ran a structured desk pass and graded every source by what it could actually support. Official pages establish timing rules. News reports document specific incidents. Reviews and forums show failure patterns but never how often they happen.

Five things held up. Walking distances are long enough that Malaysia Airports added buggies and travelators. Terminal 1 and Terminal 2 are separate journeys, and booking platforms often show only Kuala Lumpur International. A single failure cascades, as in the 2023 Aerotrain breakdown that stranded 114 passengers, ten of whom reportedly missed flights. Queues resist estimation, with a 2025 autogate failure producing reported two-hour waits. And the timing rules live in separate systems: Malaysia Airlines closes counters at 60 minutes and gates at 30, AirAsia closes bag drop at 60 and gates at 20, and combining those with security, immigration and the walk is left entirely to the traveller.

What this cannot tell me is how often any of it happens, which problem causes the most stress, or whether anyone would install a companion app. That needs people, not better sourcing.

The solution. Four inputs resolve to one next action.

Airline deadline, chosen pace, last confirmed checkpoint, and how stale the data has gone. Those four produce one prioritised next step, and every screen answers the same three questions: where am I, what now, is stopping safe. It is built for a single capability, reading a status and acting on it while moving, which is what makes the permanent case, the post-surgery case and the four-percent-battery case the same design problem.

Three calls I would defend in a review.

Manual checkpoints over sensing

GPS is unreliable around large terminal buildings, and continuous location creates a trail I would have to secure and explain. Manual confirmation survives a dead network and hands back a small win at each step. The flaw is obvious, a stressed person forgets to tap, so confirmation sits on the lock screen with fallback to the last confirmed point.

Offline is a connection state, not a truth state

Losing signal does not make saved information wrong. It means the app cannot see what changed. Five states carry that distinction: confirmed, live, likely, last known, unconfirmed. Advice turns conservative as data ages, and on reconnect a change is announced rather than quietly swapped.

A Rest Window after every completed checkpoint

Clearing a checkpoint is the moment a tired traveller most wants to sit down and least knows whether they can. So every completed step returns a Rest Window: how long you can safely pause before the next deadline bites, calculated from your own pace rather than an average walker. It answers the question my own missed flight failed on, without the traveller having to ask.

The prototype, in Figma and in code.

The prototype is built in Figma and Expo. It is not yet tested with travellers, but it is ready for user testing and iteration.

Metrics. What I would measure, and what I have.

3

Tasks in the test plan

Decide whether resting is safe. Read a departure change after reconnecting. Find the way forward after a missed flight.

4

Signals I would track

Correct rest-or-move calls, whether saved data reads as current, skipped confirmations, plus SUS and AttrakDiff because calm is part of the claim.

3

Predictions logged before session one

I made it too calm and someone misses the urgency. Saved information reads as current. Someone opens the airline app first.

0

Travellers tested so far

Recruitment fell through twice. There are no results here and I am not going to imply otherwise.

What is next, and what could sink it.

Desk research suggests the problem exists. It cannot show how often, or how people behave under stress. Travellers already carry an airline app, a wallet pass and their own checklist, so the open question is whether Cekap earns a place beside them.

Shared Awareness, letting someone trusted follow the journey, is the feature people react to most and the one I cut. It carries the highest infrastructure cost, the highest privacy risk and my weakest evidence, so it waits until the manual journey is proven.

Next, I’ll validate the concept through five think aloud sessions, targeted re tests, and a core task comparison with an existing airline product. I’ll also test offline recovery, finalise the key flows in Figma and code, complete the POUR review, and revisit the problem definition based on what I learn.