Feel Pro Club Docs

Appearance

0002. Player Profile Onboarding and Completion Status ​

Status: Approved Author: Codex Created: 2026-03-09

Overview ​

This PRD defines the base player profile journey that follows authentication. It covers the wizard used to build the core player card, the one-time deferral path, and the completion-status rules used to control eligibility across the platform.

Problem Statement ​

Feel Pro Club needs a minimum viable player identity before it can place users into team or market experiences. Without core player data and a reliable signal of profile completeness, discovery quality drops, platform actions become inconsistent, and users may enter flows they are not yet ready to complete.

Goals ​

  • Capture the minimum player data needed to personalize team and market experiences.
  • Make the wizard lightweight enough to complete in one session while still allowing a one-time deferral.
  • Maintain an explicit profile-complete flag that other product areas can use to allow or block actions.

Success Metrics ​

  • High completion rate for the four-step player profile wizard.
  • Low abandonment between authentication and first profile completion.
  • High percentage of incomplete users who recover through home/profile reminders and complete their player card later.

Scope ​

In Scope ​

  • Profile-start explanation screen.
  • Four-step player profile wizard.
  • Skip and cancel behavior for first-time completion and later editing.
  • Persistent completion-state tracking and downstream gating based on that state.
  • Home notification that routes incomplete users into profile completion.

Out of Scope ​

  • Full personal-account editing such as avatar upload or legal profile fields.
  • Team-specific roles like organizer, starter, substitute, or known substitute assignment.
  • Free-player discovery preferences such as availability and preferred zones.

Personas and Roles ​

  • Authenticated new user: Needs to create a usable player card before entering the rest of the app.
  • Returning user editing profile: Needs to update player data from the profile area without redoing onboarding context.
  • Incomplete-profile user: Deferred the initial wizard and needs a clear recovery path from home into profile completion.
  • Platform service: Needs a reliable completion flag to determine whether the user is eligible for specific product actions.

User Journey ​

  1. After authentication, the user lands on a welcome-to-profile screen explaining why the player card matters.
  2. The user can either start the wizard or defer it after confirming the consequences.
  3. The user completes preferred foot, positions, play style, and birth date.
  4. If the user defers during first-run onboarding, the system lets the user continue into their context-specific post-onboarding path but does not present this onboarding wizard automatically again.
  5. An incomplete-profile user sees a persistent home notification that routes into the profile area, where the same data can be completed or edited later.
  6. If the wizard was opened from the profile page later, completion returns the user to the originating screen instead of replaying onboarding.

Functional Requirements ​

Profile Start and Deferral ​

  1. The profile-start screen shall greet the user by first name and explain why the player card is needed.
  2. The user shall be able to begin the wizard immediately or defer it.
  3. Deferring the base player card shall require an explicit confirmation dialog.
  4. Deferring from the base onboarding flow shall still allow the user to continue into their context-specific destination.
  5. Once the user defers the first-run wizard, the onboarding version of this journey shall not be shown automatically again.
  6. After a first-run deferral, the product shall surface a persistent home notification that links the user to the profile area to complete the missing information.

Core Player Wizard ​

  1. The wizard shall contain exactly four required data steps in this order: preferred foot, positions, play style, birth date.
  2. Preferred foot shall be a single choice among left, right, or both.
  3. Positions shall support multi-select and allow the user to choose more than one field role.
  4. Play style shall be a single choice among casual/fun, high effort, or competition-oriented options.
  5. Birth date shall be captured through a scrollable picker composed of separate day, month, and year selectors.
  6. The day selector shall allow values from 1 through 31.
  7. The month selector shall display abbreviated month names from Jan through Dec.
  8. The year selector shall be ordered in descending order, starting from the current calendar year and continuing down to 1900.
  9. The birth date must result in an age between 5 and 99 years (inclusive). Values outside this range shall be rejected with an error message.
  10. The wizard shall enforce completion of the current step before enabling the primary next action.
  11. The footer controls shall expose progress indicators, back navigation, and a contextual final action label.
  12. Completing all four required steps shall mark the user's base profile as complete.

Editing Behavior ​

  1. When the wizard is entered from my-profile, the header action shall read as cancellation rather than skip.
  2. When the user completes the final step while editing, the flow shall save and return to the originating screen.
  3. When the user leaves editing from the first step, the flow shall return to the originating screen rather than restarting onboarding.
  4. Birth date shall be displayed but not editable in edit mode. Users who need to correct their birth date must contact support.
  5. The profile area shall expose the same base player fields even when the user previously deferred the onboarding wizard.
  6. Completing all missing required fields from the profile area shall update the profile-complete flag immediately.

Completion Status and Gating ​

  1. The system shall store an explicit completion flag for the base player profile.
  2. The completion flag shall be complete only when preferred foot, at least one position, play style, and a valid birth date are all present.
  3. If one or more required fields are missing, the completion flag shall remain incomplete.
  4. The completion flag shall be available to other product areas so they can allow or block actions based on profile readiness.
  5. Users with an incomplete base profile shall not appear in the market.
  6. Additional gated actions may be introduced later using the same completion flag without requiring changes to the onboarding entry flow.

Business Rules and Permissions ​

  • Preferred foot, at least one position, play style, and a valid birth date are required to mark the base profile as complete.
  • A user may continue into other app areas with an incomplete base profile, but downstream capabilities may be restricted based on the completion flag.
  • The completion flag is cross-cutting state and shall not be inferred separately by each feature area.
  • Birth date cannot be changed after initial entry. Users who need to correct their birth date must contact support.

UX Considerations ​

  • The wizard should feel lightweight, with one concept per screen and highly visual option cards.
  • Birth date should be framed as private information used for categories or internal statistics, not public profile display.
  • The birth-date picker should optimize fast mobile selection by presenting day, month, and year as independent scrollable controls.
  • Skip language should be explicit about the downside of leaving the player card incomplete.
  • The home reminder for incomplete profiles should remain visible until the user reaches a complete state.
  • Moving from the home reminder into profile completion should feel like a continuation of setup, not a punitive dead end.

Error States ​

  • The wizard shall autosave in-progress answers locally after each completed step and restore the latest draft if the app is closed, refreshed, or loses connectivity before final submission.
  • If the final save fails, all entered values and current-step context shall remain intact, the user shall stay in the wizard, and the product shall offer retry instead of restarting the flow.
  • If edit mode cannot load the user's existing profile values, the product shall block editing behind an error state with retry. It shall not open an empty wizard that could overwrite existing data.
  • Profile writes shall use conflict detection. If the same profile is changed on another device before save completes, the user shall see a conflict message and must reload the latest server state before overwriting newer data.

Linear Issues ​

IDTitle
FPC-14Player Profile Onboarding and Completion Status (Epic)
FPC-15Shared types, schemas, and constants for player profile
FPC-16API — Player create and update endpoints
FPC-17App — Profile wizard start and deferral screens
FPC-18App — Profile wizard steps (foot, positions, style, birthdate)
FPC-19App — Profile wizard summary and save
FPC-20App — Profile editing from my-profile
FPC-21App — Home notification for incomplete profiles
FPC-22App — Completion status gating