Create Account

Sign up as a patient or a clinic; the form adapts, then sends you to email verification.

<!-- GENERATED FILE. Do not edit by hand. Source: components/help/content/. Run npm run gen:docs. -->

Purpose & Business Context

Create Account is where both sides of the marketplace join Global Clinic: patients who want to plan and manage treatment abroad, and clinics who want to list and reach patients worldwide. The same screen serves both because the early steps (name, email, password, consent) are identical, and tailoring the labels keeps each audience feeling spoken to.

Commercially it is the top of the acquisition funnel. The role choice here decides which onboarding path a new account follows, and the explicit terms consent makes the sign-up compliant and intentional rather than accidental.

Screen Overview

The shared split-screen auth layout: the branded marketing panel on the left and the sign-up card on the right. The card's subtitle changes with the role: 'Plan, book and manage your treatment abroad.' for patients, 'List your clinic and reach patients worldwide.' for clinics.

It stacks a Patient / Clinic role toggle, a name field (relabelled by role), an email field (relabelled by role), a password field with a show/hide eye, a terms consent checkbox, the Create account button, and a footer link to sign in.

Controls & Components

• Role toggle: Patient or Clinic. It reshapes the form's labels, icons, placeholders and the consent note.
• Name field: labelled 'Full name' with a user icon for patients (placeholder 'e.g. Yusuf Al-Rashid'), or 'Clinic name' with a building icon for clinics (placeholder 'e.g. Apollo Hospitals').
• Email field: labelled 'Email' for patients or 'Work email' for clinics, with a mail icon.
• Password field: a masked input with a lock icon and an eye button to reveal it; placeholder 'Create a password'.
• Terms consent: a checkbox plus the text 'I agree to the Global Clinic Terms and Privacy Policy.' For clinics it adds 'Clinic accounts are reviewed before going live.'
• Create account button: the primary submit; it is dimmed and not actionable until consent is given.
• Footer link: 'Already have an account? Sign in', routing to /signin.

Field Definitions

• Account type (role): Patient or Clinic. Controlled toggle, defaults to Patient. It drives the name and email labels, the field icons, the placeholders, the card subtitle, the clinic-review note, and the ?role= value passed to verification.
• Name: Required text input. Rendered as 'Full name' (patient) or 'Clinic name' (clinic). Captured by the form but not validated beyond being required in this prototype.
• Email: Required email input (type=email). Rendered as 'Email' (patient) or 'Work email' (clinic). Native email-format validation applies.
• Password: Required input, masked by default. The eye button toggles plain-text visibility. No strength rule is enforced on this screen in this build.
• Agree to terms: Required consent checkbox, unchecked by default. The Create account button stays disabled (dimmed, not-allowed cursor) until it is ticked; submitting without it is a no-op.

User Actions & Workflows

1. Choose Patient or Clinic; the form's labels, icons, placeholders and subtitle adapt to that audience.
2. Enter your name (full name or clinic name) and your email (personal or work).
3. Create a password, using the eye button to reveal it if you want to check it.
4. Tick 'I agree to the Terms and Privacy Policy' to enable the Create account button.
5. Press Create account; you are taken to /verify with your role carried in the URL.
6. If you already have an account, use the footer 'Sign in' link instead.

Navigation & Relationships

Reached from: the Sign In footer ('New to Global Clinic? Create an account'), the public site's sign-up call to action, and the brand logo link to /.

Leads to: /verify?role=patient or /verify?role=clinic on submit (the role is appended to the query string), and /signin via the footer link.

Hands off to: Verify, which reads ?role= on the client and, after a code is entered, signs the user in with signInAs and routes them onward.

Business Rules & Constraints

• Submission is blocked until the terms checkbox is ticked; the button is visibly disabled until then.
• Name, email and password are all required; the browser blocks an empty submit.
• The selected role is the single switch that adapts the whole form and is forwarded as ?role= to verification.
• Clinic accounts display a notice that they are reviewed before going live, signalling a manual approval step in production.
• No account is created in storage at this step; the mock session is only established later, on the Verify screen.

Data Dependencies

Self-contained in this prototype: the form holds its own local state (role, password visibility, consent) and does not read shared data. Its only output is the route it pushes, /verify?role=<role>, which the Verify screen consumes via the mock auth's signInAs.

• Local component state: role, show-password, agree
• Role value: forwarded to /verify as ?role=
• lib/auth.tsx signInAs(): invoked later by Verify, not here

Error Handling & Edge Cases

• Pressing Create account without ticking consent does nothing; the handler returns early and the button stays disabled-looking.
• Switching role mid-form relabels everything instantly without clearing what you have typed in shared fields.
• Native validation handles an empty or malformed email before the submit handler runs.
• Revealing the password is local only and is reset to masked if you toggle it back.
• Mobile: the marketing panel is hidden, the card fills the width, and the floating Help button remains top-right.

User Roles & Permissions

• Public (no sign-in required): Anyone can reach /register to start a new account.
• Prospective patient: Choosing Patient tailors the form to personal care and, after verification, lands the new user on /portal.
• Prospective clinic: Choosing Clinic tailors the form to listing a clinic, notes that accounts are reviewed, and routes a new clinic to /clinic/onboarding after verification.

Related Features & Functionalities

Sign In (/signin) for existing users, Verify (/verify) which is the immediate next step and where the mock session is created, the clinic onboarding flow at /clinic/onboarding that a verified clinic enters, and the shared role toggle reused on Sign In. The AuthShell and floating Help button frame this screen too.

Flow & Screenshots

flowchart LR
  Register[Create Account] -->|role toggle| Adapt[Form labels adapt]
  Adapt --> Consent{Agree to terms?}
  Consent -->|no| Disabled[Button disabled]
  Consent -->|yes| Create[Create account]
  Create -->|patient| VerifyP[/verify?role=patient/]
  Create -->|clinic| VerifyC[/verify?role=clinic/]
  Register -->|Sign in| SignIn[/signin/]

Guided Walkthrough Steps

The in-app walkthrough for this screen has 6 steps (auto-advances every 5 seconds; Prev / Pause / Next; click outside to exit):

1. Patient or clinic? ([data-tour="register.role"])

Tell us who is signing up. The whole form, from labels to the subtitle, adapts, and your choice decides where you go after verifying.

1. Your name ([data-tour="register.name"])

For patients this is your full name; for clinics it is your clinic's name. The icon and placeholder change to match.

1. Your email ([data-tour="register.email"])

Where we send your verification code. Clinics are asked for a work email. This is also the address you will sign in with.

1. Agree to continue ([data-tour="register.terms"])

Tick to accept the Terms and Privacy Policy. The Create account button stays disabled until you do. Clinic accounts are reviewed before going live.

1. Create your account ([data-tour="register.submit"])

Once consent is given, this takes you to the email verification step, carrying your account type with you.

1. Help is always here ([data-tour="topbar.help"])

Open this Help button on any screen for documentation, and press Play to replay a walkthrough like this one.