System Requirements Document for healthcare-chatbot

1. Introduction

Product intent. healthcare-chatbot is a conversational health product: a chatbot that people converse with about health topics. Users describe symptoms or ask health questions in natural language and receive health-related responses. The product is deliberately human and warm rather than clinical — it is built for people who are worried, often vulnerable, and who need to feel heard rather than processed.

Audience. The product serves three accepted human roles: patients and health information seekers asking about their own health; caregivers and family members asking on behalf of someone in their care; and healthcare staff / clinical reviewers who monitor conversations so that guidance stays safe, accurate, and appropriately escalated to human care.

Delivery shape. The product is a custom first-party application with application-owned identity. Patients and caregivers enroll themselves; clinical reviewers are provisioned with review authorization. Conversations and their context are retained so users can review and resume earlier health discussions.

2. System Overview

healthcare-chatbot is a web application with a public entry surface, a shared identity-access boundary, a self-service enrollment surface for patients and caregivers, a conversation workspace, a browse-and-resume destination for past conversations, and a protected clinical review workspace.

Actors.

• Patient / Health Information Seeker — describes their own symptoms or asks health questions and follows up until they have a usable answer or a clear next step.
• Caregiver / Family Member — describes another person's situation, relays context accurately, and translates the chatbot's answers into practical care decisions.
• Healthcare Staff / Clinical Reviewer — reviews conversation content, identifies responses needing correction or human follow-up, and steps in when a case exceeds what the chatbot should handle.

Accepted behavior. Users converse with the chatbot about health topics; the chatbot provides health-related responses to questions and described symptoms; conversation history and current discussion context are persisted so users can review and resume earlier conversations; clinical reviewers review conversations and identify cases needing correction or human follow-up.

Ownership. All current surfaces are first-party application surfaces. Identity is application-owned: patients and caregivers complete self-service enrollment, all actors verify identity on return, and clinical reviewer accounts are provisioned with review authorization before clinical review work.

Narrow exclusions. This document does not add appointment booking, prescription or medication ordering, insurance or billing workflows, provider directory search, medical-record integration, or any other adjacent healthcare capability. The chatbot's responses are conversational health guidance; the product does not replace professional diagnosis, and clinical review exists to keep guidance safe and to route at-risk users to human care.

2a. Product Interpretation and Delivery Boundary

Current delivery. The current product is a first-party web application delivered as custom UI with a supporting backend. Everything a user does — reading about the product, enrolling, verifying identity, conversing with the chatbot, browsing past conversations, and reviewing conversations clinically — happens on first-party surfaces owned by this application.

Access ownership. The Landing surface is anonymously reachable and explains what the chatbot is, who it serves, and what it is for. Login is the shared returning-verification surface for all three roles. Sign Up is the self-service enrollment surface for patients and caregivers only; clinical reviewer access is provisioned rather than self-enrolled. Conversation, Conversations, and Clinical Review are protected: Conversation and Conversations are restricted to the enrolled patient/caregiver roles, and Clinical Review is restricted to provisioned clinical reviewers. A protected destination never owns the interaction that establishes access to itself — enrollment and verification happen on their own surfaces before protected work begins.

Current vs. future. Everything described in this document is current. No future-horizon capabilities are accepted; nothing in this document should be read as committing to a later phase.

2b. Source Content Inventory

Not applicable — no reference directive in this request declares a content_source.

2c. Page Content and Component Coverage

Landing

• Purpose and information. Anonymous entry surface that explains the healthcare chatbot, who it serves, and its health-conversation purpose before any protected use. Presents the product's purpose in plain, warm language: ask health questions, describe symptoms, get understandable responses, and come back to earlier conversations.
• Primary actions. Start a conversation (routes an unauthenticated visitor into the identity-access boundary, then into the conversation workspace); See how it works (explains the conversation and review model on the same surface).
• Supporting actions. Navigate to Login for returning users; navigate to Sign Up for new patients and caregivers.
• Domain entities. Product description content; health-topic marquee items (sleep, nutrition, stress, pain, medication); sample conversation preview content.
• Component responsibilities. Oversized headline block; tangerine colour block bleeding off the right edge; floating chat preview card showing a sample user/chatbot exchange with the illustrated chatbot avatar; primary hot-pink pill CTA; secondary text link; slow-scrolling health-topic marquee; decorative squiggles, stars, and 3D props.
• States. Loading: static content, no data dependency; the chat preview renders immediately. Empty: not applicable — the surface always carries its explanatory content. Success: visitor understands the product and can choose to start a conversation, log in, or sign up. Error: if the identity-access boundary is unreachable when a visitor chooses to start a conversation, the surface states that sign-in is temporarily unavailable and keeps the explanatory content and the See how it works path usable. Recovery: the visitor can retry the CTA or read the explanation and return later.

