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.

Guard · iOS appVisitor · mobile browserMVP design input

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.

Deliver guard-ios.html and visitor-browser.html, with index.html only as a launcher linking the two. Keep each prototype complete and self-contained. Include the screens, copy, alternate states, and acceptance criteria below.

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 the building, gate, destination, identity method, and visit state consistently. Never use color alone to communicate verification, admission, denial, or connectivity.

Bind the supplied Airbnb tokens: white canvas, near-black text, gray supporting labels, one restrained coral accent, the supplied single-family font stack, rounded inputs and subtle layered elevation for sheets. Adapt the system to a security utility; omit travel photography, listing cards, Airbnb branding, and decorative category icons. Do not imitate another company’s distinctive screen composition.

Keep visitor identity separate from entry status in the layout. Use one primary CTA per screen; “Deny entry” remains a clear secondary action. Pair foreground and background states to maintain contrast. On coral, select a token-based text pairing that meets 4.5:1; do not assume white text passes.

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.

G00 · Staff session

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.

G01 · Visits

Pending work, at a glance

Content: Pending visits with destination, elapsed wait, identity status, permission status, and a visit reference. “Start visit” is the primary action.
Behavior: Tap a row to resume that visit. Background updates change the relevant row without replacing the visit currently being reviewed. Empty copy: “No visitors waiting.”
States: Loading, empty, multiple pending visits, reconnecting, and session expired. Show the last successful sync time when disconnected.

G02 · Start visit

Choose the right destination

Content: Searchable tenant/apartment/office directory, selected destination summary, building and gate. CTA: “Generate QR code.”
Behavior: Require an explicit directory selection. Preserve the selection on errors. Prevent duplicate visit creation from repeated taps.
States: “Choose a destination to continue.” No results: “No destinations found. Check the name or unit number.” Directory unavailable: retry; do not silently allow an unverified destination.

G03 · QR & waiting

Give this visitor their own link

Content: Large QR, building/gate/destination, visit reference, expiry countdown, “Ask the visitor to scan with their phone camera.” Secondary actions: “Use manual check-in” and “Cancel visit.”
Behavior: Move to review after the backend accepts identity evidence. Leaving the screen does not cancel the visit. Regeneration invalidates the old reference while preserving visit context.
States: Waiting to scan, authentication in progress, expired, cancelled, identity received, and disconnected. Expired copy: “This QR code has expired. Generate a new code for this visitor.”

G04 · Identity & entry review

Make the entry decision

Content: Visitor name in full; identity method and status; destination; optional approved photo. Separate “Entry permission” block. Never show Emirates ID, nationality, gender, email, or phone by default.
Checks: Unchecked controls: “Person checked at gate” and “Entry permission checked.” Display host permission as Not required / Awaiting confirmation / Approved / Declined with source and time.
Behavior: “Admit visitor” opens a confirmation sheet with name and destination; “Confirm admission” writes the decision. “Deny entry” opens a sheet requiring a short policy-defined reason and “Confirm denial.” Admit stays disabled until required checks and policy are satisfied. Deny remains available.
Photo: Without a photo, show “Photo not provided” and the building’s alternative identity-check instruction. Never insert a stock portrait or suggest UAE PASS supplied a photo it did not supply.

G05 · Host permission, when required

Resolve permission without a third app

Content: Destination, host confirmation requirement, approved contact channel, outcome controls, and timeline.
Behavior: Proposed MVP: the guard contacts the resident/office through the building’s established channel, then logs Approved, Declined, or Unreachable. Record who confirmed, channel, time, and recording guard. Do not imply an integrated message was sent.
States: Awaiting confirmation blocks admission; Declined blocks admission; Unreachable stays pending or can be denied under policy. No silent timeout approval and no unapproved override.

G06 · Manual check-in sheet

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.

G07 · Decision result & visit detail

Show what was actually saved

Content: Admitted or Denied, visitor/destination, gate, guard and recorded time. Timeline separates visit creation, identity event, permission, decision, and checkout.
Behavior: Pending save says “Saving decision…”; success appears only after acknowledgment. A denied visit never enters Inside. A failed or uncertain save requires a status check before retry.
Copy: “Visitor admitted. Entry recorded.” / “Entry denied. Decision recorded.” / “Decision not confirmed. Check the visit status before trying again.”

