Product & design brief · Version 1.0 · 30 September 2026
Identity on their phone.
Entry in the guard’s hands.
A UAE PASS–powered visitor check-in system for staffed buildings.
Visitors scan, verify with UAE PASS, and receive guard-approved entry—while the building records who was admitted, where they were going, and who approved them.
01 / What Open Design should build
Build two connected, high-fidelity interactive product prototypes: a guard’s iOS application and a visitor’s mobile browser flow. Use this document as the design brief. Prioritize the complete admission and checkout workflow over marketing pages.
The review set opens from index.html. It includes connected guard and visitor pages, standalone browser-demo variants, and this brief. The connected pair needs the Gatepass API; the standalone pair shares demo state in the browser.
Guard application
Designed for a staffed gate, one-handed use, interruptions, and quick decisions. Use an iPhone frame, Dynamic Island, safe areas, native navigation, sheets, and at least 44pt touch targets.
Visitor browser
Opened by the phone’s camera after scanning a QR. No separate visitor app or account creation. Adapt to iOS Safari and Android Chrome at 360–430px; preserve browser navigation and return from authentication.
The key distinction: “Identity confirmed” describes identity evidence. “Admitted” describes a guard’s entry decision. Neither UAE PASS authentication nor resident approval may admit someone automatically.
Scope: destination selection, visit-specific QR, authentication handoff, guard review, optional host permission, Admit/Deny, manual check-in, current visitors, checkout, and restricted visit detail. No resident app, door-unlock integration, payment, visitor registration, document scanning, or analytics dashboard in this MVP.
Status & ownership: draft for design exploration. The product manager owns policy decisions; building operations validates gate procedures; engineering validates integration capabilities. No user research or integration approval is assumed.
02 / Users & design priorities
- Guard: establish who is at the gate, where they are going, and whether entry is permitted. Maintain multiple pending visits without losing context.
- Visitor: understand the building’s request, share only necessary identity information, and know whether to wait, enter, or ask for help.
- Building operations: obtain an accountable admission record and a list of visits without recorded checkout. This is not a guaranteed physical occupancy count if exits are missed.
Use calm, direct language. Show building, gate, destination, identity method, or visit state only where each changes the next decision. Keep non-color status cues and a clear path to more detail.
Continue the approved cool iOS-inspired Gatepass palette, system typography, restrained outline icons, and light and dark appearances. Keep surfaces calm and controls familiar; avoid decorative density. Preserve the official UAE PASS logo at the identity handoff on a light inset when the page is dark.
Keep visitor identity separate from entry status in the layout. Use one primary action per screen; “Deny entry” remains a clear secondary action. Maintain readable contrast independently in light and dark appearances.
English is the first design deliverable. Support long and Arabic-script identity names without truncating them; plan layout mirroring for a later Arabic localization. A translated Arabic UI is a follow-on requirement, not a working language switch in this prototype.
03 / The connected journey
Guard starts a visit
Select the destination from the building’s directory. Show building and gate context; create one visit and a short-lived QR reference.
Visitor scans & understands
A browser page names the building and gate, shows the destination, explains the actual approved fields shared with the building, and offers “Continue with UAE PASS.”
Visitor authenticates
UAE PASS handles authentication. The backend retrieves approved identity information and attaches it to the original visit. An OAuth callback is not proof of physical presence or entry permission.
Guard reviews identity
The app updates automatically. The guard sees the returned name, identity status, destination, and photograph only if approved and available. Missing photograph remains a first-class state.
Guard checks permission & decides
Check the person at the gate and obtain resident or office confirmation where required. Explicitly confirm Admit or Deny. Visitor sees the resulting state.
Record entry, then exit
Only a saved guard admission places the visit in “Inside.” Record checkout against that admission; remove it from Inside and preserve the timeline.
04 / Guard iOS screens
Use a native tab bar: Visits for pending work and starting a visit, Inside for admitted visits without checkout, and History only for authorized staff. The header always identifies the assigned building and gate.
Know who is accountable
- Intent
- Every decision belongs to an authenticated guard, not a shared device identity.
- Content
- Staff sign-in or an existing authorized session; assigned building/gate and guard identity. The sign-in mechanism is an integration decision.
- Behavior
- After session expiry, preserve the pending visit and require reauthentication before a decision. For the prototype, start in a clearly labelled demo guard session; never invent a live credential service.
Review what is ready
Put verified visitors ready for a guard decision first. Show Start visit as the next common action. Keep visits still waiting for identity in a labelled disclosure; open the relevant visit to resume it.
Choose the destination
Search or choose one destination, then generate the visitor QR. Keep building context implicit in the guard session; show only the selected destination and next action.
Present the link
Make the QR, destination, and expiry the focus. Show regeneration when needed. Place manual check-in, cancellation, and visit metadata behind clearly labelled secondary controls.
Make the decision
Show the visitor name, destination, identity method, required in-person check, and required permission check before Admit. Keep Deny visible. Place the extended visit record behind Visit details.
Ask only at the decision point
If building policy requires host permission, surface that check in entry review. Keep contact or escalation detail in a disclosure until the guard needs it.
Keep the alternative accountable
- Content
- Banner: “Manual identity check — not verified with UAE PASS.” Required visitor name, fallback reason, policy-approved verification method, guard attestation, and original destination.
- Behavior
- Reasons: No usable phone / No connectivity / No UAE PASS account / Authentication unavailable. Offer only methods approved by the building. No default photo capture or identity-document number entry.
- Next
- “Continue to review” follows the same physical-presence, permission, Admit/Deny rules. Manual status persists in detail/history; it is never upgraded to UAE PASS verified.
Show the saved outcome
Lead with the recorded decision, visitor, and destination. For an admitted visitor, show Record checkout as the next action. Put timestamps and activity in Visit details and activity.
Find the person leaving
List visitors awaiting checkout. Show search when the list is long; opening a visit reveals its checkout action and record.
Find a record
Keep history out of the active queue. Show recent records first and put outcome filters behind Filter records. Preserve restricted access and audit information.
05 / Visitor mobile browser screens
The camera scan opens the browser. The product never requests camera access just to open the QR link. Do not display a directory of residents or expose other visits.
Understand and continue
Show building, destination, the name and demo identity result shared with the guard, and one Continue with UAE PASS action. Put privacy detail and alternate check-in behind labelled disclosures.
Keep the boundary clear
Show the official UAE PASS mark unaltered, the demo disclosure, and one simulation action. Keep Back and Cancel available. A live service replaces the simulation with its approved authentication handoff.
Wait at the gate
Say that the demo identity result was received, the guard decides entry, and identity verification is not permission to enter. Offer a status refresh without repeating a second status panel.
Follow the guard
Show the approval outcome and destination once. Explain that the page is not an access pass and checkout goes through the guard. Put the recorded time in Decision details.
Speak to the guard
Give the outcome and one clear next step. Do not expose internal denial reasons in the visitor flow.
Give one useful next step
Keep specific expired, cancelled, unavailable, and invalid-link messages. Offer retry only when the visit remains usable; otherwise direct the visitor to the guard.
Bracketed strings above are copy variables, not invented facts. Resolve them from approved configuration. In prototypes, visibly label sample building, destination, staff, names, and timestamps as demo data; never imply they came from UAE PASS.
06 / State & decision contract
Model separate state dimensions instead of one ambiguous “Verified” badge. The visitor and guard share the same authoritative visit record.
Not started → In progress → Confirmed, Needs additional check, Failed, or Cancelled. Manual check recorded is a separate method/status. “Confirmed” requires the configured evidence policy, not merely a successful login.
Not required, Awaiting confirmation, Approved, Declined, or Unreachable. Permission approval alone never changes entry status.
Pending → Admitted → Checked out. Pending may instead end as Denied, Cancelled, or Expired. Authentication events remain distinct from admission events.
Visit pending + accepted identity evidence (UAE PASS or approved manual method) + person checked at gate + entry permission checked + required host approval + active guard session + fresh server state.
The reference contains no identity data. Proposed behavior: claim it atomically when authentication starts; bind the attempt to that browser session. Allow authorized retries until a separate authentication deadline. Unrelated scans cannot bind another identity.
QR claim expiry applies before a browser claims it. The authentication attempt and pending visit have separate deadlines. A completed identity check does not expire just because the displayed QR timer reaches zero. Exact durations require policy approval.
Invalidate the old reference and attempt. Accept no late callback against them. Changing destination after identity attachment requires cancelling and creating a new visit; never silently carry approval to a different destination.
Resolve admission/denial atomically. If another guard decides first, show that saved outcome, guard, and time. Retried callbacks and writes must not duplicate identity, admission, or checkout events.
Cached rows carry a stale-data warning. MVP does not commit admission or checkout offline. Manual fallback covers identity failure, not backend failure; follow the building’s separate outage procedure and label later reconciliation explicitly.
07 / Data, privacy & integration boundaries
Minimum record
Store visit reference, building, gate, destination, creation time/guard, identity method, permitted identity reference and display name, identity outcome/time, physical-presence attestation, permission outcome/source/time, entry decision/time/guard, and checkout time/guard. Include cancellation/expiry and required denial/fallback codes in the event timeline.
Keep authentication failures and denials for the approved audit purpose, under their own retention rules; they are not admissions. The Inside view includes only admitted records with no checkout. Use server timestamps; display local building time with timezone on record details.
Identity data rules
- Persist and display only attributes justified for this workflow. Do not collect optional identity-document details, contact information, demographic data, or photographs by default.
- Photographs require explicit integration availability, access controls, purpose, retention, and an approved visual-check procedure. Their absence must not break the normal flow.
- Restrict history by role and building; log access and corrections. Record corrections as attributed events, never silent timeline edits.
- Set retention and deletion rules before live collection, including separate treatment for pending, denied, admitted, manual, and photo records. Do not invent a legal retention duration.
- Keep OAuth tokens and secrets on the backend; do not expose them in QR URLs, guard views, copied links, analytics, or visit history. Visitor status requires its authorized session, not only knowledge of a visit reference.
What is verified, and what is still conditional
Official UAE PASS documentation describes authorization-code authentication followed by token and user-info retrieval. Returned profiles differ; the application must use its approved scope and actual returned attributes. The documented general profile response does not establish that this integration receives a photograph.
Inference for this product: make the photo optional and validate the accepted account/assurance policy with UAE PASS onboarding before showing “Identity confirmed.” Design both confirmed and additional-check states now.
A forwarded QR can start a remote identity attempt. It cannot prove the visitor is physically at the gate. The guard’s check remains mandatory.
08 / Prototype behavior & assets
- Make start visit → QR → identity review → admission → Inside → checkout work end to end, with denial and manual check-in as working alternate paths.
- When both files run under the same origin, synchronize the demo visit across surfaces. Persist the current visit on refresh. On environments without shared storage, clearly label the surfaces as independent demo flows and provide equivalent in-flow actions; do not claim synchronization works.
- Use a real scannable QR for a routable demo URL when available. Otherwise label the QR surface “Demo QR — open the visitor prototype from the launcher.” Never present decorative pseudo-QR artwork as working.
- Keep demo fixtures labelled. Prototype timeouts are configurable demonstration values, not committed security policy. Do not use real identity-document numbers, live personal data, or an unrelated person’s photograph.
- Default to the no-photo variant. If an approved photo or brand asset is supplied later, localize it and preserve its aspect ratio. Use an official UAE PASS asset only from authorized brand materials; until then use the plain text label, not a drawn look-alike logo.
- Do not recreate UAE PASS’s proprietary authentication screens. Mock the handoff boundary explicitly.
- Keep scenario fixtures in code or a dedicated test harness. Product screens must not contain designer-only state switchers or fake operational controls.
Accessible behavior: minimum 44px/44pt targets, visible keyboard focus, named icon controls, announced status changes without focus theft, logical reading order, reduced-motion support, and full-name wrapping. Use at least 4.5:1 for normal text and 3:1 for large text/icons. Disable Admit with an adjacent explanation, not color alone.
Use supplied motion tokens for UI feedback. Announce “Saving…” immediately; do not fabricate completion times. Propose a 3-second healthy-network status update target for validation, not as an achieved performance claim.
09 / Acceptance checks
- Create a visit with a selected destination. Its QR is bound to that building/gate and contains no personal data.
- Open the visitor flow. Before authentication, the building, destination, actual sharing fields, privacy notice, and manual-help route are understandable.
- Complete the demo authentication. The guard sees that same visit’s identity event; the visitor still waits and Inside remains unchanged.
- Complete physical-presence and permission checks, then confirm Admit. Exactly one admission record contains visitor, destination, gate, guard, and time; only then does Inside update.
- Require host confirmation in one scenario. Awaiting, Unreachable, and Declined cannot silently become permission Approved.
- Deny a pending visit with a required reason. No admission exists and the visitor sees the safe denial copy.
- Complete manual check-in. The history permanently identifies the method as manual; it never claims UAE PASS verification.
- Exercise expired, already used, cancelled, forwarded, and regenerated links. Late callbacks cannot overwrite the replacement or another person’s identity.
- Retry admission and checkout writes; simulate a second guard acting first. No duplicate event appears and stale decisions do not overwrite the saved decision.
- Record checkout. The visit leaves Inside and retains entry/exit attribution. Repeating checkout reports the existing result.
- Refresh, resume, and interrupt connectivity. The current visit is restored; uncertain writes remain uncertain until checked, and stale data is labelled.
- Use long English and Arabic-script names, no photo, empty queues, and multiple waiting visitors. No text is clipped, no other visit is exposed, and review focus stays stable.
- Verify the visitor layout at 360/390/430/600/768/820/1024/1366/1440/1920px without horizontal scroll; verify guard content at iPhone widths with native safe areas and keyboard behavior.
How to evaluate the MVP
In staff/visitor walkthroughs, every participant should distinguish identity confirmation from entry permission and successfully complete admission and checkout without coaching. Track median and tail check-in time, manual fallback rate, unresolved waits, duplicate decisions, and checkout completion. Set operational targets after measuring the current process; no claimed speed improvement or reliability percentage is supplied.
Instrument the named lifecycle events, aggregate by identity method, and monitor denials and missed checkouts alongside speed. Do not optimize faster admission at the expense of physical checks or accountability; keep personal information out of analytics.
10 / Decisions to validate before production
These are production dependencies, not reasons to delay the design exploration. Make proposed policies visibly distinct from confirmed requirements.
Integration approval · UAE PASS onboarding + engineering
Confirm approved identity fields, supported profile/account types, assurance criteria, photograph availability, authentication handoff, allowed scopes, and production redirect behavior. A login alone is not automatically sufficient identity evidence.
Building policy · operations + product
Confirm which destinations need host permission, how guards contact hosts, acceptable physical checks when no photo exists, approved manual methods, denial reason codes, and handling of minors/groups. MVP assumes one person per visit; group visits require separate records.
Timing & staff access · security + engineering
Approve QR claim, authentication, and pending-visit deadlines; staff sign-in and building/gate assignment; session timeout; reconnection behavior; concurrent decision handling; and the separate building outage procedure.
Retention & history · data controller + privacy owner
Define actual sharing disclosure, retention/deletion durations, photo treatment, staff visibility, audit access, and correction process. Final privacy copy must match the approved policy; this document does not claim legal compliance.
Languages & field validation · product + building staff
Validate English-first delivery, Arabic localization priority, long-name behavior, and checkout ownership across multiple gates. Test the gate process with real guards and visitors before committing operational targets.
11 / Evidence & source notes
The six-step journey, single-use visit reference, guard decision, manual fallback, minimization, and checkout are confirmed by the product brief. Navigation, native sheets, recorded host calls, concurrent-write behavior, and deadline separation are proposed design/engineering defaults.
- UAE PASS: OAuth endpoints — authorization, token, and user-info integration boundaries.
- UAE PASS: authorization code — scopes, locale parameters, and citizen/resident versus visitor integration.
- UAE PASS: user information — profile-specific attributes. No assurance that this application receives all sample fields or a photograph.
References checked 30 September 2026. The review prototypes use sample visitor data and a locally stored official UAE PASS mark; no visitor photograph or real identity data is used.