Login

• Purpose and information. Shared returning-verification surface for patients, caregivers, and clinical reviewers accessing protected conversations or clinical review work. States which protected work follows verification.
• Primary actions. Submit credentials to verify identity and continue to the destination the user was heading toward.
• Supporting actions. Navigate to Sign Up for patients and caregivers who do not yet have an account; return to Landing.
• Domain entities. Account identity; verification session.
• Component responsibilities. Credential entry fields; submit control; inline validation messaging; link to enrollment; role-appropriate continuation routing (patient/caregiver to Conversation or Conversations, provisioned reviewer to Clinical Review).
• States. Loading: submit control shows in-progress state while verification runs. Empty: fields render empty with labels and no error styling. Success: identity verified; user continues to the protected destination they intended. Error: invalid credentials show an inline message that does not reveal whether the account exists; a provisioned reviewer without review authorization is told review access is not enabled for the account rather than being silently routed elsewhere. Recovery: the user can correct and resubmit, or use the enrollment link if they have no account.

Sign Up

• Purpose and information. Self-service enrollment surface for independently starting patients and caregivers. Explains that clinical reviewer access is provisioned rather than self-enrolled.
• Primary actions. Create an account with the required enrollment information and establish the user's own identity.
• Supporting actions. Navigate to Login for users who already have an account; return to Landing.
• Domain entities. New account identity; enrollment details supplied by the user.
• Component responsibilities. Enrollment fields; submit control; inline validation; statement of the clinical-review provisioning boundary; link to Login.
• States. Loading: submit control shows in-progress state while the account is created. Empty: fields render empty with labels. Success: account created and the user proceeds into the conversation workspace as an enrolled patient or caregiver. Error: missing or invalid enrollment information is reported inline against the specific field; a duplicate-identity condition is reported without exposing unrelated account details. Recovery: the user corrects the flagged fields and resubmits, or switches to Login if an account already exists.

Conversation

• Purpose and information. Ongoing workspace for starting a health discussion, sending questions or symptoms, receiving responses, and continuing with retained context. Shows the current thread and the retained context of the discussion.
• Primary actions. Send a health question or symptom description; read the chatbot's health-related response; continue the discussion with follow-up context.
• Supporting actions. Use quick prompts from the care card; use the human-escalation CTA to request human follow-up; move to Conversations to browse earlier discussions.
• Domain entities. Conversation thread; individual messages (user messages and chatbot messages); retained discussion context; chatbot avatar sentiment state; escalation request.
• Component responsibilities. Chat thread column with asymmetric message bubbles (user messages as hot-pink pills with a sharp bottom-right corner, chatbot messages as white cards with a soft shadow and rounded bottom-left corner); message composer; chatbot avatar in the header that changes expression with conversation sentiment; persistent care-card sidebar with quick prompts and a sticker-like Talk to a human badge; mobile bottom-sheet collapse of the sidebar.
• States. Loading: the thread shows a loading state while retained context is fetched; the composer is available once the thread is ready. Empty: a new conversation shows an opening prompt inviting the user to describe what is going on, with quick prompts available. Success: the user's message appears in the thread and a health-related response is returned and readable in context. Error: if a message cannot be sent or a response cannot be produced, the thread shows the failed message with a retry affordance and the retained context is not lost. Recovery: the user retries the message, rephrases it, or uses the human-escalation CTA; the conversation remains resumable from Conversations.

Conversations

• Purpose and information. Revisitable browse destination for reviewing past health conversations and selecting one to resume. Shows the user's own retained conversations with enough identifying context to recognize each one.
• Primary actions. Select a past conversation to resume it in the conversation workspace.
• Supporting actions. Start a new conversation; return to the current conversation.
• Domain entities. The user's conversation list; per-conversation identifying context (topic or opening question, recency).
• Component responsibilities. Conversation list with per-item summary and recency; selection control that opens the chosen conversation; entry point for starting a new conversation.
• States. Loading: list shows a loading state while retained conversations are fetched. Empty: a user with no retained conversations sees an explanation and a direct path to start the first conversation. Success: the list shows the user's conversations and the selected one opens with its retained context. Error: if the list cannot be loaded, the surface explains the failure and offers retry without discarding the user's ability to start a new conversation. Recovery: retry the load, or start a new conversation and return to browsing later.

