Invite Friends Flow — Spec & Design Doc

Artifact selection

Selected: Spec & Design Doc Pack with Prototype Brief emphasis

Rationale: This is a mobile consumer flow where "feel" is critical -- the invite experience lives or dies on permission timing, share-sheet friction, and the emotional moment of sending an invite. A prototype brief is needed to validate the riskiest interactions (contacts permission prompt timing, share-sheet configuration, and the post-invite feedback moment). The tap economy worksheet is essential given the explicit goal to optimize taps to first value.

0) Context snapshot

1) Goals / Non-goals / Out of scope

Goals

• G1: Enable users to invite friends via contacts, share sheet, or direct link with minimal friction.
• G2: Optimize the critical path so that a user can send their first invite in 3 taps or fewer from the most common entry point.
• G3: Provide clear feedback on invite status (sent, accepted, reward) to reinforce the behavior loop.
• G4: Instrument the full funnel (impression -> open flow -> send -> accept -> sign up) for optimization.

Non-goals

• NG1: Incentive/reward system design (referral rewards are a separate initiative; the flow should have a placeholder hook but not implement reward logic in v1).
• NG2: Android support in this release.
• NG3: Server-side contacts matching or "find friends already on the app" (privacy-sensitive; deferred).
• NG4: In-app messaging / chat-based invites.

Out of scope

• OOS1: Referral attribution beyond first-touch (multi-touch attribution is a data platform concern).
• OOS2: A/B testing framework setup (use existing feature flag system).
• OOS3: Custom invite landing page design (use existing app install page; add deep link params only).
• OOS4: Bulk invite limits or anti-spam throttling beyond Apple's built-in share sheet constraints.

2) Assumptions + dependencies

Assumptions

• A1: Deep-link infrastructure (Universal Links) is available or can be set up within week 1. (Owner: Mobile Platform team -- confirm by day 2.)
• A2: The app already has a user identity system that can generate unique referral codes per user.
• A3: Users are most motivated to invite after a "value moment" (e.g., completing an action, achieving a milestone). Entry point placement will leverage these moments.
• A4: iOS share sheet (UIActivityViewController) is the primary send mechanism; we do not need to build custom channel integrations (iMessage, WhatsApp, etc.) in v1.
• A5: Push notifications to the inviter ("Your friend joined!") are supported by existing infra.

Dependencies

• D1: Deep-link service -- must support deferred deep links (recipient clicks link -> App Store -> opens app -> deep link resolves). (Branch.io / Firebase Dynamic Links / custom.)
• D2: Analytics pipeline -- invite events must flow to the existing event system with <1h latency for monitoring.
• D3: App review -- contacts permission purpose string must be reviewed by legal/privacy before submission.
• D4: Backend endpoint -- /invites/create and /invites/status APIs (new; estimated 3 days backend work).

3) Tap economy (mobile)

First value event: The inviter's friend receives a personalized invite message (the inviter feels "I did something").

Tap budget target: 3 taps from entry to first invite sent.

Tap removals applied:

• Combined "select contact + preview message" into a single screen (eliminated a dedicated "compose" step).
• Pre-filled message removes the need to type anything.
• Share sheet is the native iOS mechanism -- no custom channel picker needed.
• If contacts permission is denied, fall back to share-sheet-only path (still 3 taps: entry -> share sheet -> send).

Attention fragility points:

• Contacts permission prompt: If the user denies, they cannot use the contact picker. The flow must gracefully degrade to the share-sheet path without a dead end.
• App switching: When the share sheet opens Messages/WhatsApp, the user leaves the app. The success state must persist so that when they return, they see confirmation (not a stale invite screen).
• Post-send moment: If the user returns to a blank screen, the loop breaks. Show a brief celebration + "invite more" affordance.

4) Low-fidelity diagram (moving pieces)

flowchart TD
    subgraph Entry Points
        EP1["Profile tab\n(Invite Friends button)"]
        EP2["Post-action sheet\n(Share with friends)"]
        EP3["Settings\n(Invite Friends row)"]
    end

    EP1 --> IP["Invite Picker Screen"]
    EP2 --> IP
    EP3 --> IP

    IP --> PC{Contacts\npermission?}
    PC -->|Granted| CL["Contact List\n(multi-select)"]
    PC -->|Denied / Not asked| SS

    CL --> PM["Pre-composed Message\n+ Invite Link"]
    PM --> SS["iOS Share Sheet\n(Messages, WhatsApp, etc.)"]

    SS --> SR{Share\ncompleted?}
    SR -->|Yes| SC["Success Screen\n(Celebrate + Invite More)"]
    SR -->|Cancelled| IP

    SC --> IM["Invite More?\n(Return to picker)"]
    SC --> RET["Return to app\n(previous context)"]

    subgraph Backend
        API["/invites/create\n(generate link + log)"]
        DL["Deep-link service\n(Universal Link)"]
        AN["Analytics pipeline\n(invite_sent event)"]
        NF["Push notification\n(friend_joined)"]
    end

    PM -->|"Generate link"| API
    API --> DL
    API --> AN
    NF -.->|"Async: friend signs up"| SC

