Clubfold’s Door Flow Needs a Decision
Clubfold's early-October scanner work separated finding a membership from confirming identity and recording admission, with a native layout built for repetition.
The Clubfold work at the start of October concentrated on a very physical interaction: someone is waiting at a door while a staff member checks a pass.
A scanner can make that look like a one-step flow. Read the QR code, show a green screen, move on. The actual decision needs more context.
The native work on 1 October added fresh photo-ID confirmation at the door. The following day's changes refined the scanner layout. Both changes concern the same thing: making the operator's decision clear under repetition.
Finding the record is the beginning
The code lets staff find the relevant membership or reservation. It does not answer every question involved in admitting that person.
The flow needs the selected club or event, current eligibility, and the booked party size. The operator also needs to confirm the matching photo ID before recording admission.
That makes the final action meaningful. Staff can see what they are confirming, and the application can record an admission rather than merely a successful scan.
Repeated use changes the layout priorities
An account screen might be used once a week. A door screen can be used for one person immediately after another.
In that setting, the hierarchy should stay stable. Important details need a predictable position. The next scan should be easy to start. The final admission action needs a clear relationship to the person currently displayed.
A large decorative success state can become a liability if it obscures the party size or makes the operator work through unnecessary steps before returning to the scanner. Polishing this flow means improving the sequence, as well as the appearance of an individual result.
A Wallet pass and a current decision have different lifetimes
Clubfold also has a native Apple Wallet path. A saved pass is convenient because the member can reach it quickly. The admission decision still needs current server information.
That distinction matters when membership changes or an account is removed. Possessing an old visual artifact should not be equivalent to holding a current permission. The door workflow has to check the state that applies now.
It is also why network availability belongs in the operational experience. When the required current check cannot complete, the interface needs to say so clearly rather than turning absence of information into permission.
The member and the operator need different simplicity
The member wants to find the right pass and understand their booking. The operator wants to check the right person, make an explicit decision, and move to the next arrival.
Those are different interfaces around related information. Keeping the native screens focused on their own task makes each one easier to use.
The early-October scanner work is a good example of why I enjoy building native products alongside web systems. The backend defines what a decision means; the device interface has to make that decision practical in the place where someone actually performs it.