Clinical Review

• Purpose and information. Protected workspace for clinical or support staff to review chatbot conversations and identify cases needing correction or human follow-up. Shows conversation content alongside the review state of each case.
• Primary actions. Review a conversation's content; identify a response that needs correction or human follow-up; step in when a case exceeds what the chatbot should handle.
• Supporting actions. Move between conversations awaiting review and those already dispositioned; record the review outcome for a case.
• Domain entities. Reviewable conversations; chatbot responses under review; review disposition (needs correction, needs human follow-up, escalated to human care); reviewer identity bound to the disposition.
• Component responsibilities. Conversation content viewer; disposition controls; queue or list of conversations awaiting review; indication of which cases have been escalated to human care.
• States. Loading: the review workspace shows a loading state while conversations are fetched. Empty: a reviewer with no conversations awaiting review sees a clear all-clear state rather than a blank panel. Success: the reviewer records a disposition and the case leaves the awaiting-review set with the disposition visible. Error: if a conversation cannot be loaded or a disposition cannot be recorded, the workspace states the failure and preserves the reviewer's in-progress selection. Recovery: retry the load or the disposition; the case remains in the awaiting-review set until a disposition is successfully recorded.

3. Functional Requirements

FR-1 — Converse with the chatbot about health topics (explicit) As a Patient / Health Information Seeker, I should converse with the healthcare chatbot about health topics so that I can get understandable health guidance in natural language.

• Trigger/input: the user opens the Conversation workspace and sends a message describing a health topic.
• Observable result: the message appears in the thread and a health-related response is returned and readable in the retained context of the discussion.
• Access state: protected; requires verified identity as an enrolled patient or caregiver.
• Failure/recovery: if the message cannot be sent or a response cannot be produced, the thread shows the failed message with a retry affordance and the retained context is preserved; the user can retry or rephrase.
• Continuation: the user continues the discussion with follow-up messages, or moves to Conversations to resume it later.

FR-2 — Receive health-related responses to questions and described symptoms (explicit) As a Patient / Health Information Seeker, I should describe my symptoms or ask my health question and receive a health-related response so that I get a usable answer or a clear next step.

• Trigger/input: a question or symptom description submitted in the Conversation workspace.
• Observable result: a health-related response is returned in the thread, addressed to what the user described.
• Access state: protected; requires verified identity as an enrolled patient or caregiver.
• Failure/recovery: if no response can be produced, the user is told the response could not be generated and can retry, rephrase, or use the human-escalation CTA.
• Continuation: the user follows up with additional context until the answer is usable or a next step is clear.

FR-3 — Ask on behalf of someone in my care (explicit, via accepted caregiver role) As a Caregiver / Family Member, I should describe another person's situation and interpret the guidance for them so that I can act on the chatbot's answers in the care I provide.

• Trigger/input: a message describing the cared-for person's symptoms or situation, submitted in the Conversation workspace.
• Observable result: a health-related response is returned that the caregiver can translate into a practical care decision.
• Access state: protected; requires verified identity as an enrolled caregiver.
• Failure/recovery: as FR-2 — retry, rephrase, or escalate to a human.
• Continuation: the caregiver follows up with the cared-for person's context and retains the conversation for later reference.

FR-4 — Self-service enrollment for patients and caregivers (required_inference) As a Patient / Health Information Seeker or Caregiver / Family Member, I should complete self-service enrollment before creating or retaining protected conversations so that my health discussions are bound to my own identity.

• Trigger/input: the user chooses to start a conversation or sign up from the Landing surface and supplies the required enrollment information on Sign Up.
• Observable result: an account is created and the user proceeds into the conversation workspace as an enrolled patient or caregiver.
• Access state: Sign Up is anonymously reachable; the protected conversation state remains unavailable until enrollment completes.
• Failure/recovery: invalid or missing enrollment information is reported inline against the specific field; a duplicate-identity condition is reported without exposing unrelated account details; the user corrects and resubmits or switches to Login.
• Continuation: the enrolled user starts their first conversation.