Annotated decisions:

1. Single invite picker screen (not separate flows per channel) -- reduces complexity and keeps tap count low.
2. Contacts permission is optional -- the flow works without it (share-sheet fallback). This avoids a hard gate.
3. Pre-composed message -- the invite link is generated before the share sheet opens, so the user sees a ready-to-send message.
4. Deep-link generation is synchronous -- must be fast (<500ms) or the share sheet feels laggy. Consider pre-generating the link when the invite screen loads.
5. Success screen is the loop point -- it reinforces the behavior and offers "invite more" before returning to the app.

5) User flows

5.1 Happy path (contacts permission granted)

1. User completes a value moment (e.g., finishes a session)
2. Post-action sheet appears: "Share with friends?" [Invite Friends] [Not now]
3. User taps [Invite Friends]
4. → Invite Picker Screen loads
   - System checks contacts permission status
   - Permission = .authorized → show contact list
   - Contact list loads (alphabetical, with search, multi-select)
5. User selects 1-3 contacts, taps [Next]
6. → Pre-composed message screen
   - Shows: "Hey [First Name], I've been using [App] and thought you'd love it! [invite-link]"
   - User can edit (optional)
   - Taps [Send via...] → iOS share sheet opens
7. User selects Messages, taps Send
8. → App resumes, Success Screen shows:
   - "Invite sent to [Name(s)]!" + animation
   - [Invite More Friends] [Done]
9. User taps [Done] → returns to previous screen

5.2 Happy path (contacts permission NOT granted -- fallback)

1-3. Same as above
4. → Invite Picker Screen loads
   - Permission = .denied or .notDetermined (user chose "skip")
   - Contact list is hidden; screen shows:
     - [Share Link] button (prominent)
     - "Allow contacts access for easier inviting" (secondary, links to Settings)
5. User taps [Share Link]
6. → iOS share sheet opens with pre-composed message + invite link
7. User selects a channel, sends
8. → Success Screen (same as above)

5.3 Edge cases

6) States (per key screen)

Invite Picker Screen

Pre-composed Message Screen

Success Screen

7) Prototype brief

Decision to enable

Validate two critical interaction uncertainties before committing to build:

1. Permission timing: Does showing a pre-permission explainer before the system contacts prompt increase the grant rate compared to triggering the system prompt directly?
2. Post-send moment: Does a celebratory success screen with "Invite More" increase repeat invite behavior compared to a simple toast notification?

Scenarios to prototype (3)

1. Permission pre-frame flow: User taps Invite Friends -> sees the explainer half-sheet -> taps Allow -> system prompt appears -> grants permission -> contacts load. Alternate: user taps Skip -> goes to share-sheet path.
2. 3-tap happy path: User taps Invite Friends -> selects 2 contacts -> taps Send -> share sheet -> sends via Messages -> sees success screen with confetti.
3. Denied-permission fallback: User taps Invite Friends -> permission denied -> sees share-link-only screen -> taps Share Link -> share sheet -> sends -> success screen.

Fidelity + tooling

• Fidelity: Hi-fi (in Figma or SwiftUI prototype). The "feel" of the permission explainer and success animation cannot be evaluated at low fidelity.
• Tooling: SwiftUI prototype preferred (runs on-device, real share sheet behavior). Figma prototype acceptable for the permission flow only.
• Disposable: Yes -- prototype code is throwaway. Production code will be built separately.

Data realism

• Use 15-20 realistic contact names (not "John Doe 1, John Doe 2").
• Pre-composed message must use a real-looking invite link (e.g., https://app.example.com/invite/abc123).
• Success screen must show real names from the selection step.

Timebox + reviewers

• Timebox: 3 days (start of week 1).
• Reviewers: Product Designer (lead), PM, 1 iOS engineer.
• Review format: 15-min walkthrough on a physical device (not screen share).

Success criteria ("feel")

• Permission grant rate in usability test: >70% of test participants grant contacts permission after seeing the pre-frame explainer.
• 3-tap completion: Participants complete the happy path in 3 taps without confusion or hesitation.
• Repeat invite intent: >50% of participants tap "Invite More" on the success screen (or express intent to invite more when asked).
• Comprehension: Participants can explain what happened to their invite ("it sent a message to my friend with a link") without prompting.

8) Requirements + acceptance criteria

9) Measurement plan

10) Risks / Open questions / Next steps

Risks

Open questions

Next steps

Quality gate

Checklist verification

Rubric self-score

Total: 29/30 -- Exceeds ship-ready threshold (24/30). No category below 3.