G08 · Inside & checkout

Close the admission loop

Content: Search by name, destination, or visit reference. Rows show admitted time and identity method; the view represents admissions without recorded checkout.
Behavior: Open a visitor; “Record checkout” opens a confirmation with name and destination. Save checkout time and recording guard, then remove the visit from Inside. Duplicate checkout is a no-op, not a second event.
States: “No open visits.” Already checked out, checkout saving, stale connection, and checkout save failed. Do not silently infer exit after a time limit.

G09 · Restricted history

Find a record without exposing everyone

Content: Authorized history filtered by date, gate, destination, and decision. Minimal rows; tap for the same visit timeline. Denied, cancelled, expired, and checked-out visits have distinct labels.
Behavior: Scope visibility by role/building. Do not add bulk export to the MVP. Unauthorized staff see “You don’t have access to visit history.”

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.

V01 · Check-in introduction

Understand the request before continuing

Content: “Check in at [building name]”, gate, selected destination, and “Verify your identity, then wait for the guard to approve entry.”
Disclosure: “The building will receive your [approved field list] to check your identity and record this visit. The guard decides whether you can enter.” Show the actual field list, data controller, actual retention policy, and a privacy notice link before authentication.
Actions: Primary: “Continue with UAE PASS.” Secondary: “Need another way to check in?” → “Ask the guard for manual check-in.” Optional data sharing must not be preselected.

V02 · Authentication handoff & return

Let UAE PASS own authentication

Copy: “Continue in UAE PASS to confirm your identity. Return here when you’re finished.”
Behavior: Use the approved browser-to-UAE PASS flow and recover this same visit on return. Show “Checking identity…” while the backend validates the result. Never ask for UAE PASS credentials inside the building’s UI.
Prototype: Use a clearly labelled “Demo authentication” handoff, with “Simulate successful authentication” and a secondary cancellation path. No counterfeit UAE PASS login, invented official screens, production credentials, or claims of a live integration.

V03 · Awaiting guard decision

Verification is not entry

Copy: “Identity confirmed. Please wait at the gate.” Supporting text: “The guard is checking your identity and permission to enter.” Use “Additional identity check needed” when the verification policy is not satisfied.
Content: Building/gate/destination, visit reference, identity status and separate “Entry decision: Pending.” No “Access granted” language.
Behavior: Update automatically using an authorized visit session. Refresh or returning from the background restores current status. A connection failure says “We can’t get the latest status. Please ask the guard.”

V04 · Entry approved

Give a clear next step

Copy: “Entry approved.” / “The guard has approved your visit to [destination]. Please follow their directions.”
Content: Building, gate, destination, approval time, and “Tell the guard when you leave so your visit can be checked out.” No QR or browser badge acts as a reusable access credential.
States: If the visit later closes, display “Visit closed” and recorded checkout time.

V05 · Entry not approved

Resolve the outcome with staff

Copy: “Entry not approved.” / “Please speak to the guard for help.” Do not expose internal denial notes or host contact details.
Behavior: Terminal outcome for this visit. Do not offer a button that resubmits an admission request against the same used link.

V06 · Recovery states

A useful next step in every failure

Cancelled: “Identity check cancelled. Try again or ask the guard for help.” Retry only while the same authorized attempt remains valid.
Unavailable: “We couldn’t confirm your identity. Try again or ask the guard for manual check-in.” Do not claim the visitor has no UAE PASS account based on a network error.
Expired: “This check-in link has expired. Ask the guard for a new QR code.”
Used/invalid: “This link is no longer available. Please speak to the guard.” Reveal no visitor identity. The original authorized session may still see its own status.
Missing data: “Additional identity check needed. Please speak to the guard.” Missing name or insufficient evidence never creates an Identity confirmed state.

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.

Identity

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.

Permission

Not required, Awaiting confirmation, Approved, Declined, or Unreachable. Permission approval alone never changes entry status.

Visit

Pending → Admitted → Checked out. Pending may instead end as Denied, Cancelled, or Expired. Authentication events remain distinct from admission events.

Admit condition

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.

Single use

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.

Expiry

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.

Regenerate/cancel

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.

Concurrency

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.

Offline

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. No real visitor data, brand logo, photograph, or remote media asset is used in this brief.