FR-5 — Returning verification for all actors (required_inference) As a Patient / Health Information Seeker, Caregiver / Family Member, or Healthcare Staff / Clinical Reviewer, I should verify my identity on return before accessing protected conversations or clinical review work so that my retained state stays bound to me.

• Trigger/input: the user submits credentials on Login.
• Observable result: identity is verified and the user continues to the protected destination they intended.
• Access state: Login is anonymously reachable; protected destinations remain unavailable until verification succeeds.
• Failure/recovery: invalid credentials show an inline message that does not reveal whether an account exists; a provisioned reviewer without review authorization is told review access is not enabled for the account; the user can correct and resubmit or use the enrollment link.
• Continuation: the verified user proceeds to Conversation, Conversations, or Clinical Review according to their role.

FR-6 — Provisioned clinical reviewer access (required_inference) As a Healthcare Staff / Clinical Reviewer, I should have my account provisioned with the appropriate review authorization before accessing Clinical Review so that review work is limited to authorized staff.

• Trigger/input: a provisioned reviewer verifies identity on Login.
• Observable result: the reviewer reaches the Clinical Review workspace; a reviewer whose account lacks review authorization is told review access is not enabled rather than being routed into review work.
• Access state: Clinical Review is role-restricted to provisioned clinical reviewers; Sign Up does not grant review access.
• Failure/recovery: if review authorization is absent or cannot be confirmed, the reviewer is informed and does not enter review work.
• Continuation: the authorized reviewer begins reviewing conversations awaiting review.

FR-7 — Review conversations and identify cases needing correction or human follow-up (explicit) As a Healthcare Staff / Clinical Reviewer, I should review chatbot conversations and identify responses that need correction or human follow-up so that guidance stays clinically sound.

• Trigger/input: the reviewer opens Clinical Review and selects a conversation from those awaiting review.
• Observable result: the conversation content is shown and the reviewer records a disposition — needs correction, needs human follow-up, or escalated to human care — which becomes visible on the case.
• Access state: protected; role-restricted to provisioned clinical reviewers.
• Failure/recovery: if a conversation cannot be loaded or a disposition cannot be recorded, the workspace states the failure and preserves the reviewer's in-progress selection; the case stays in the awaiting-review set until a disposition is recorded.
• Continuation: the reviewer moves to the next conversation awaiting review.

FR-8 — Step in when a case exceeds the chatbot's handling (explicit) As a Healthcare Staff / Clinical Reviewer, I should step in when a case exceeds what the chatbot should handle so that at-risk users are routed to appropriate human care.

• Trigger/input: the reviewer identifies a conversation that exceeds the chatbot's handling during review, or a user requests human follow-up from the care card.
• Observable result: the case is marked as escalated to human care and is distinguishable from cases that only need correction.
• Access state: protected; role-restricted to provisioned clinical reviewers for the review-side action; the user-side escalation request is available to enrolled patients and caregivers in the Conversation workspace.
• Failure/recovery: if the escalation cannot be recorded, the workspace states the failure and the case remains in the awaiting-review set.
• Continuation: the escalated case remains visible as escalated while the reviewer continues with other cases.

FR-9 — Persisted conversation history and current context (required_inference) As a Patient / Health Information Seeker or Caregiver / Family Member, I should have my conversation history and current discussion context persisted so that I can review and resume earlier health conversations.

• Trigger/input: the user sends messages in the Conversation workspace, then later opens Conversations.
• Observable result: the user's retained conversations are listed with enough identifying context to recognize each one, and selecting one reopens it with its retained context.
• Access state: protected; the user sees only their own conversations.
• Failure/recovery: if the list or a conversation cannot be loaded, the surface explains the failure and offers retry without discarding the user's ability to start a new conversation.
• Continuation: the user resumes the selected conversation or starts a new one.

FR-10 — Request human follow-up from within a conversation (explicit, via accepted escalation behavior) As a Patient / Health Information Seeker or Caregiver / Family Member, I should be able to ask for human follow-up from the care card so that a case that needs a person reaches one.

• Trigger/input: the user activates the human-escalation CTA in the care-card sidebar.
• Observable result: the conversation is marked as needing human follow-up and becomes visible to clinical review as a case requiring attention.
• Access state: protected; available to enrolled patients and caregivers in the Conversation workspace.
• Failure/recovery: if the request cannot be recorded, the user is told and can retry; the conversation remains intact.
• Continuation: the user continues the conversation while the case is available for clinical review.

4. User Personas

Patient / Health Information Seeker

• Product context. A person with a health concern who opens the healthcare chatbot to describe symptoms or ask health questions in natural language. They arrive worried and often vulnerable, and they are not looking for a hospital portal — they want a place that feels safe to ask anything.
• Primary goal. Get a relevant, comprehensible response without needing to navigate a complex medical system.
• Distinct accepted responsibilities. Supply enough context about their own situation; follow up on the chatbot's responses until they get a usable answer or a clear next step; enroll themselves before creating or retaining protected conversations; verify identity on return; review and resume earlier conversations; request human follow-up when a conversation needs a person.
• Relevant inputs and decisions. Symptom descriptions and health questions; how much personal context to share; whether a response is usable or needs follow-up; whether to escalate to a human.
• Interactions with other participants. Their conversations become reviewable cases for the Healthcare Staff / Clinical Reviewer when a response needs correction or human follow-up, and their escalation request is what routes a case to human care.
• Observable success. A health-related response that addresses what they described, retained so they can return to it, with a clear next step when one is needed.

Caregiver / Family Member

• Product context. A person asking health questions on behalf of someone they care for, such as a relative or dependent. They are describing a situation they did not experience directly and must interpret the answer for someone else.
• Primary goal. Obtain guidance they can act on for the person in their care.
• Distinct accepted responsibilities. Relay symptoms and context accurately on behalf of another person; translate the chatbot's answers into practical care decisions; enroll themselves; verify identity on return; retain and revisit conversations about the person in their care; request human follow-up when the situation needs a person.
• Relevant inputs and decisions. The cared-for person's symptoms and circumstances; how to phrase a second-hand description so it is accurate; whether the guidance is actionable for the person in their care.
• Interactions with other participants. Like the patient, their conversations can become reviewable cases for the Healthcare Staff / Clinical Reviewer, and their escalation request routes a case to human care.
• Observable success. Guidance specific enough to act on for the person in their care, retained for later reference.

Healthcare Staff / Clinical Reviewer

• Product context. A clinical or support professional who monitors the chatbot's health conversations to ensure the guidance given is safe, accurate, and appropriately escalated. They work behind a provisioned account rather than self-enrolling.
• Primary goal. Keep conversations clinically sound and route at-risk users to appropriate human care.
• Distinct accepted responsibilities. Review conversation content; identify responses that need correction or human follow-up; step in when a case exceeds what the chatbot should handle; record a disposition that stays bound to their reviewer identity.
• Relevant inputs and decisions. The conversation content under review; whether a response is safe and accurate; whether a case needs correction, human follow-up, or escalation to human care.
• Interactions with other participants. They act on conversations initiated by patients and caregivers, including cases those users explicitly escalated, and their dispositions determine whether a user's case receives human attention.
• Observable success. Conversations stay clinically sound, cases needing attention are dispositioned, and at-risk users are routed to appropriate human care.

5. Core User Flows

Flow A — A patient asks about a symptom and gets a usable answer

1. The patient arrives at Landing anonymously and reads what the chatbot is for and who it serves.
2. The patient selects Start a conversation. Because protected conversation state requires identity, they are routed into the identity-access boundary.
3. Having no account, the patient goes to Sign Up and supplies the required enrollment information. The account is created and they proceed into the conversation workspace as an enrolled patient.
4. In Conversation, the patient sees an opening prompt inviting them to describe what is going on, with quick prompts available in the care card.
5. The patient types a description of their symptom and sends it. Their message appears as a hot-pink pill with a sharp bottom-right corner.
6. The chatbot returns a health-related response, which appears as a white card with a rounded bottom-left corner; the avatar in the header reflects the conversation's sentiment.
7. The patient reads the response and decides it is not specific enough, so they send a follow-up with more context. The retained context of the discussion is preserved across both messages.
8. The chatbot returns a response the patient can act on. Observable result: the patient has a usable answer or a clear next step in a retained conversation.
9. Failure/recovery: if a message fails to send or no response can be produced, the thread shows the failed message with a retry affordance and the retained context is not lost; the patient retries or rephrases.
10. Continuation: the patient leaves and later returns through Login, verifies identity, opens Conversations, recognizes the discussion by its identifying context, and resumes it in Conversation.

Flow B — A caregiver asks on behalf of someone in their care

1. The caregiver arrives at Landing and selects Start a conversation, then enrolls through Sign Up as a caregiver.
2. In Conversation, the caregiver describes the cared-for person's symptoms and circumstances, making clear that the description is second-hand.
3. The chatbot returns a health-related response. The caregiver reads it and judges whether it is actionable for the person in their care.
4. The caregiver sends a follow-up to pin down what they should do next; the retained context carries the earlier description forward.
5. Observable result: the caregiver has guidance they can act on for the person in their care, retained in their own conversation history.
6. Failure/recovery: if a response cannot be produced, the caregiver retries or rephrases; if the situation feels beyond what the chatbot should handle, they use the Talk to a human CTA in the care card.
7. Continuation: the caregiver returns later through Login, opens Conversations, and resumes the discussion to check what was advised.

Flow C — A user escalates a conversation to a human

1. While in Conversation, the patient or caregiver decides the situation needs a person and activates the Talk to a human CTA in the care-card sidebar.
2. Observable result: the conversation is marked as needing human follow-up and becomes visible to clinical review as a case requiring attention.
3. Failure/recovery: if the request cannot be recorded, the user is told and can retry; the conversation remains intact either way.
4. Continuation: the user keeps talking in the same conversation while the case is available for clinical review.

Flow D — A clinical reviewer dispositions a conversation

1. The reviewer verifies identity on Login with a provisioned account that carries review authorization.
2. The reviewer lands in Clinical Review and sees the conversations awaiting review, or a clear all-clear state if none are waiting.
3. The reviewer selects a conversation — including any case a user escalated — and reads the conversation content.
4. The reviewer decides the response needs correction and records that disposition. Observable result: the disposition becomes visible on the case and the case leaves the awaiting-review set.
5. The reviewer selects the next conversation and identifies one that exceeds what the chatbot should handle, then steps in by marking it escalated to human care. Observable result: the case is distinguishable from cases that only needed correction, and the at-risk user is routed to appropriate human care.
6. Failure/recovery: if a conversation cannot be loaded or a disposition cannot be recorded, the workspace states the failure and preserves the reviewer's in-progress selection; the case stays in the awaiting-review set until a disposition is recorded.
7. Continuation: the reviewer continues with the remaining conversations awaiting review.

Flow E — A returning user resumes an earlier conversation

1. The user opens Login and verifies identity.
2. The user opens Conversations and sees their own retained conversations with enough identifying context to recognize each one.
3. The user selects the earlier discussion. Observable result: it reopens in Conversation with its retained context.
4. Failure/recovery: if the list or the conversation cannot be loaded, the surface explains the failure and offers retry; the user can still start a new conversation.
5. Continuation: the user continues the resumed discussion or starts a new one.

Flow F — A visitor learns about the product before committing

1. A visitor arrives at Landing anonymously and reads the oversized headline and the explanation of who the chatbot serves.
2. The visitor watches the health-topic marquee pass and reads the sample conversation in the floating chat preview card.
3. The visitor selects See how it works to understand the conversation and review model on the same surface.
4. Observable result: the visitor understands the product and can choose Start a conversation, Login, or Sign Up.
5. Failure/recovery: if the identity-access boundary is unreachable when the visitor chooses to start, the surface says sign-in is temporarily unavailable and keeps the explanatory content and the See how it works path usable.
6. Continuation: the visitor returns later and proceeds into enrollment or verification.

6. Visuals Colors and Theme

Muse and headline. Jessica Walsh — playful maximalism for a healthcare chatbot that feels human, not clinical. The register is warm, confident, and a little surprising: saturated, surreal, and bold enough to feel like a real product rather than a triage form. The palette deliberately avoids the blue-indigo band entirely, so the product never reads as generic SaaS or as a hospital portal.

Colour tokens — light mode (authoritative).

No blue appears anywhere in the palette. The palette is entirely warm by design: it signals care, warmth, and humanity rather than clinical sterility.

Typography.

• Headings: Archivo Black, weight 900 only, tight tracking -0.03em, sentence case with occasional all-caps for emphasis. Headlines are oversized and confident — they fill the frame and feel like a poster.
• Body: Syne.
• Scale: 1.5 modular — 72 / 48 / 32 / 24 / 18 / 16.
• Hero headline: 96px desktop, 48px mobile, using clamp() so it scales between them.
• Body: 18px with 1.6 line-height.
• Micro-labels: 12px all-caps with 0.12em tracking.

Shape language. Big radii — 24px on cards, 999px on pills and buttons. Overlapping sticker-like shapes and hard-edged colour blocks that cut diagonally across sections. Chat bubbles are asymmetric: user messages are hot-pink pills with a sharp bottom-right corner; chatbot messages are white cards with a soft drop shadow and a rounded bottom-left corner. Decorative blobs and squiggles in muted peach and tangerine float behind content but never cover text.

Layout. Asymmetric editorial grid on a 12-column base. The hero is a full-bleed warm cream field with an oversized headline spanning 8 columns, a tangerine colour block bleeding off the right edge, and a floating chat preview card. Sections alternate between full-bleed colour fields and white content areas. The conversation page is a two-column split: chat thread on the left (70%), persistent care-card sidebar on the right (30%) with quick prompts and a human-escalation CTA. On mobile, the sidebar collapses to a bottom sheet.

Imagery style. Surreal, art-directed 3D props rendered in a bright, toy-like style with soft shadows: a glossy pink pill capsule with a face, a smiling stethoscope, a tangerine heart with a bandage. No stock photography of doctors, hospitals, or patients. The chatbot avatar is a custom illustrated character — a friendly blob with eyes that blink and change expression based on conversation sentiment. Decorative squiggles and stars in muted peach float in the background. Nothing photorealistic, nothing that could induce anxiety — no needles, blood, or gore.

Readable text and controls. Headlines, wordmarks, labels, numbers, and card text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The oversized ask. The Landing surface opens on a full-bleed warm cream (#FFF4E6) field. The headline "Ask me anything about your health" is set in Archivo Black at 96px desktop / 48px mobile, spanning 8 columns of the 12-column grid, with the word "anything" in hot pink (#FF4D6D) and rotated -2deg. It is never centred; on mobile it wraps to three lines. To the right, a tangerine (#FF8C42) colour block bleeds off the right edge of the viewport, and a floating white chat preview card overlaps it, showing a sample exchange between a user and the illustrated chatbot avatar — the user's line rendered as a hot-pink pill with a sharp bottom-right corner, the chatbot's as a white card with a soft shadow and a rounded bottom-left corner. Pinned beneath the headline is the hot-pink pill CTA "Start a conversation", with a secondary "See how it works" text link beside it. Across the lower band of the field, a slow marquee of health topics — sleep, nutrition, stress, pain, medication — scrolls in muted peach (#FFD6A5). Decorative squiggles, stars, and toy-like 3D props sit behind the content without covering any text or control.

The concept recomposes only accepted content and controls: the product's purpose, the sample conversation, the health topics the chatbot covers, and the two entry actions. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief.

• Focal subject. The oversized Archivo Black headline with "anything" in hot pink and rotated -2deg, paired with the floating white chat preview card overlapping the tangerine block that bleeds off the right edge.
• Input → transformation → outcome thesis. As the visitor arrives, the headline reveals word-by-word with a staggered 80ms delay, so the question assembles itself the way a conversation starts; the chat preview card settles into place over the tangerine block, showing a sample exchange with the illustrated avatar; the health-topic marquee begins its slow 40s-per-loop scroll. The outcome is a visitor who reads the product's purpose and reaches the Start a conversation CTA already understanding what a conversation here looks like.
• Motion vocabulary. Word-by-word headline reveal at 80ms stagger; springy message entrance using cubic-bezier(0.34, 1.56, 0.64, 1) at 300ms, with chat messages sliding in from the left; buttons scaling to 1.05 on hover with a 200ms spring; the health-topic marquee scrolling at 40s per loop; the avatar's eyes blinking and shifting expression with conversation sentiment.
• Composed first frame. Warm cream field, headline fully legible and spanning 8 columns with "anything" in hot pink and rotated -2deg, tangerine block bleeding off the right edge, chat preview card overlapping it with one user pill and one chatbot card visible, hot-pink CTA pinned beneath the headline, marquee band visible in muted peach below.
• Reduced-motion state. All motion is removed: the headline appears instantly in its final position, chat messages appear instantly rather than sliding in, hover scaling is dropped, and the marquee becomes a static wrapped row of health topics so every item is fully readable. The composed first frame is unchanged.

9. Non-Functional Requirements

• NFR-1 — Identity-bound conversation privacy (required_inference). Retained conversations and their context are bound to the enrolled identity that created them; a user sees only their own conversations, and clinical review work is reachable only by provisioned reviewers. Rationale: the accepted journeys require durable, resumable, actor-specific health discussions and a protected review workspace.
• NFR-2 — Warm, non-clinical visual register (explicit, creative direction). The interface must not use the blue-indigo palette (#0057FF, #2563EB, #4F46E5, #6366F1) on white, must not use Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body, and must not use stock photography of doctors, hospitals, or patients or any photorealistic medical imagery that could induce anxiety. Rationale: the product must lower the temperature for anxious users rather than read as a hospital portal.
• NFR-3 — Readable text and controls at every viewport (explicit, creative direction). Headlines, wordmarks, labels, numbers, and card text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control.
• NFR-4 — Reduced-motion support (explicit, creative direction). All motion respects prefers-reduced-motion: messages appear instantly, the marquee becomes a static wrapped row, and the hero headline appears in its final position without the staggered reveal.
• NFR-5 — Retained conversation context (required_inference). Conversation history and current discussion context persist across sessions so a user can review and resume an earlier health conversation with its context intact.
• NFR-6 — Backend integration (required_inference). The product requires backend integration to produce health-related responses, persist conversations and context, and hold review dispositions.

10. Tech Stack

• Frontend: React, delivered as a custom first-party web UI. (Default — not specified by user)
• Backend: Python with FastAPI, providing the conversation, persistence, and review endpoints. (Default — not specified by user)
• Storage: a persistent datastore for accounts, conversations, message history, retained context, and review dispositions. (Default — not specified by user)
• Packaging and local run: Docker with docker-compose. (Default — not specified by user)
• Deployment: Kubernetes is not required for the current scope and is not included. (Default — not specified by user)

No source-specified technology choices were provided; the above are labeled defaults and do not alter any product behavior.

11. Assumptions and Constraints

• A-1. The product is a first-party web application with application-owned identity and custom UI, as established by the accepted delivery shape.
• A-2. Patients and caregivers enroll themselves through Sign Up; clinical reviewer accounts are provisioned with review authorization and are not created through self-service enrollment.
• A-3. Login is the single shared returning-verification surface for all three accepted roles.
• A-4. Conversation and Conversations are restricted to enrolled patients and caregivers; Clinical Review is restricted to provisioned clinical reviewers.
• A-5. The chatbot's responses are conversational health guidance. The product does not replace professional diagnosis; clinical review exists to keep guidance safe and to route at-risk users to human care.
• A-6. No future-horizon capabilities are accepted. Nothing in this document commits to a later phase.
• A-7. The creative direction is authoritative for palette, typography, shape language, layout, imagery, and motion; the user supplied no competing colour, font, or brand instruction.
• A-8. The health-topic marquee items (sleep, nutrition, stress, pain, medication) are the topics named in the creative direction and are presented as illustrative topics, not as a closed taxonomy of chatbot capabilities.
• C-1. The blue-indigo palette and the listed generic typefaces are prohibited for this project, and the generic indigo/blue-on-white SaaS template is forbidden.
• C-2. No adjacent healthcare capability is in scope: no appointment booking, prescription or medication ordering, insurance or billing workflow, provider directory search, or medical-record integration.

12. Glossary

• Chatbot — the conversational agent users talk to about health topics; it returns health-related responses to questions and described symptoms.
• Conversation — a single retained health discussion between a user and the chatbot, including its messages and current context.
• Conversations — the browse destination where a user reviews their own past conversations and selects one to resume.
• Care card — the persistent sidebar on the conversation workspace holding quick prompts and the human-escalation CTA.
• Clinical Review — the protected workspace where provisioned clinical reviewers examine conversations and record dispositions.
• Disposition — the reviewer's recorded outcome for a case: needs correction, needs human follow-up, or escalated to human care.
• Escalation — routing a case to human care, either because a user requested human follow-up or because a reviewer judged the case to exceed what the chatbot should handle.
• Enrollment — self-service account creation by a patient or caregiver on Sign Up.
• Provisioning — the out-of-band establishment of a clinical reviewer account with review authorization, as distinct from self-service enrollment.
• Retained context — the persisted history and current discussion state that lets a user resume an earlier conversation.
• Sentiment state — the chatbot avatar's expression, which changes with the tone of the conversation.